Poll: UI Designer new features
Hello everyone,
As we're building the plan for Demetra, we'd like to request community feedback
on the major new UI Designer features that you consider the most useful.
If you had 20 votes, how would you spread them between features in the following
list (in no particular order)?
- Swing menu designer
- Run-time loading of .form files
- SWT support
- Reverse-engineering support (import Java code to .form file)
- Possibility to create and navigate to event handlers
- Support for non-visual components (possibility to drop any class to a form
and to set its properties in the designer)
- MIDlet form designer
- API for plugging custom components and component containers
- UI inspections (including automatic checking for UI guideline compliance)
- Support for nested forms and/or form inheritance
You may also add other features to the list if desired. Note that you don't
need to vote for removal of forms_rt dependency, complete support for all
Swing components and component features, and lots of usability improvements.
They'll be there whether you vote for them or not. :)
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
请先登录再写评论。
UI Inspections sounds like a great and unique feature, there are so many bad designed apps out there.
What is the:
- Swing menu?
- Runtime loading .forms?
Missed or forgoten features :)
- Standard layout managers
- Ability to plug custom layout manager
- Ability to visual edit The Pure Java code, instead of .form XML
- Rewrite algoritm of puttint components into (i want to put component into any Container, not into several hardcoded only)
Thanks!
If I would have 20 votes than I would give them all for this:
http://jformdesigner.com/
Check the new version (2.0) and see what does it mean "Develop Swing/GUI with pleasure!".
IMHO you should buy or copy it (regarding the usability).
I don't mean the "feature list" as the feature list or Eclipse is also big, but the
details and the smoothness of which each feature works.
You need to play with the jFormdesigner to "feel" what's missing from IntelliJ GUI designer.
Ahmed.
Hello Ahmed,
>> If you had 20 votes, how would you spread them between features in
>> the following list (in no particular order)?
>>
AM> If I would have 20 votes than I would give them all for this:
AM> http://jformdesigner.com/
AM> Check the new version (2.0) and see what does it mean "Develop
AM> Swing/GUI with pleasure!".
AM> IMHO you should buy or copy it (regarding the usability).
AM> I don't mean the "feature list" as the feature list or Eclipse is
AM> also big, but the
AM> details and the smoothness of which each feature works.
AM> You need to play with the jFormdesigner to "feel" what's missing
AM> from IntelliJ GUI designer.
We are already looking hard at JFormDesigner. We do not plan to buy it or
copy it, but we will definitely strive for the same level of polish and usability.
(And of course, "feel" is a very subjective issue, and a list of specific
problems in IDEA's UI designer that are handled better in JFormDesigner would
be a great help for us. Even if the list would be very long.)
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
Hello Alexey,
AE> What is the:
AE> - Swing menu?
See request IDEABKL-1249.
AE> - Runtime loading .forms?
See http://www.intellij.net/tracker/idea/viewSCR?publicId=28422
AE> Missed or forgoten features :)
AE>
AE> - Standard layout managers
Demetra will use GridBagLayout as the layout manager for generated code.
AE> - Ability to plug custom layout manager
What's the use case for this feature?
AE> - Ability to visual edit The Pure Java code, instead of .form XML
I'm afraid we'll not be able to implement support for visual editing of arbitrary
Java Swing code in Demetra timeframe.
AE> - Rewrite algoritm of puttint components into (i want to put
AE> component into any Container, not into several hardcoded only)
See "- API for plugging custom components and component containers"
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
Hello!
I've got one interesting idea, that (maybe) can help with creating better ui logics. I began to write an article about it, but it is in russian. In short: all logics (of one form or all forms in an application) can be presented as a state mashine. It is initiated with usual ui events. State mashine is good, because we implement it every time in about every interface. And it is easy to edit it (it can be presented as a graph). So, "ui logics creation tool" may be great addition to "ui design tool". As I think.
If it is interesting, I can send first edition of my article to you (may be you've already read it at rsdn inner forum).
--
Alexander Babaev
Than take a wide monitor and start in paralel IntelliJ GUI designer and
JFromDesigner and try to make the same panels/forms in both.
Also give this job and follow how it masters it to a totally newbie to InteliJ GUI Designer and
JFormDesigner.
You will see how he/she will get in a few minutes the job done with JFormDesinger
and with IntelliJ GUI designer will be totally frustrated because it behaves
in a totally unintuitive way.
The list would be too long also because the concepts behind IntelliJ GUI designer are totally twisted,
and unnatural (that twisted layout-ing concept). You can't fix something when the base concepts are
totally wrong.
Well, that's just MHO, but as long as IntelliJ GUI designer is not passing the "10 minutes test", no
one will really use it.
I brought IntelliJ in many teams I worked, but I couldn't convince one person to use the GUI
designer and no one found it usable so far - everybody got frustrated and dropped it.
So as a conclusion, "feeling" is very important, cause it's the same thing that made users switch
from JBuilder to IntelliJ(and not the very long feature lists).
Ahmed.
Hello Ahmed,
AM> The list would be too long also because the concepts behind IntelliJ
AM> GUI designer are totally twisted,
AM> and unnatural (that twisted layout-ing concept). You can't fix
AM> something when the base concepts are totally wrong.
OK, let's discuss the base concepts first. What exactly do you find twisted?
Do I understand correctly that the twisted thing is the requirement to drop
components in free-form layout first and then do "Lay out in a grid"? Will
it be better if we present the grid right from the start?
Are there any other concepts that you find twisted?
(My main goal currently is to understand how to achieve the maximum effect
for the UI Designer with a reasonable amount of effort. We do not plan to
rewrite the UI Designer from scratch, and we plan to reuse as much of the
existing codebase as possible. My current feeling is that there is a lot
which can be achieved by improving instead of rewriting, but I may be wrong
- that's why I initiated this discussion.)
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
+1 Though creating menus is a quite simple thing, this is certainly something the designer
lacks.
+5 for no more build-dependencies on javac2, jdom, bcel, etc.
-1 Is SWT that widely used? Wouldn't SWT programmers use Eclipse anyway?
+5 But I think that's only a good idea if this works sufficiently well with complex UIs of
real-world apps. If such an import still requires 80% of manual work I think it's not
worth to bother.
I like the current approach of the UI designer to be a UI "designer" only, but probably
such a tool needs to have that functionality.
Hmm, what's that good for?
+1 Sounds useful
Sounds interesting. How would that work and what would it check?
Sascha
Yes, this just one unnatural thing (but 'bangs' the user from the beginning),
and it's more evident when one adds a new component on the layouted form
(one would like to "insert" in the right place but it doesn't behave as
one would expect).
Of course it would be better. The behaviour of the grid
should be however dependent on the used LayoutManager combination.
(again, see JFormDesigner). Also offer those extra LayoutManagers,
cause they ease the work allot and are free.
1. The entire feedback from the GUI designer about what is the user doing
or what would the user intend/could to do. You can observe this feedback
very well in JFromDesigner - e.g. it's highlighted where something could
be placed. Not like in IntelliJ where after the users does something
just sees underlined with red in the component tree that somethings was wrong.
It's the entire concept of the "order of the designer actions". In IntelliJ
GUI designer it's always after the user does something, but a GUI designer
is a WYSIWYG so many of those "actions/feedbacks" should be before, so that
the user knows what possibilities he has or what would be the best solution without
having to do a lot of "do/undo" actions just to find out if something fits.
2. The entire 'binding' concept is unnatural and requires from the user too much
work where it wouldn't be required at all.
3. The level at which the GUI designer 'understands' components is very
poor(JTabbedPane is just one example). Many components need special handling cause they
behave in a special way so they should have special feedback in the designer view. It's not
everything about just 'setting properties', cause in this case one could just use the BeanBox.
4. The missing of JFrame and Menu Building and ContextdMenus support. It was always used as argument
against them that in a real application one would use 'frameworks', for them, but
this is simply not true. Besides, for tests and quick prototyping it's required that
one can 'click' a 'complete' prototype application.
5. An 'in designer' I18N support(just see how JFormDesigner does it - there are even
some flash demos about them).
6... There are many more but I suppose that it won't help to loose time with them since
even to implement the mentioned above would blow up any budget.
Well of course it's not my business, but my first idea was to 'buy' or 'license'
JFromDesigner cause it has all the above and many more. The author wants to make
JFormDesigner as plug-in for Eclipse (and IntelliJ later), so for me it sounds
logical that Jetbrains could use it, make the plug-in part and drop the existing GUI designer :).
Of course, my logic has nothing to do with business strategies of both companies :) - this
is just the perspective of a user that wants the best and to 'develop with pleasure' :).
Of course, I don't know the IntelliJ GUI designer code base, but I don't think
it's just about "a little usability" that must be programmed/improved.
Ahmed.
>> - SWT support
Not at all. Just see the last numbers:
http://weblogs.java.net/blog/hansmuller/archive/2005/10/official_swing.html
Ahmed.
Hello Ahmed,
>> Are there any other concepts that you find twisted?
>>
AM> 1. The entire feedback from the GUI designer about what is the user doing
AM> or what would the user intend/could to do. You can observe this feedback
AM> very well in JFromDesigner - e.g. it's highlighted where something could
AM> be placed.
Of course, presenting clear feedback about the possible actions and the result
of the action the user is currently performing is one of the most important
parts of UI designer usability. We'll definitely improve on that.
AM> 2. The entire 'binding' concept is unnatural and requires from the
AM> user too much work where it wouldn't be required at all.
Could you please elaborate? I can agree that there are many cases where binding
does not work smoothly (just as one example, changing a binding sometimes
leaves an unused field hanging around). But the concept itself seems quite
sound to me.
AM> 3. The level at which the GUI designer 'understands' components is very
AM> poor(JTabbedPane is just one example). Many components need special
AM> handling cause they
AM> behave in a special way so they should have special feedback in the
AM> designer view. It's not
AM> everything about just 'setting properties', cause in this case one
AM> could just use the BeanBox.
I totally agree with this. Indeed, there is a lot of things which can be
edited visually, and now are either not editable at all or editable by hand-typing
property values.
AM> 4. The missing of JFrame and Menu Building and ContextdMenus
AM> support. It was always used as argument
AM> against them that in a real application one would use 'frameworks',
AM> for them, but
AM> this is simply not true. Besides, for tests and quick prototyping
AM> it's required that
AM> one can 'click' a 'complete' prototype application.
This was on the list of items suggested for voting. I'd like to receive a
little more feedback before committing to implement this feature, but we're
definitely looking into this.
AM> 5. An 'in designer' I18N support(just see how JFormDesigner does it
AM> - there are even some flash demos about them).
Agreed. We can definitely improve on this.
AM> 6... There are many more but I suppose that it won't help to loose
AM> time with them since even to implement the mentioned above would blow
up any budget.
Why do you think so? However good JFormDesigner might be, it is (to the best
of my knowledge) being developed by a single person. We can definitely match
this amount of resources. :)
AM> Well of course it's not my business, but my first idea was to 'buy'
AM> or 'license'
AM> JFromDesigner cause it has all the above and many more. The author
AM> wants to make
AM> JFormDesigner as plug-in for Eclipse (and IntelliJ later), so for me
AM> it sounds
AM> logical that Jetbrains could use it, make the plug-in part and drop
AM> the existing GUI designer :).
AM> Of course, my logic has nothing to do with business strategies of
AM> both companies :) - this
AM> is just the perspective of a user that wants the best and to
AM> 'develop with pleasure' :).
Well, I certainly welcome the release of the JFormDesigner IDEA plugin. Giving
the user different kinds of pleasure to choose from is a nice thing. :)
>> My current feeling is that there is a lot which can be achieved by
>> improving instead of rewriting, but I may be wrong - that's why I
>> initiated this discussion.)
>>
AM> Of course, I don't know the IntelliJ GUI designer code base, but I
AM> don't think it's just about "a little usability" that must be
AM> programmed/improved.
No one's talking about "a little usability". All of the above is a big chunk
of work, but most of it is adding, not rewriting.
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
- Support for nested forms and/or form inheritance
Strong, particularly if you improve the palette system to make it easy to put custom-designed forms into a palette.
- UI inspections (including automatic checking for UI guideline compliance)
Could be extremely valuable, but realize that the real differentiator in the existing inspection system is that errors appear inline, rather than just in batch. If you can't highlight errors in the form editor, it's probably not worth the bother.
- Possibility to create and navigate to event handlers
- Support for non-visual components (possibility to drop any class to a form
and to set its properties in the designer)
These of course go together, and would be extremely strong.
Add all of these together, and you've got an actual programming environment for Swing work, rather than just a screen-painter. Split my votes equally among them.
--Dave Griffith
Hello Sascha,
>> - UI inspections (including automatic checking for UI guideline
>> compliance)
>>
SW> Sounds interesting. How would that work and what would it check?
In fact, the UI designer has had support for inspections since the very beginning
(see the "unbound field" highlighting). The new inspections would work in
a similar way - highlighting in the component tree (and possibly on design
surface) and possibility to run in batch mode.
Just a few of the things they could check:
- duplicate mnenonics (i18n aware);
- inconsistent capitalization of control text (i18n aware);
- incorrect border between component and edge of form.
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
Hello Dave,
DG> - UI inspections (including automatic checking for UI guideline
DG> compliance)
DG>
DG> Could be extremely valuable, but realize that the real
DG> differentiator in the existing inspection system is that errors
DG> appear inline, rather than just in batch. If you can't highlight
DG> errors in the form editor, it's probably not worth the bother.
This we can do already. Including quickfixes.
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
IMHO the binding concept at this level is superfluous.
Why should I bind when I respect conventions or when I just want to generate code?
Why should I learn, know, and loose time with them at this level?
Binding makes sense at different level e.g. using frameworks like JGoodies,JDNC,Actions, but
at this level binding starts to be some sort of RAD functionality, more suited if
IntelliJ would bundle an RCP platform with all the above.
Well, if one asks too much, in the end gets nothing :).
This was also the case with the genesis of IntelliJ GUI designer:
- many were against cause it might be a flop like the one from JBuilder, others
said that is simply impossible. I was for the GUI designer (and JFormDesinger
is the proof that is possible).
- one of the CEOs promised that the IntelliJ GUI designer will be as innovative
as IDEA was and if someone can do it, than Jetbrains :). You can find those statements on the forum
:). Unfortunately the first group of people were right - it turned out to be unusable in practice.
- everytime people asked about WYSIWYG in other areas than Swing (e.g. HTML/XHTML/JSF) they
were refused with the argument that it will be the same unusable thing like the GUI Builder.
One person? Maybe(although others contributed as well), but:
- since when is that person working on that tool? Do you have a 2,3 years timeframe?
- it has no 'legacy code' and IDE dependent constraints( I still think that
the migration of Fabrique as plug-in to IDEA was the last nail in Fabrique's coffin).
- Not to mention about intermittent pauses from the various IDEs that break the 'smooth' workflow,
so JFormDesigner didn't lost time with such problem.
- the documentation is beautiful and detailed.
So you would need to outbid all the above :).
I'm convinced you could, but I suppose even with Fabrique the problem wasn't the "amount of
resources", was it?
>>> My current feeling is that there is a lot which can be achieved by
>>> improving instead of rewriting, but I may be wrong - that's why I
>>> initiated this discussion.)
Of course, you know better if this means 'adding' vs 'rewriting' from the IntelliJ source code
perspective :).
Ahmed.
Hello Ahmed,
>> AM> 2. The entire 'binding' concept is unnatural and requires from
>> the
>> AM> user too much work where it wouldn't be required at all.
>> Could you please elaborate? I can agree that there are many cases
>> where
>> binding does not work smoothly (just as one example, changing a
>> binding
>> sometimes leaves an unused field hanging around). But the concept
>> itself
>> seems quite sound to me.
AM> IMHO the binding concept at this level is superfluous.
AM> Why should I bind when I respect conventions or when I just want to
AM> generate code?
AM> Why should I learn, know, and loose time with them at this level?
Sorry, I still don't quite follow. Binding is very simple: it's a way to
tell the IDE "this UI component should be accessible as that field in my
Java class". Is that too much to learn? Where do you lose time? And the main
question: what do you suggest as a replacement?
>> However good JFormDesigner might be, it is (to the best of my
>> knowledge) being developed by a single person.
>>
AM> One person? Maybe(although others contributed as well), but:
AM> - since when is that person working on that tool? Do you have a
AM> 2,3 years timeframe?
No, we have the timeframe of a regular IDEA release, but the UI designer
development in Demetra does not start from scratch.
AM> - it has no 'legacy code' and IDE dependent constraints( I still think
that
AM> the migration of Fabrique as plug-in to IDEA was the last nail in Fabrique's
coffin).
This was not a deciding factor for Fabrique, and will not be a deciding factor
for the UI designer.
AM> - Not to mention about intermittent pauses from the various IDEs
AM> that break the 'smooth' workflow,
AM> so JFormDesigner didn't lost time with such problem.
AM> - the documentation is beautiful and detailed.
AM> So you would need to outbid all the above :).
We'll try to. And we inherited some great technical writers from Fabrique.
:)
>> We can definitely match this amount of resources. :)
>>
AM> I'm convinced you could, but I suppose even with Fabrique the
AM> problem wasn't the "amount of resources", was it?
No, it was not the main problem. But the scope of the UI designer improvements
is much smaller, and much less is at stake. I can't promise to deliver the
best UI designer in the world, but there's so much that could be improved
in the current UI designer that there will be at least some improvement
in any case. :)
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
Hello Alexander,
AB> I've got one interesting idea, that (maybe) can help with creating
AB> better ui logics. I began to write an article about it, but it is in
AB> russian. In short: all logics (of one form or all forms in an
AB> application) can be presented as a state mashine. It is initiated
AB> with usual ui events. State mashine is good, because we implement it
AB> every time in about every interface. And it is easy to edit it (it
AB> can be presented as a graph). So, "ui logics creation tool" may be
AB> great addition to "ui design tool". As I think.
This might be a very good idea, but I'm afraid this is far outside the scope
of what can be planned for the next version of IDEA.
-
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
>>> AM> 2. The entire 'binding' concept is unnatural and requires from
>>> the
>>> AM> user too much work where it wouldn't be required at all.
>>> Could you please elaborate? I can agree that there are many cases
>>> where
>>> binding does not work smoothly (just as one example, changing a
>>> binding
>>> sometimes leaves an unused field hanging around). But the concept
>>> itself
>>> seems quite sound to me.
Simply drop binding, or hide it as default. If the user is using a simple
convention, e.g. the same name for the form as for the class and form fields
as for class attributes, than let IDEA do everything and not bother the users
to do this on every field.
Why do users have to do this activity on every field just because some others
would like for one field from hundred to use another naming?
This is done right with JFromDesigner(and as most users expect): the complete class
is generated from the form, and one can choose a JFrame or JPanel or JDialog,
(and AFAIK in future from other higher level templates).
Also 'Generate GUI into source code' should be the default, since most users want to know
what and how the GUI Builder does under the hood.
>>> We can definitely match this amount of resources. :)
>>>
Well, that was my point from the beginning: some improvement it's not worth,
the effort.
Most people use IDEA because it's the best and not because it does some things.
Hence the idea that if you can't do it at least as good, than use/buy/license the
alternative. It's not worth just to fill the feature list, cause it's not about
feature lists, as Rob Harwood too pointed here:
http://idea-log.blogspot.com/2005/09/intellij-idea-interview-transcript.html
Ahmed.
Well, it may be a new "standard" plugin. I did test project, using this concept. It works very well. But whole library is too complex for me, because I've got a lot of another work to do. I think, that this idea is not very complex.
This thing will be unique and it will help to create simple, reusable interface logics easily.
Wouldn't be a better place for this a DSL with MPS? (instead of the GUI Builder?).
Ahmed.
I don't think so. MPS is a common thing for creating "anything", and UI logics - is a concrete, very serious problem, especially for newbies. Logics, that is created by them is (usually) very hard to refactor, reuse and understand. Even if all the logics is described in a task, there are many ways to implement it and most of the ways are not acceptable.
GUI builder is usually associated with "UI drawer and data/events binder", but I can't understand - why not to add functionality, other than "drawing" there.
5 Swing menu designer
5 Run-time loading of .form files
0 SWT support
0 Reverse-engineering support (import Java code to .form file)
2 Possibility to create and navigate to event handlers
-- Action support would be useful, but I don't want event handler code in the
gui designer
? Support for non-visual components (possibility to drop any class to a
form and to set its properties in the designer)
-- If this means interfacing with JGoodies Binding or something like that,
then +5 and take 5 votes from my other votes :)
0 MIDlet form designer
3 API for plugging custom components and component containers
3 UI inspections (including automatic checking for UI guideline compliance)
2 Support for nested forms and/or form inheritance
Why reverse is 0?
Alexey Efimov wrote:
I think the implementation would end up sucking because there is no standard for
how to write layout code, so IDEA would probably try guessing what the layout
was like. I haven't written manual layout code since UI Designer was in EAP, but
I think if I did, it would be too dynamic for IDEA to be able to parse into
something that I could usefully modify in the UI designer.
Hello Keith,
>> Why reverse is 0?
>>
KL> I think the implementation would end up sucking because there is no
KL> standard for how to write layout code, so IDEA would probably try
KL> guessing what the layout was like. I haven't written manual layout
KL> code since UI Designer was in EAP, but I think if I did, it would be
KL> too dynamic for IDEA to be able to parse into something that I could
KL> usefully modify in the UI designer.
The main motivation for the reverse engineering feature is the possibility
to import code generated by other UI designers (JBuilder etc.), not hand-coded
layout code. There exist a number of other GUI designers which support generic
import and can handle code generated by many different IDEs, so this task
should be feasible for IDEA as well.
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
>>> Why reverse is 0?
>>>
Than don't call this "reverse engineer", but:
"JBuilder jbInit() to IntelliJ Forms converter" :).
Ahmed.
Hello Ahmed,
>> The main motivation for the reverse engineering feature is the
>> possibility to import code generated by other UI designers (JBuilder
>> etc.), not hand-coded layout code. There exist a number of other GUI
>> designers which support generic import and can handle code generated
>> by many different IDEs, so this task should be feasible for IDEA as
>> well.
>>
AM> Than don't call this "reverse engineer", but:
AM> "JBuilder jbInit() to IntelliJ Forms converter" :).
Naming is subject to further discussion, but we definitely want this feature
to be reasonably generic and to support code generated by different tools.
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
>>> The main motivation for the reverse engineering feature is the
>>> possibility to import code generated by other UI designers (JBuilder
>>> etc.), not hand-coded layout code. There exist a number of other GUI
>>> designers which support generic import and can handle code generated
>>> by many different IDEs, so this task should be feasible for IDEA as
>>> well.
>>>
Well, it might be even an external tool (like in the case of some concurent GUI desingers :) ).
Considering that there are more sources to import from, maybe it might make sense just to
describe exactly(I mean in a document) the IntelliJ format, and make as an example
only for one, e.g. JBuilder format, and let the community do the rest for all the other
possible builders :) they might need.
Ahmed.
Ahmed,
For what it's worth, I agree completely that the UI designer should not
just try to get some improvement, it should strive to be the best. I
don't have the background or knowledge to know if buying JFormDesigner
is a feasible thing, but strategically it is something worth
investigating. When there are already JFormDesigner, and now Matisse, it
simply does not make sense to put effort into the UI designer unless
JetBrains strives to make it the best (or at least one of the very
best). From your comments, it sounds clear to me that the UI designer is
seriously lacking in usability, and I wish that the developers involved
will take that problem seriously. If you want my honest opinion,
ignoring serious usability problems was the true cause of Fabrique's
failure. I know there are people at JetBrains that disagree with me, but
that's my opinion.
--
Rob Harwood
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"