UI Designer: feedback request

Hello everyone,

Now that the UI Designer has reached somewhat stable state in recent builds,
we'd like to request feedback on its current state. I'm particularly interested
in discussing the user experience for placing components on forms and editing
the form layout, although feedback on all other features is also very much
welcome.

It's important for us to receive the feedback now, because now we still have
time to make major changes to the UI Designer user experience if it turns
out to be necessary.

Thanks in advance for all your comments.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0
39 comments

Dmitry, just a question before taking a look at the designer: does it now
allows to use existing component references?

Tom

0

Hello Tom,

T> Dmitry, just a question before taking a look at the designer: does it
T> now allows to use existing component references?

If you mean our discussion at http://www.jetbrains.net/jira/browse/IDEA-6728
- the situation hasn't changed much. If you need to use aggregate components,
you should create a form in the UI Designer containing the components to
be aggregated (a label and a text field in this case), and add instances
of that form to your other forms using the "nested forms" feature. The additional
layout support promised in my comment has been implemented (as "Align grid
with parent" checkbox in the layout properties).

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0

Can the UI Designer be used to generate layouts using TableLayout:

https://tablelayout.dev.java.net/

0

Hello Ted,

TH> Can the UI Designer be used to generate layouts using TableLayout:
TH>
TH> https://tablelayout.dev.java.net/

Currently we have no plans to support non-standard layout managers except
for our own GridLayoutManager (which was used in IDEA 5.0 and earlier versions).
However, if there is sufficient interest, we can provide OpenAPI so that
support for other layout managers can be added by third-party plugins.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0
Avatar
Matthew Montgomery

Is it planned to support more border options? The UI Designer exposes None, Bevel Lowered, Bevel Raised and Etched. I dislike the default "None" as there really is a border being rendered. In the small amount of Swing coding I have done, I like to use EmptyBorder and LineBorder to produce a cleaner layout.

I am curious as to the intent of the UI Designer here. Should custom borders really be set in a sort of secondary setup UI method? Or, am I missing this ability in the UI Designer as it stands now?

I have attached two screen shots illustrating the difference.

--
Matthew



Attachment(s):
default-borders.png
custom-borders.png
0

Matthew, I don't think, one should use borders or colors "on demand" in a UI
designer. I found it much more useful to define constant spaces for ALL
dialogs, e.g. left=12, top=12, right=13, bottom=13 as the outer (empty)
border and, e.g., 2 pixels between belonging components and 8 or 16 pixels
between unrelated components. But IMHO this should not need to be available
from the UI Designer, because it should be equal for ALL dialogs and hence
better is placed in a central place of your application. This makes it very
easy to change the values later if needed.

Do you know the birthday invitations you get from new Word-users, in the
full-scale color-range, using 5 to 10 different fonts and font sizes? A GUI
for professional applications should NOT look similar.

Tom

0
Avatar
Matthew Montgomery

Matthew, I don't think, one should use borders or
colors "on demand" in a UI
designer. I found it much more useful to define
constant spaces for ALL
dialogs, e.g. left=12, top=12, right=13, bottom=13 as
the outer (empty)
border and, e.g., 2 pixels between belonging
components and 8 or 16 pixels
between unrelated components. But IMHO this should
not need to be available
from the UI Designer, because it should be equal for
ALL dialogs and hence
better is placed in a central place of your
application. This makes it very
easy to change the values later if needed.


I guess I wonder equally about the best practice in this area. A constant spacing between components etc... is ideal. I have seen applications where somthing is off by a single pixel and it irratates me to no end.

I played around with Apple's Interface Builder and really liked how they implemented the guides as you dragged components around.

When I have hand coded Swing UIs I used constants for spacing similar to what you describe. But I think setting something like this in the UI Designer could be done well and globally for that matter.

Does JFormDesigner support this sort of thing?

Do you know the birthday invitations you get from new
Word-users, in the
full-scale color-range, using 5 to 10 different fonts
and font sizes? A GUI
for professional applications should NOT look
similar.


Oh I completely agree.

Do note that I spend pretty much all of my time coding J2EE. I am by no means a Swing expert, only a person who hates sloppy GUIs. :)


--
Matthew

0

Does JFormDesigner support this sort of thing?


JFormDesigner supports FormLayout's constants.

Do note that I spend pretty much all of my time coding J2EE. I am by no
means a Swing expert, only a person who hates sloppy GUIs. :)


Well, for me it's the opposite. Developing web-application causes me some
head-aches because of the fragility (just like refactoring in the pre-IDEA
days).

Tom

0

Hello Matthew,

MM> Is it planned to support more border options? The UI Designer
MM> exposes None, Bevel Lowered, Bevel Raised and Etched. I dislike the
MM> default "None" as there really is a border being rendered. In the
MM> small amount of Swing coding I have done, I like to use EmptyBorder
MM> and LineBorder to produce a cleaner layout.
MM>
MM> I am curious as to the intent of the UI Designer here. Should custom
MM> borders really be set in a sort of secondary setup UI method? Or, am
MM> I missing this ability in the UI Designer as it stands now?

Yes, we plan to add support for other border types and border properties
in Demetra. Currently you can set up custom borders from Java code.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0

FYI, I have provided feedback as a comment on your blog entry: http://blogs.jetbrains.com/yole/archives/000112.html (as yet, the comment is still in review, but I'm sure it'll show up eventually).

0

Hi!

I have some feedback/questions about GUI Designer in Demetra EAP.

First of all, let me say, that in my opinion GUI Designer has greatly improved. I was very disappointed with the version shipped with IntelliJ 4.5 and I am glad to see steady improvement in recent builds of Demetra.

Questions/Complains:

1. Creation of subcalsses of Swing components.

On an ideological level, why should GUI Designer (i.e., visual layout tool), pretending to be most usable & productive one, restrict me in what I can create and what I can not? If I am replacing JTextField with MyCustomTextField and not violating JTextField contract and it's interaction with layout manager, why should anybody be worried about it?

On a practical level, today we (team of ~40 programmers) have code-base with hundreds of forms created with Sun1 (NetBeans predecessor), using custom creation code to create all kinds of custom components. Often we need to use non-default constructor for our components or use factory to create one of a family of components. We'd like to use IntelliJ GUI Designer for all of our GUI development. For us missing of custom creation of components is a show-stopper. What we really need, is a possibility to replace the code JPanel panel = new JPanel(), generated by IntelliJ, with a JPanel panel = createCustomPanel(). The createCustomPanel() method may be abstract. It will be implemented in a class, derived from a class bound to a form. In addition, we need a possibility to call $$$SetupUI$$$ method after initialization of the bound class with parameters, transferred by non-default constructor, rather than in the initialization block. If the price to pay for this feature is to drop code injection into .class files, we are ready to pay this price. Why not add these capabilities as an option, disabled when selecting GUI generation into binary class files? (I am attaching the form with proposed changes)

2 Form migration.

Do I understand properly, that migration utility will use only basic swing classes to build form from running GUI application? If at certain level of hierarchy I have control with class, derived from JPanel (for example, custom histogram control), will it be replaced with simple JPanel?


3. Some usability improvement suggestions:

- Add project level settings page for GUI defaults (such as borders, offsets, margins, gaps), similar to coding style pages.

- Enable to select/use custom Look and Feel.

- Enable to change default size policy of existing palette components.

- Enable editing of properties of multiple selected components at once (relevant for anchor, insets, margins, sizes, size policies, visibility, enable flag and so on).

- Enable in-place editing of margins & sizes (as in NetBeans editor)

- Enable to change layout of non-empty container (build 5181 complains about this). Old constraints should be discarded; all components should be laid out according to default constraints of a new layout.



Attachment(s):
form.java
0

Now that the UI Designer uses ASM, has the bcel.jar included with IDEA become obsolete? Also, while I'm looking at the lib dir, isn't servlet-api.jar completely included in javaee.jar? And is oromatcher.jar still being used, not for searching I believe?

Bas

0

Hello Bas,

BL> Now that the UI Designer uses ASM, has the bcel.jar included with
BL> IDEA become obsolete? Also, while I'm looking at the lib dir, isn't
BL> servlet-api.jar completely included in javaee.jar? And is
BL> oromatcher.jar still being used, not for searching I believe?

BCEL will be removed in the final release of 6.0 (there's still a usage or
two of some of its utility functions, as far as I know). As for servlet-api
and oromatcher, this is not really about the UI Designer. :)

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0

Feature request:

When editing the text of a component I would like to be able to directly
edit the key name (when using a resource bundle). This would be useful
when copy pasting the key from somewhere else, for example.

By the way, the usage search on changing the value text of a key is great!

Bas

0

The "Create Property" dialog doesn't warn on creating a new key with the
same name as an already existing key.

To reproduce:
1. edit the text of an ui component
2. select the resource bundle radio button and choose a bundle
3. go to the "Chooser Value" dialog ("..." button for "key:" text field)
(strange name for that dialog btw)
4. click the "New Property..." button and create a property with an
existing name.

result: a new property with the same name is created ("duplicate
property key" warning in the property file).
expected: "property key already exists" warning


Bas

0

Form Preview doesn't work with nested forms.

Sascha

0

Hello Sascha,

SW> Form Preview doesn't work with nested forms.

I know that. :) A JIRA request won't hurt as a reminder.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0

I like the new option to navigate from a UI component to it's Listener.

It would be good if, while in the Java editor, a little arrow appeared next to the Listener (like with overridden methods) which when clicked allowed me to navigate back the other way to the UI component/s, which the Listener is linked to, in the designer. I know this is currently possible from the point where the UI component is declared in the Java editor but this is just an additional point of navigation to that which already exists.

- scott

0

Being an IntelliJ user for many years, I really like IntelliJ a lot and have my whole team converted to IntelliJ users. However, the GUI side of Java has not been treaded all that well by IDEA/ Jetbrains, nor has it by any other IDE, besides JBuilder maybe.

Matisse on the other hand has changed the game. Now there is an IDE, allowing developers to design UIs for Java apps with the same ease uf use, formerly only available in Interface builder for Cocoa Mac Apps.
Adding a new layout manager was just a very smart move and since it will be part of Java 6, there really is no downside in using it.
Take a very close look at Netbeans / Matisse GUI builder. This is currently state of the art gui building for Java apps, IntelliJ has to be measured on.
Or to say it differently, currently, designing GUIs with Matisse is much more "Develop with pleasure" than it is with IntelliJ.

0

Out of curiosity, how does it compare to JFormDesigner?

Take a very close look at Netbeans / Matisse GUI builder. This is
currently state of the art gui building for Java apps, IntelliJ has to
be measured on.



0

Hello Wolf,

WP> Or to say it differently, currently, designing GUIs with Matisse is
WP> much more "Develop with pleasure" than it is with IntelliJ.

Have you actually tried the UI Designer in the EAP builds of Demetra?

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0

Yes, I did start to look into Demetra. I would really like to stay in the IntelliJ camp, learning a new tool and master it just takes time and focus away from the things I would rather do.

However, Demetra's GUI designer still trys to tackle the "old" LayoutManagers like GridBag, Box, and what not. The smart move Matisse made was not to work with those un-toolable layout-managers, but come-up with a new one, built for GUI tools like Matisse.

Even better, their new layoutmanager, which is less than 200k anyways, will be part of Java 6.
Current LayoutManagers in Java (especially Gridbag) really suck, even more so if you want to write a tool, allowing to configure them. The solution shown with Matisse is simply cool. Don't fight it. Write a Matisse plug-in or put all the menpower you can get behind Demetra's GUI designer and provide an even better solution.

The game has changed. Netbeans is free, and being as good as Matisse simply isn't good enough for IntelliJ.

Java is about to (re)gain some attension on the Desktop, which requires a GUI desginer.

0

Hello Wolf,

You make an important statement without providing any arguments for it: the
statement that the Matisse layout manager is easier to build tools for than
any other layout manager. Could you please describe why you think this is
so? My experience building tools shows quite different results.

(Remember SpringLayout, which appeared in JDK 1.4 with the specific purpose
of being toolable? Ever seen that in real use?)

One of the goals which are very important for us is to make it possible to
use the GUI Designer in the widest possible range of projects. And however
good the Matisse layout manager may be, the majority of projects in existence
today use other layout managers. Because of that, today we're spending effort
on providing support for other layout managers. If Matisse does become widespread,
we will definitely support for it - but right now this is not on top of our
priority list.

And we do spend all the effort we can on the Demetra GUI Designer. "Better"
is a very subjective thing, but we do think that the Demetra GUI Designer
will be a more productive tool for developing user interfaces than Matisse.

You can check out my blog, where I've posted more of my thoughts on this
topic:
http://blogs.jetbrains.com/yole/

WP> Yes, I did start to look into Demetra. I would really like to stay
WP> in the IntelliJ camp, learning a new tool and master it just takes
WP> time and focus away from the things I would rather do.
WP>
WP> However, Demetra's GUI designer still trys to tackle the "old"
WP> LayoutManagers like GridBag, Box, and what not. The smart move
WP> Matisse made was not to work with those un-toolable layout-managers,
WP> but come-up with a new one, built for GUI tools like Matisse.
WP>
WP> Even better, their new layoutmanager, which is less than 200k
WP> anyways, will be part of Java 6.
WP>
WP> Current LayoutManagers in Java (especially Gridbag) really suck,
WP> even more so if you want to write a tool, allowing to configure
WP> them. The solution shown with Matisse is simply cool. Don't fight
WP> it. Write a Matisse plug-in or put all the menpower you can get
WP> behind Demetra's GUI designer and provide an even better solution.
WP>
WP> The game has changed. Netbeans is free, and being as good as Matisse
WP> simply isn't good enough for IntelliJ.
WP>
WP> Java is about to (re)gain some attension on the Desktop, which
WP> requires a GUI desginer.
WP>
--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0

Yes, I also think that it is a waste of time to build a nice GUI editor
that will result in GridBag code.

I would like to see a GUI editor that would generate layouts using
TableLayout. It is just as flexible as GridBag but MUCH easier to use
and MUCH more intuitive.

https://tablelayout.dev.java.net/

0

Hello Ted,

TH> Yes, I also think that it is a waste of time to build a nice GUI
TH> editor that will result in GridBag code.
TH>
TH> I would like to see a GUI editor that would generate layouts using
TH> TableLayout. It is just as flexible as GridBag but MUCH easier to
TH> use and MUCH more intuitive.
TH>
TH> https://tablelayout.dev.java.net/

One question: why do you care?

When working in the UI Designer, both the ease of use and the intuitiveness
are determined by the design-time environment, not by generated code. Ideally,
you should not need to know at all what layout manager is used by the generated
code.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0

Occasionally I might like to be able to modify the generated code by
editing the .java files.

0

Hello Ted,

TH> Occasionally I might like to be able to modify the generated code by
TH> editing the .java files.

This is a one-way process: the UI Designer will not be able to import the
changes you make in the generated code back to the form file.

Once we support full source code round-trip (which may or may not happen
in version 6.0), it will definitely make much more sense to support different
layout managers when generating code. But before that, ease of modifying
the generated code is not one of our major design goals.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0

In build 5245 I see

  • UI Designer. Taking form snapshots from running application.

Is this the functionality promised in
http://blogs.jetbrains.com/yole/archives/000114.html to generate an Idea
.form file from an existing window? How do I trigger this?
R

0

Hello Robert,

RG> In build 5245 I see
RG> * UI Designer. Taking form snapshots from running application.
RG> Is this the functionality promised in
RG> http://blogs.jetbrains.com/yole/archives/000114.html to generate an
RG> Idea
RG> .form file from an existing window? How do I trigger this?

Yes, it's that functionality. To activate this, right-click a package and
select "New / Form Snapshot" from the context menu.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0

Hmmm, doesn't seem to work for me. I'm prompted to set link the
functionality to a run config which seems to succeed since when I run I
get a line like
SnapShooter listening on port 46666
in my output. But when I choose New Snapshot I can only type in the Name
box or press Cancel - I have no components listed in the box.

Here's what appears in my console
SnapShooter listening on port 46666
SnapShooter connection accepted
Sending response: .

End of stream receiving command

Moreover, how do I set up this functionality for additional run configs
or remove it on a config I've already set up? I don't see anything in
the Run Configuration dialog box.

R

0

Please sign in to leave a comment.