Dmitry Jemerov's Weblog

First of all, thank you for considering this request Dmitry! As a user I really appreciate it. Now, to get down to details.

I like the idea of UI Designer generating source code which uses JGoodies forms. Some fine tuning would be nice. For example, I would like to be able to specify that FormLayout be used directly, or encapsulated in a PanelBuilder.

Another, probably more difficult requirement would be to identify existing JGoodies Forms code and import it into the UI Designer.

Finally, I don't know if the UI Designer already supports this, but besides row and column grouping, JGoodies Forms supports constant spacing between cells in terms of pixels, DLU (dialog units), and points. Other features are bounded sizes, where one bound may be a constant (again in terms of pixels, dlus, or points).

Thanks again for considering my request.

I tried the 6.0 EAP and I could not figure out how to put a narrow gap between a column of labels and a column of text fields, and then put a wider gap between the "rows" of components. In JFormDesigner (using JGoodies FormLayout), I just put the labels and text fields on the form, and then choose "label-component gap" for the column gap and "related gap" for the row gap, and I am done.

JGoodies FormLayout also has support for using "Dialog Units" instead of pixels, which is very useful.

Like I said, I tried to use the Demetra EAP form designer. I just couldn't figure out how to deal with inter-component spacing. Plus, forms do not look the same in the design view as they do in the preview (especially regarding inter-component spacing). For example, if I stack three text fields on top of each other, then I expect the spacing between them to be fixed by default, but that only happens if I remember to add a VSpacer to the bottom of the form. That wouldn't be so bad, maybe, if the design view showed this behavior. In general, I find the VSpacer/HSpacer stuff to be very unintuitive, especially compared to how JFormDesigner does it.

It would be helpful if you could create a demonstration that shows us how to use the form designer effectively. For example, could you reproduce this one?:

http://www.jformdesigner.com/demos/demo1.html

(BTW, I am not affiliated with JFormDesigner beyond being a customer).

Also, I would honestly not have to depend on JGoodies FormLayout. I think that you will find that most people will be extremely happy if you can provide the design-time experience that FormLayout-based UI designers give, without the JGoodies dependency.

You can do a very informal usability study: Find three or four developers that have never used IntelliJ's form designer, and three or four developers that have never used JFormDesigner. Put them in a room and ask them to design a "contact form" (which is pretty representative of forms created for in-house corporate applications). My bet is that the IntelliJ users will get frustrated with component spacing and resizing. At the end of this test, the problems with the IntelliJ form designer's UI will be clear. Once you fix those problems, I bet most of the people asking form JGoodies Forms support will start asking for other stuff instead.

As I mentioned many times before:
"Try JFormDesigner"
It is the perfect example of a good GUI Designer, and especially for JGoodies Forms support.

In all the discussions Jetbrains employees keep saying that they've tried JFormDesigner, but my impression is that they did NOT.
If one is REALLY using it for something real than it's simply IMPOSSIBLE not to see the difference.
It's no rocket science, but the "polish level".
It's the same polish level the IntelliJ Editor has over the Eclipse or Netbeans one, just that in this case Jebrains is in disadvantage.

As I said before: buy a big wide screen, to run the IntelliJ GUI designer and the JFromDesigner side by side, and try to do something: than you can see the fine differences and the "polish level" exactly on each feature or step of work.

Just my 2 cents,

Ahmed.
P.S. Sorry, but from all these many messages about the GUI Builder it seems to me that Jebrains this time "can't see the trees from the forest", or developers are just too subjective: they should step back, forget that the IntelliJ GUI Builder is their baby, and make an objective analyze (e.g. side by side).

Ahmed,

Sorry, but this comment was not very much helpful. Right now my goal is to understand whether we can provide a useful amount of JGoodies Forms support in the time we have remaining before the release. If a useful degree of JGoodies Forms support will cost us 3 or 4 weeks to implement, then, well, there will be no JGoodies Forms support at all. If it turns out that we can provide something useful in a shorter time frame, it's likely that we'll do that.

As for polish - please understand that it doesn't come in one big splash; we can't go from the state that we had in 5.0 to a super clean and polished product in a single EAP build. I can publish lists of polish-level improvements that we keep making in each build, if that's what it takes to convince you that we do care about this.

> Sorry, but this comment was not very much helpful.
Sorry but my impression was that we were going in circles.

>If a useful degree of JGoodies Forms support will
> cost us 3 or 4 weeks to implement,
4 weeks X 1 talented developer? I'm not sure. I don't know how the legacy code looks like.
From the JGoodies Forms side there are some very nice debug methodes that give visual clues about the layout (AFAIK they're the base for most GUI designers that support Forms). I don't know however how do they fit with the IntelliJ legacy code. JFormDesigner is using them fully, but it has no legacy problems. If I recall well, in it's first version it supported only Forms, and later, those visual effects and behaviours were implemnted over the other layout managers and not vice versa.

>we can't go from the state that we had in 5.0
>to a super clean and polished product in a single
> EAP build
IMHO you can. If it won't be, people won't use it - it's that simple. As an analogy, this(polish) is the single reason people switched to IntelliJ (even for the first version - I was one of them). Even from the begining, if features were missing, was not a problem - but the existing ones were polished.

> ...if that's what it takes to convince you that
> we do care about this.
I know you care :), but this was not my point.
I follow very carefully each build and give it a fair test, however a simple comparative side by side test shows that the GUI designer is not "smooth at all".

Another thing that some asked was to open the source of the UI designer. I don't think however that this would help. How many users could really help? Maybe one or two? I also suppose that the code is totally undocumented since even the OpenAPI is mostly so, and as a consequence, even if many would like to help (like me), it's very probable that they won't be able to do much.

Because of this, IMHO the simplest way to try to improve in this situation is to try to compare, feature by feature the polish level to something that is already good (e.g. JFromDesigner), and try for at least some of the most used one to achive the same level.

If this is possible in 4 weeks? I can't answer you that :(. Maybe there's a way to find out what is "mostly or all the time used": "DETAILED Productivity Guide" for all the features in the UIDesigner, and a "Submit Statistics to Jetrains" button.
I think such a feature would give you way more realistic "usage statistics" than all the "loud wining" from some users on the forums.

Ahmed.

If you think about implementing your own layout manager you def'nitly should take a look at http://sourceforge.net/projects/visuallayout. We are using it bcoz it even can group rows/columns on different panels.

Ahmed.

You are doing precisely what Demitry complained about in the first place!

There is no point saying things like "make it more polished", or "try it and see for yourself".

If you want them to improve the GUI designer, then provide specific instances of what IntelliJ is doing wrong, and how JForm Designer gets it right.

When a user comes up to you and says "Yeah it works OK, but can you make it ... y'know ... better?"

It's not really very much to go on.

To Rayz,
Please read all my other comments from the other messages and you'll see that I've mentioned many clear things that are missing from the IntelliJ GUI designer.

And one more thing:
I wrote "try it side by side", because "IT'S NOT OK" IMHO. This is why IMHO it needs many radical changes, and I also propose how to find out them. Enumerating them here does't help as they would be out of the context and it would require a longer explanation than implementing them from the ground. Just looking at something that already does that right is just practical and it's like a "diff".
In the case of a GUI designer, polishment is not the 10% but the 90% that makes the difference. It's not really about features lists, but more about the way the are "polished" in the same way the code editor from IntelliJ does(but as the good example).

Ahmed.