Open GoogleCodeExporter opened 9 years ago
Here is the complete list of methods:
selectItem(int index) already implemented
selectItem(String text) already implemented
selectItem(Pattern pattern)
toggleItem(int index)
toggleItem(String text)
toggleItem(Pattern pattern)
selectItems(int... indices) already implemented
selectItems(String... texts) already implemented
selectItems(Range.From from, Range.To to) already implemented
selectItems(Pattern... patterns)
selectItems(PatternRange... ranges)
toggleItems(int... indices)
toggleItems(String... texts)
toggleItems(Range... ranges)
toggleItems(Pattern... patterns)
toggleItems(PatternRange... ranges)
I would also replace selectItems(Range.From from, Range.To to) with
selectItems(Range... ranges).
That's a lot of methods. Maybe having a toggle method for each select method-or
having toggle methods at all for that matter-is just too much to ask for, but
having
variants which expect regular expressions seems reasonable.
Thanks and keep up the good work,
Csabi
Original comment by csaba.ju...@gmail.com
on 3 Jul 2008 at 7:59
I forgot, I believe that selectAllItems should also be implemented.
Thanks,
Csabi
Original comment by csaba.ju...@gmail.com
on 3 Jul 2008 at 9:04
Hi Csabi,
Although I strongly think this is a useful feature, I'd prefer to address it in
version 1.1 since it will require a lot of work. On the mean time, I think you
could
achieve the same result if you implement your own JListCellReader, which matches
names using regex.
Please let me know what you think.
Thanks!
-Alex
Original comment by Alex.Rui...@gmail.com
on 14 Jul 2008 at 10:12
[deleted comment]
[deleted comment]
Hi,
I'm certainly not rushing you Alex. I'm convinced that you have more urgent
issues to
worry about. I already have workarounds in place for the methods that I would
need
and currently I have other things on my mind, I have a lot of tests to
implement.
On the other hand, I'm more concerned with issues that require radical changes
in the
FEST code base. I'm thinking of changing a method's fingerprint or its
semantics, for
example. An example of this is issue 171.
I believe that it's imperative that these issues are settled before 1.0, which
should
be stable enough to build upon. Once you have a stable contract in place for the
standard components it is more easier to concentrate on extending FEST to other
component libraries, which, of course, should have a similar contract, with
similar
method fingerprints or support classes, for example.
I also believe that more people should be involved in discussions regarding the
evolution of FEST. A forums would be nice.
Do you have any plans to include more people in the development team?
Some questions about the future directions of FEST:
Will it provide backward compatibility?
When will it stabilize?
What about the ASM support class for decorating ContainerFixture?
JIDE components?
And sorry for the late reply, I haven't checked my mail recently.
Hope to hear from you soon,
Csabi
Original comment by csaba.ju...@gmail.com
on 17 Jul 2008 at 7:26
Hi Csabi,
Thanks for your reply :)
I completely agree with you. Changes in API should be completed before 1.0. We
plan
to have a stable API by 1.0b2 (due in middle August.) After that we might have
1.0b3
(depending on enhancement requests/bugs) or we might just jump to 1.0r1. All the
release candidates (we have planned 3) are going to focus on bug fixing.
We expect to have 1.0 by November this year. We expect to have any version(s)
after
that to be backwards compatible.
About the ASM/extension-related stuff, we are going to create a separate
extension
module (fest-swing-extension). Since this module is separate from the main
FEST-Swing
module, it can have its own schedule. We are aiming at releasing it at the same
time
as FEST-Swing 1.0.
Support for JIDE/SwingX/Flamingo will come after 1.0 (because of time
constraints.)
About the forums, I agree, we should have something like that. My only concern
is
that people would have to look in two places for answers, etc. Probably we'll
stick
to the existing Google group for now.
About the direction of FEST, I'm 100% with you that we all need to discuss it.
I was
thinking about starting a thread in this mailing list after we release 1.0b1
(3rd or
4th week of July.)
Thank you so much Csabi for help and feedback!
Best regards,
-Alex
Original comment by Alex.Rui...@gmail.com
on 17 Jul 2008 at 9:27
Set the module as a label, instead of being part of the title.
Original comment by Alex.Rui...@gmail.com
on 1 Dec 2008 at 2:03
Hi Alex,
Please notify me if you start working on this. By posting a comment, for
example.
Thank you,
Csabi
Original comment by csaba.ju...@gmail.com
on 9 Jan 2009 at 8:26
[deleted comment]
Issue migrated to http://kenai.com/jira/browse/FEST-30
Original comment by Alex.Rui...@gmail.com
on 15 Feb 2009 at 7:13
Issue migrated to Issue migrated to http://jira.codehaus.org/browse/FEST-31
Original comment by Alex.Rui...@gmail.com
on 4 Mar 2009 at 1:42
Original issue reported on code.google.com by
Alex.Rui...@gmail.com
on 13 Jun 2008 at 7:10