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!"
请先登录再写评论。
Dmitry Jemerov (JetBrains) wrote on 19/10/05 20:32:
+1 - done in a generic manner similar to forms where a menu is bound to
a class which can be reused by popups or main menus.
How would this alter the current byte-code modification process? Would
forms extend a base form and not have code-injected, or have code
"generated" still?
Yes - but only if you support plugable event types. Netbeans forces the
use of anonymous ActionListeners throughout the generated form code, but
I really don't like that. Hooking into using Action classes (be they
inner classes of the form, separate classes) as well as older style
ActionListeners would be good.
Definitely - as well as intentions - "surround with" would be a favorite.
FACTORY METHODS
I'm sure one of the biggest complaint against the UI designer is that
you can't use factory methods to create components. I'm sure Thomas
Singer will have a lot to say on this matter...
Mark
I'd also argue that it makes more sense to integrate well with existing, innovative gui builders than continue with your own, unless you can bring something truly unique to the table.
Argument 1: Take advantage of Best of Breed recognition
You didn't create a new Ant, you didn't create a new JUnit, you didn't create new app servers...you integrated with the best of breed out there.
I have no experience with JFormDesigner, but for sake of argument, let's assume it's the greatest thing since sliced bread. I'd be more interested in an IDE that had a really slick integration with the undisputed champion of gui builders, than an IDE that has an in-house tool that's similar and "has some of the same features". It's analogous to the stereos in cars: good = "8 speaker stereo", better = "BOSE 8 speaker stereo".
Argument 2: User should have choice of GUI builder paradigm
If all GUI builders pretty much worked alike, and the differentiation between them was simply the level of polish, then GUI builders would pretty much be a commodity item, and I'm confident you could write your own that's as polished as anyone elses. But GUI builders are not that homogenous. Some GUI builders really try and attack the problem from unique angles. As a user, I'd love to say "I like the way does things, and my IDE integrates really well with that."
Argument 3: GUI builders don't benefit much from pervasive IDE integration
Some features make sense to develop from scratch, because they gain value by being so closely integrated with the core IDE functions. For example, the code beautifier. Maybe it isn't the most configurable, feature-rich beautifier on the market, but it makes up for that by pervading the editor so thoroughly. I don't think GUI builders are necessarily like that. They are almost always their own isolated, mini-development environments, and so not much is lost by choosing to integrate with an external product.
I agree with Russell here. I have used JFormDesigner, and it's a complete
pleasure to use. While I'm not saying JetBrains couldn't copy it, and even
add some nice new features, I feel like it would be a lot of re-inventing
the wheel.
Personally, I would love to see JetBrains license JFormDesigner and then
integrate the two (perhaps just assist Karl (the author) with writing the
plugin for IDEA).
Tobin
+1
+1, inject ui file is also ok.
+5
sounds ok, but are you going to seperate ui from code?
+10 very useful, just like I need to inherit class.
I still have some points, so I would give it to the UI designer itself. Unlike the other commentors, I like the product very much and find it very productive(not the first glance), with some integration of my own file templates/live templates
-1
What is the need for it?
+/-0
-1
-10 (does not have to do with GUI directly, but instead with underlying
logic!)
-10 (does not have to do with GUI at all)
+/-0
No API, but allow to use own components which do NOT follow the
bean-concept (e.g. a JTable-subclass which requires a special table
model in the constructor).
What exactly do you mean?
+1 for nested panels (like in JFormDesigner)
Please think about to make switching from hand-coded GUIs very easy:
- No limitation regarding the used components (if they are derived from
JComponent).
- Make code reuse very easy, e.g. using a special table instead of
normal JTable.
- Allow own creation code of components (e.g. using a component factory)
Tom
Thomas Singer (MoTJ) wrote:
>> - Run-time loading of .form file
It would mean you don't need a special compiler or special ant task to compile.
Hello Thomas,
>> - Possibility to create and navigate to event handlers
>>
TS> -10 (does not have to do with GUI directly, but instead with
TS> underlying logic!)
Any other arguments against this feature?
Note that it says exactly what it says: possibility to create an event handler
for the control you currently have selected in the designer, and possibility
to navigate to event handlers which are already defined for the control.
We do not have any plans to put anything related to event handlers into .form
files: the entire code for assigning event handlers will stay in the source
code files.
In the form that we suggest, I think this feature would be very convenient
and won't break the "purity" of the UI designer in any significant way.
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
It would lead unexperienced developers to write bad code.
Example:
You have a button selected and the unexperienced developer would think
adding a mouse-click-listener would be the right choice of performing
the useful stuff. Instead it would be appropriate to first create an
action that does the useful stuff and then create a button out of that
action.
Tom
Hello Thomas,
>> Any other arguments against this feature?
>>
TS> It would lead unexperienced developers to write bad code.
TS>
TS> Example:
TS> You have a button selected and the unexperienced developer would think
TS> adding a mouse-click-listener would be the right choice of performing
TS> the useful stuff. Instead it would be appropriate to first create an
TS> action that does the useful stuff and then create a button out of
TS> that action.
Indeed, in some cases creating an action would really be the appropriate
way of adding event handling code. In other cases, an action would be pure
overhead and a simple listener would be sufficient.
Of course, there is no reason for IDEA not to support creating and navigating
to actions in the same way as for listeners.
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
Dmitry Jemerov (JetBrains) wrote:
+1
+3
+1 (general alien gui bean support, with custom properties)
+4
+3
+1
+1
+1
+1
+2
- color setting, font setting
- binding of properties to constants and java code
Hello Thomas,
TH> - color setting, font setting
This is definitely planned.
TH> - binding of properties to constants and java code
What's the advantage of doing this in the UI designer and not in Java code?
Leaving "purity" and implementation details aside, is it really convenient
to edit Java code in a tiny edit box embedded in the property editor?
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
Dmitry Jemerov (JetBrains) wrote:
Great ;)
Imagine color and font properties are configured via central
constants/parameters. Traversing through all components is annoying then.
I agree including an editor in the UIDesigner might be overdressed.
Thomas
Hello Thomas,
>> TH> - binding of properties to constants and java code
>>
>> What's the advantage of doing this in the UI designer and not in Java
>> code? Leaving "purity" and implementation details aside, is it really
>> convenient to edit Java code in a tiny edit box embedded in the
>> property editor?
>>
TH> Imagine color and font properties are configured via central
TH> constants/parameters. Traversing through all components is annoying
TH> then. I agree including an editor in the UIDesigner might be
TH> overdressed.
Indeed, for colors and fonts it makes sense to implement special selectors
(for example, selectors that allow to take component colors and fonts from
the Swing UIManager constants). Most likely we will provide an OpenAPI for
implementing such customized property edtitors, but we don't plan to provide
the possibility to set property values as arbitrary Java code directly from
the designer.
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
Tobin Juday wrote:
I just want to mention the commercial aspect to all this discussion,
only JFormDesigner is good might not hinder jetbrains to develop his own
gui designer. I think it is very important for jetbrains to integrate
its own because they have to compete with even bigger products on the
market (IBM Websphere - Eclipse, Netbeans). I think there is no doubt
about this.
They have to get the source, if there is a way to do this with
JFormDesigner only knows Karl and Jetbrains. ;)
JM2C
Thomas
How they should be displayed in the WYSIWYG-designer?
Tom
Hello Thomas,
>> Imagine color and font properties are configured via central
>> constants/parameters.
>>
TS> How they should be displayed in the WYSIWYG-designer?
Either not displayed at all, or (optionally) displayed with some overlaid
tags.
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
Just for kidding, Dmitry do you use th e GUI Designer in your team to
develop GUIs like Idea itself?! Perhaps this might convince others. ;)
Thomas
Hello Thomas,
TH> Just for kidding, Dmitry do you use th e GUI Designer in your team
TH> to develop GUIs like Idea itself?! Perhaps this might convince
TH> others. ;)
Of course, most of the dialogs in IDEA itself are created using IDEA's UI
designer since version 4.0, when the UI Designer first appeared.
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
Should I give you examples of where they look ugly?
Tom
This is by no means an argument.
Just because one is 'eating it's own dog food' it doesn't mean that it really 'tastes' :).
The "10 minutes test" is the most basic and simple argument, and there
the Intellij GUI Designer fails, period.
Ahmed.
Hello Thomas,
>> Of course, most of the dialogs in IDEA itself are created using
>> IDEA's UI designer since version 4.0, when the UI Designer first
>> appeared.
>>
TS> Should I give you examples of where they look ugly?
Feel free to file JIRA requests for those examples (one per dialog), or point
to the existing requests. We are certainly aware of some problems (code style,
ahem...), but you may have something different in mind.
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
Hello Ahmed,
AM> The "10 minutes test" is the most basic and simple argument, and
AM> there the Intellij GUI Designer fails, period.
Could you please hold your criticisms of our UI designer until we release
the first EAP of Demetra? :)
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
Dmitry Jemerov (JetBrains) wrote:
Maybe it would be easier to wait if we knew when :)
E.g. IDEA-5650
IDEA-5651
IDEA-5652
If they will be solved in an acceptable time frame, I'm sure I could add more.
Tom
Please don't understand me wrong, I don't want to show how incapable
Jetbrains are, I just want to give examples that a too simple GUI-designer
makes it very hard to create a consistent GUI application.
Tom
>> Hello Ahmed,
>>
>> AM> The "10 minutes test" is the most basic and simple argument, and
>> AM> there the Intellij GUI Designer fails, period.
>>
>> Could you please hold your criticisms of our UI designer until we
>> release the first EAP of Demetra? :)
>>
Exactly :).
Please, please give us some 'hints' :).
We are like little children: no chocolate, no fun :)
Ahmed.
Hello Thomas,
TS> Please don't understand me wrong, I don't want to show how incapable
TS> Jetbrains are, I just want to give examples that a too simple
TS> GUI-designer makes it very hard to create a consistent GUI
TS> application.
And that's exactly why we are spending effort right now on improving the
UI designer. And one of the features we plan to add is UI inspections, which
will detect at least some of the problems you have reported.
However, it's funny to note that of the dialogs you have reported (Modules,
Change Method Signature and Plugin Manager), only the Plugin Manager dialog
was created in the UI designer, and most of the problems you have reported
with it are related to JTable setup, which is not done in the UI designer
anyway.
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
Ahmed Mohombe wrote:
>> Dmitry do you use th e GUI Designer in your team to develop GUIs like
>> Idea itself?! Perhaps this might convince others. ;)
Hi Ahmed, sorry but now I have to interrupt - I totally disagree, please
use arguments. Believe it or not I used all the visual designer (Visual
Age, Netbeans, Eclipse AND JFormDesigner) and I always stepped back to
Idea because of its easiness and clarity and even your criticized
bindings I do love, it keeps the code quite clean for complex layouts.
And for the real complex things you have to use GridBagLayout for your
own, every designer has its borders.
The "10 minutes test" is bullshit, if I want to work with something
seriously I take the time to investigate.
Thomas
PS: Visual Age was impressive for its time.
>>> Dmitry do you use th e GUI Designer in your team to develop GUIs like
>>> Idea itself?! Perhaps this might convince others. ;)
>>
>>
>> This is by no means an argument.
>> Just because one is 'eating it's own dog food' it doesn't mean that it
>> really 'tastes' :).
>>
>> The "10 minutes test" is the most basic and simple argument, and there
>> the Intellij GUI Designer fails, period.
In fact I did - previously on these forums. This problem was discussed allot even
few years ago. I didn't wanted to write novels again here.
I also used all of them, but in production, not just toying around. Also worked
on an company internal visual designer(derivate from an OS one).However, when we got JFromDesigner,
we dropped our own :).
Than it seems you never tried JFromDesigner. This is what I'm using now and I'm very
productive with it. Even if it's not perfect, at the moment it gives the most of
the productivity. All users I know just love it and they are also more productive.
No it's not. I did investigate, but most of the users won't.
The "10 minutes test" it showing if something is 'getting in the way' or not, the simplicity
and efficiency of a tool. It's also the 'first impression' and for humans this is very relevant :).
This test is a very valid argument, and IntelliJ is the best in it from all IDEs (but as I said -
except GUI Designer).
I suppose this is why, when someone really gives IntelliJ a try (not just toying around, but
working with it), after a very short time, doesn't want to use something else and becomes addicted :).
I convinced many programmers to use IntelliJ, and this was the best way to convince them. As I said,
I could convince no one to use the IntelliJ GUI designer because (as an opposite to the rest of
IDEA) it was 'getting in the way' and users got frustrated.
These problems were however discussed and Jetbrains knows now about them.
Now we are waiting for the Demetra EAP to see what's new and how are the issues addressed :).
Ahmed.
Funny :) I try to search for advertised JFormDesigner and http://www.google.com.ua/search?hl=en&q=JFromDesigner&btnG=Google+Search points to this thread :)