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!"


70 comments
Comment actions Permalink

Dmitry Jemerov (JetBrains) wrote on 19/10/05 20:32:

- Swing menu designer


+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.

- Run-time loading of .form files


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?

- Possibility to create and navigate to event handlers


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.

- UI inspections (including automatic checking for UI guideline compliance)
- Support for nested forms and/or form inheritance


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

0
Comment actions Permalink

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.

0
Comment actions Permalink

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


0
Comment actions Permalink

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

+1

- Run-time loading of .form files

+1, inject ui file is also ok.

- SWT support
- Reverse-engineering support (import Java code to
.form file)
- Possibility to create and navigate to event
handlers

+5

- Support for non-visual components (possibility to
drop any class to a form
and to set its properties in the designer)

sounds ok, but are you going to seperate ui from code?

- 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

+10 very useful, just like I need to inherit class.


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!"


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

0
Comment actions Permalink

- Swing menu designer


-1

- Run-time loading of .form file


What is the need for it?

- SWT support


+/-0

- Reverse-engineering support (import Java code to .form file)


-1

- Possibility to create and navigate to event handlers


-10 (does not have to do with GUI directly, but instead with underlying
logic!)

- Support for non-visual components (possibility to drop any class to a
form and to set its properties in the designer)


-10 (does not have to do with GUI at all)

- MIDlet form designer


+/-0

- API for plugging custom components and component containers


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).

- UI inspections (including automatic checking for UI guideline compliance)


What exactly do you mean?

- Support for nested forms and/or form inheritance


+1 for nested panels (like in JFormDesigner)

You may also add other features to the list if desired.


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

0
Comment actions Permalink

Thomas Singer (MoTJ) wrote:
>> - Run-time loading of .form file

What is the need for it?


It would mean you don't need a special compiler or special ant task to compile.

0
Comment actions Permalink

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!"


0
Comment actions Permalink

Any other arguments against this feature?


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

0
Comment actions Permalink

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!"


0
Comment actions Permalink

Dmitry Jemerov (JetBrains) wrote:

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

+1

- Run-time loading of .form files

+3

- SWT support

+1 (general alien gui bean support, with custom properties)

- Reverse-engineering support (import Java code to .form file)

+4

- Possibility to create and navigate to event handlers

+3

- Support for non-visual components (possibility to drop any class to a
form and to set its properties in the designer)

+1

- MIDlet form designer

+1

- API for plugging custom components and component containers

+1

- UI inspections (including automatic checking for UI guideline compliance)

+1

- Support for nested forms and/or form inheritance

+2

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. :)


- color setting, font setting

- binding of properties to constants and java code

0
Comment actions Permalink

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!"


0
Comment actions Permalink

Dmitry Jemerov (JetBrains) wrote:

TH> - color setting, font setting

This is definitely planned.


Great ;)


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?


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

0
Comment actions Permalink

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!"


0
Comment actions Permalink

Tobin Juday wrote:

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


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


0
Comment actions Permalink

Imagine color and font properties are configured via central
constants/parameters.


How they should be displayed in the WYSIWYG-designer?

Tom

0
Comment actions Permalink

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!"


0
Comment actions Permalink

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

0
Comment actions Permalink

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!"


0
Comment actions Permalink

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.


Should I give you examples of where they look ugly?

Tom

0
Comment actions Permalink

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.

Ahmed.

0
Comment actions Permalink

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!"


0
Comment actions Permalink

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!"


0
Comment actions Permalink

Dmitry Jemerov (JetBrains) wrote:

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? :)


Maybe it would be easier to wait if we knew when :)

0
Comment actions Permalink

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.


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

0
Comment actions Permalink

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

0
Comment actions Permalink

Dmitry Jemerov (JetBrains) wrote:

>> 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? :)
>>


Maybe it would be easier to wait if we knew when :)

Exactly :).
Please, please give us some 'hints' :).

We are like little children: no chocolate, no fun :)

Ahmed.

0
Comment actions Permalink

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!"


0
Comment actions Permalink

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. ;)


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.


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.

0
Comment actions Permalink

>>> 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.


Hi Ahmed, sorry but now I have to interrupt - I totally disagree, please
use arguments.

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.

Believe it or not I used all the visual designer (Visual
Age, Netbeans, Eclipse AND JFormDesigner)

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 :).

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.

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.

The "10 minutes test" is bullshit, if I want to work with something
seriously I take the time to investigate.

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.

0
Comment actions Permalink

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 :)

0

Please sign in to leave a comment.