I have extensively tested the JGoodies Forms framework and I have chosen it for my future projects.
The pro's are: 1. very easy to use, 2. there are many possibilities (e.g. can set components widths to a number of pixels or to a number of dialog units, several alignment options, etc.). 3. I create the code myself and not an UI designer, which means that the code is much shorter and understandable etc. 4. forces me to adapt good user interface design guidelines (e.g. must make a design on paper first). 5. the author is very helpful in case of problems. 6. it is possible to easily syncronise the sizes of the controls on two forms and like this making a better user experience when switching between these forms.
The contra's: 1. the documentation is not yet fully developed (in preparation or maybe it is already extended?). 2. it is a bit trial and error at the beginning till you get the feeling (and info) to use it. 3. ?
I do not dare to say that this is the best solution for GUI design (I let others to decide), but for me it is just good enough to use it in my projects.
I hope this will be helpful to someone...
> 3. I create the code myself and not an UI designer, which means that the code is much
> shorter and understandable etc
So when the GUI has to be changed your UI designer can do it?
I always like that I can send the GUIs to QualityAssurance people that fix my GUIs to look similar to the rest of the application.
Last fryday we finished an application that has changed looks about 5 times, since some QA bozo that just got hired was being an ass. Being a programmer I just have to listen to what they say and do as they please (just so you know; the first design I made is pretty similar to the end result).
Suffice it to say that the pro you quote is something I see as a con, because of the way projects get brought to market in many projects I worked on.
This is why my company wrote the (open source) http://uic.sf.net framework to let my graphics designer do its job :-)
Keeps those QA people out of my office!
> > 3. I create the code myself and not an UI designer,
> which means that the code is much
> > shorter and understandable etc
I would agree that this is a PRO if the code generated should be maintained by me (the programmer). But in most cases (as Zander described) it is not the programmer who decides what the UI will look like, but the UI Designer.
We see this a lot in web environments, for example webmacro, which is designed so that webdesigners can work with it (jsp is way too complex). I do not see why people are so hesitate about using that in the Java Client environment.
Forms has been designed to 1) make hand-written layout code easy to read and easy to understand, and 2) make it easy to be driven by a visual UI builder - either by generating code or dynamically creating a layout and form. I'd say that 1) is a plus for developers that write the layout code directly, without any tool support. From my perspective, a visual builder would help a large fraction of developers to quickly drive the FormLayout.
There are projects for visual builders that work with the FormLayout; what I've seen so far looks promising. I prefer tools that save time or lead to higher quality. Personally I think that such a tool should support multiple target platforms, multiple l&fs, essential layout issues and should be able to honor multiple style guides - at the same time. It seems that finally this is coming to Java.
> But in most cases (as Zander described) it is not the programmer
> who decides what the UI will look like, but the UI Designer.
I don't quite agree that in [i]most cases[/i] a UI designer will design the UI - at least in the Swing world. I'd bet that over 75% of all Swing UIs have been designed and implemented by developers. Actually, my personal statistics says that over 90% of Swing apps have been designed by a Java developer, not a professional human visual designer.
> Forms has been designed to 1) make hand-written
> layout code easy to read and easy to understand, and
> 2) make it easy to be driven by a visual UI builder -
> either by generating code or dynamically creating a
> layout and form. I'd say that 1) is a plus for
> developers that write the layout code directly,
> without any tool support. From my perspective, a
> visual builder would help a large fraction of
> developers to quickly drive the FormLayout.
I never said the generated code is not readable.. it is. But I don't find it that important if I can change the UI in a program that is designed to do just that (and is not designed for hacking code like I do in VI ;) )
> I don't quite agree that in [i]most cases[/i] a UI
> designer will design the UI - at least in the Swing
> world. I'd bet that over 75% of all Swing UIs have
> been designed and implemented by developers.
> Actually, my personal statistics says that over 90%
> of Swing apps have been designed by a Java developer,
> not a professional human visual designer.
I agree... but have you looked at most Swing UI's? A few weeks back there was a new Swing-Sightings, and I couldn't help wondering if people cared about good UI-design at all. I am a developer myself and even if I pay a lot of attention to the design of that UI it's still not good enough for non-developers to use. Since that is the main target for the programs I write, it must be easy for someone to change the UI.
I really hope people will start to pay attention to the design of their UI's. Because there is the problem that a lot of people won't even consider using a program written in Java. It is not because it's slow, has an ugly L&F or what ever other reasons people give (missing a shared JVM is a big compaint). I think Swing has a lot of potential and people can do a lot of nice things with it... but still they have to use it correctly......
> But I don't find it that important if I can change the
> UI in a program that is designed to do just that [...]
I agree completely. It's just that I'm not aware of a visual builder that supports multiple platforms/l&fs/style guides, non-pixel sizes and logical sizes, etc - all the things I address with the Forms framework. As long as so many Java UIs are being built by developers who are not trained in visual design, I'd say the layout code readability, expressiveness and size matters.
> [...] I think Swing has a lot of potential and people
> can do a lot of nice things with it... but still they
> have to use it correctly......
I'm looking for ways to assist developers in unleashing Swing's potential. For example, a visual builder would help if it leads to better design results or saves time. Good design examples, well-designed sample layouts and well-written tutorials will help too.
In Forms I tried another approach that leads developers to good design and that avoids the bad: meta design implemented by a layer of non-visual builders. For example the ButtonBarBuilder vends only button bars that are consistent and well-designed. Meta design has saved time and money in the print-media industry for a long time (see for example http://www.metadesign.com). Where traditional meta design is typically a set of rules plus design templates, it is code in Forms.
> > But I don't find it that important if I can change
> > UI in a program that is designed to do just that
> I agree completely. It's just that I'm not aware of a
> visual builder that supports multiple
> platforms/l&fs/style guides, non-pixel sizes and
> logical sizes, etc - all the things I address with
> the Forms framework. As long as so many Java UIs are
> being built by developers who are not trained in
> visual design, I'd say the layout code readability,
> expressiveness and size matters.
That's just the point... People that do not understand UI design (probably like myself) will not be able to create a decent UI. You cannot solve this in code. I'd like the step to create a (Swing)-UI to be very simple. And on top of that I'd like to be able to adjust it to my customers needs afterwards without starting over and over again... This will include changing things from comboboxes to jlists. Sliders to spinners, etc etc.. Code generation is about the easiest way to accomplish that, as long as the code generation provides hooks to update your model and view...
> I'm looking for ways to assist developers in
> unleashing Swing's potential. For example, a visual
> builder would help if it leads to better design
> results or saves time. Good design examples,
> well-designed sample layouts and well-written
> tutorials will help too.
I really hope that will help for some developers.. but for most developers that still wont make them create decent gui's. Simply because that's not what they payed/trained to do...
> [..] Meta design has saved time and money in the
> print-media industry for a long time (see for example
> http://www.metadesign.com). Where traditional meta
> design is typically a set of rules plus design
> templates, it is code in Forms.
I will have a look at that...
>> As long as so many Java UIs are
> > being built by developers who are not trained in
> > visual design, I'd say the layout code readability,
> > expressiveness and size matters.
> That's just the point... People that do not
> understand UI design (probably like myself) will not
> be able to create a decent UI. You cannot solve this
> in code. I'd like the step to create a (Swing)-UI to
> be very simple.
This difference of opinion I have talked about with Karten before, the points Roy makes are about having a good UI that is usable, but not perfect per see.
What Karsten (and probably his clients) want is a GUI that technically perfect, and if that means that the GUI can't be created with a visual builder, then he will workd that much more hours to (re) do the GUI in code.
Its all about priorities, and each for his own.
> Simply because that's not what
> they payed/trained to do...
This is the most important step; a good coder will never create good UIs, no matter how good the toolkit is. You can make it easier to rewrite it when it has to look different.
> > [..] Meta design has saved time and money in the
> > print-media industry for a long time (see for
> > http://www.metadesign.com). Where traditional meta
> > design is typically a set of rules plus design
> > templates, it is code in Forms.
> I will have a look at that...
Hehe; this is a good example of what we do as well :) Its just that we (Roy and me) both work at the programming department, and the graphics design is on the other side of the Bridge *grin*
Interesting thread - and interesting projects around that I had not been aware of.
> Its in the little things; if I have a textfield in
> the same row as a button in a GridBag layout that
> means that those 2 widgets both take a similar hight.
> That means that since the button is a bit bigger that
> your text field is spaced larger then the next
> textfield. This is solved using the UICTheme which
> makes the TextField report a correct MaximumSize.
Hmm... what's the "correct" size and how does the textfield calculate it? Looks like it somehow needs to know about the button size. Introducing such a coupling on the widget level does not appear like a good idea to me.
I think, it's the sole and only responsibility of a decent LayoutManager to take care of all positioning, alignments and sizing issues that may arise. Then there is no need to subclass the widgets and the layout will work with all widget toolkits.
FormLayout is such a decent and at the same time easy to use LayoutManager (I might be a bit biased because I'm in the process of writing a visual builder on top of it :-). To solve the issue with differing heights above simply set the alignment property of the row to "fill" instead of center which is the default. That's done in the manager's meta-data and will work with all comps in that row independ on the concrete class of the comp.
> Further things are the JTable that by default fits
> into Windows (or any other WM) much better then its
> plain Swing version.
Making Swing components behave better than the defaults is a totally different story, IMO. I prefer to keep it separated from layout and presentation issues.
> > I'm going to check out
> > JGoodies Forms next, as it looks promising.
> Let us know what your findings are!
In one of your other posts (cannot find it at the moment, sorry) you mentioned as your experience with FormLayout an example with two textfields that appear very narrow if there's nothing in them. That's principally the same behaviour as in Example1 that comes with UIC - there just replace the setBounds call to the enclosing frame by a pack and you end up with the small default width of an empty textfield. What's different between example1 and your experience with FormLayout (assuming from what you described) is that the textfields in the latter do not resize if the frame is resized - but there are simple remedies for that (f.i. setting the column resize mode to grow instead of the default no-grow).
Just to compare: how would you change the .ui to make the textfield come up with some reasonable default size, even if it's empty? In FormLayout I simply set a bounded size with a minimum value to the column of the _LayoutManager_ without touching the concrete widget.
glad you took the time to look into things a bit deeper :)
I'm afraid you misunderstood some concepts here, the basic question you seem to answer different from me is where the layout manager gets its information upon which it decides the size of each widget. Or in the case of both FormLayout and NaturalLayout; which size the columns are.
See http://uic.sf.net/textsizes1.png : screeny with fix and http://uic.sf.net/textsizes2.png : screeny without fix.
A button will have a minimumSize of 50x20 pixels, and a preferredSize equal to that.
An (empty) textfield will have a minimumsize of 50x15 pixels and a preferredSize of 0x15 pixels.
1) just put these two next to each other and the texfield will be 20 pixels height. Which is ugly, so also provide a maximumsize for the textfield (see pngs)
2) the textfield can not get smaller then those 50 pixels wide; so this is your minimum (as the name indeed implied : )
3) since the widget calculates the minimum, preferred and maximum sizes of himself he limits the choices that the layouter has, but the layouter is the one to ultimately make those desicions.
There is a lot more to the problem solving than I posted above, but this is the essence of the situation.
All these changes (I definitely want to call them fixes) are made in a look&feel; so its not that I extended lots of widgets. Some are extended but those have extra functionality like a textfield that selects text when the user enters the field (using tab for example).
That said; all the automation and fixes to the widget sizes still don't cover 100% of the cases, and I will keep working to get a GUI takes no tweaking, just placing of widgets.
> I'm afraid you misunderstood some concepts here, the
> basic question you seem to answer different from me
> is where the layout manager gets its information upon
> which it decides the size of each widget. Or in the
> case of both FormLayout and NaturalLayout; which size
> the columns are.
could well be - I did not dig too deeply ... but...
> See http://uic.sf.net/textsizes1.png : screeny with
> fix and http://uic.sf.net/textsizes2.png : screeny
> without fix.
... they both look ugly, IMO. In the first the button is higher than the textfield breaking alignment lines in that row, in the second the alignment in the row is okay but the field in the second row still not high enough. How do you get that lower textfield to the same height as the upper?
> A button will have a minimumSize of 50x20 pixels, and
> a preferredSize equal to that.
> An (empty) textfield will have a minimumsize of 50x15
> pixels and a preferredSize of 0x15 pixels.
These numbers look a bit arbitrary to me ...
> 3) since the widget calculates the minimum, preferred
> and maximum sizes of himself he limits the choices
> that the layouter has, but the layouter is the one to
> ultimately make those desicions.
agreed - but my point is that you don't have to tweak (most of) the sizing on the component level, given a good layout framework. This layout will give satisfactory results on all widgets in all LFs, provided the sizes reported by the widgets are not too far off, of course.
> All these changes (I definitely want to call them
> fixes) are made in a look&feel; so its not that I
> extended lots of widgets.
In my experience that's even worse than extending: fiddling in the ui delegates easily leads to a maintainance nightmare. If you have a very controlled context, like a company wide accepted cross-plattform LF you can get away with it - but doing so even a limited range of platforms is a terrible task.
> Some are extended but those
> have extra functionality like a textfield that
> selects text when the user enters the field (using
> tab for example).
yeah that's expected win behaviour - got lost sometime around 1.3. BTW, I don't see any need to subclass to get it back, simply replace the caret in a customizer :-)
I think we have different perspectives because we have different requirements: from your posts I assume that you have much control about the source code/LFs that are used whereas I have very little control about the widgets used, doing ui-customization across LFs in varying environments. So I need a good (stable, reliable, easy to change) layout independ from any specially adjusted components and/or LFs. From first experiments I think JGoodies Forms are the answer.
Personally I would not put too much effort into tweaking the LFs, the nasty details tend to change across versions, not always to the better but most probably clashing with the tweaks. Just my 2 cents, though.
Hi again Jeanette,
> > See http://uic.sf.net/textsizes1.png : screeny with
> > fix and http://uic.sf.net/textsizes2.png : screeny without fix.
> ... they both look ugly, IMO. In the first the button
> is higher than the textfield breaking alignment lines
> in that row, in the second the alignment in the row
> is okay but the field in the second row still not
> high enough.
I'm not sure what you mean with alignment. The button and the textfields have height dictated by the font size the user set in his preferences (http://uic.sourceforge.net/tutorials/configdiag.jnlp)
If I make the font for the text fields bigger I get a very different setup; take a look at http://uic.sf.net/textsizes3.png.
What should the general rule be for that?
> How do you get that lower textfield to
> the same height as the upper?
Simple; the export a maximum size; and the NaturalLayout respects that. The widget is centered in the cell of the layouter-grid so you get blank screen around it. Maybe I should allign it top or bottom?
> agreed - but my point is that you don't have to tweak
> (most of) the sizing on the component level, given a
> good layout framework. This layout will give
> satisfactory results on all widgets in all LFs,
> provided the sizes reported by the widgets are not
> too far off, of course.
Thats just the problem; Swings widget report their sizes incorrectly and all attempts to do it in an automated manner gave me problems in one layout example or another. So the only want to get it to show correctly in all manners is to fix bugs in Swing.
Unfortunately I can't fix bugs in the JRE, so I am restricted to do so in a layouter. It is my hope that the Swing team takes my fixes and puts them into the JVM. I dont have high hopes for that though, as the Swing team seem to not understand the fixes I made in the first place.
> In my experience that's even worse than extending:
> fiddling in the ui delegates easily leads to a
> maintainance nightmare. If you have a very controlled
> context, like a company wide accepted cross-plattform
> LF you can get away with it - but doing so even a
> limited range of platforms is a terrible task.
That is why I made the LookAnd feel color and font configurable. See the above JNLP.
> yeah that's expected win behaviour - got lost
> sometime around 1.3. BTW, I don't see any need to
> subclass to get it back, simply replace the caret in
> a customizer :-)
I never used Swing before 1.3, so I don't know where this was, and I could not find it in the sources. I also consulted the Swing team with which I came to the solution I have now.
> I think we have different perspectives because we
> have different requirements: from your posts I assume
> that you have much control about the source code/LFs
> that are used whereas I have very little control
> about the widgets used, doing ui-customization across
> LFs in varying environments. So I need a good
> (stable, reliable, easy to change) layout independ
> from any specially adjusted components and/or LFs.
> From first experiments I think JGoodies Forms are the
I'm far from happy that so many things in Swing needed fixing (we're at bug count 40 now), and that means I either do it every time the widget is used; or one time in the UI. That I have to set the L&F only means more people have an incentive to make it more beutiful. I can't tell you what is the best way to fix your GUIs, but from experience I know that it takes less time re-doing the panel in QtDesigner as it does fixing the UI using alternative means, including writing Forms code.
If you have screenshots of the forms you are 'fixing' maybe that I can comment on that better, you can sent that in a personal email if you don't want to do that publicly.
Grï¿½ï¿½e aus Holland :)
> I'm not sure what you mean with alignment. The button
> and the textfields have height dictated by the font
> size the user set in his preferences
oops ... just an aside in talking about layout: at least the tab about color choosing theme in configdiag is not exactly what I would call a good layout. Could be a matter of taste but keeping lines and boundaries aligned usually results in uis that are better to understand (for the user).
> If I make the font for the text fields bigger I get a
> very different setup; take a look at
> What should the general rule be for that?
okay, I get the impresseion that I misunderstood you: I assume the idea is to give the same height to widgets in a row? One of your examples does so, and I thought that was the fixed one. Probably got it wrong though.
Maybe we should replace the button with a comboBox: swing has it higher than a textfield in (at least metal) LF which makes uis look ragged if they are in the same row. Then the goal would be to give the two textfields (in different rows) and the one combobox (in the same row as one of the textfields) the same height. Agreed?
> > How do you get that lower textfield to
> > the same height as the upper?
> Simple; the export a maximum size; and the
> NaturalLayout respects that. The widget is centered
> in the cell of the layouter-grid so you get blank
> screen around it. Maybe I should allign it top or
hmmm ... I would prefer the two textfields to have the same height, even if they are in different rows and one of them was forced a bit higher because of other widgets in its row.
> If you have screenshots of the forms you are 'fixing'
> maybe that I can comment on that better, you can sent
> that in a personal email if you don't want to do that
Thanks for the offer, but I'm not looking for individual fixes but for a tool that allows me building and re-using layouts easily. BTW: I dont like code generators :-)
> Grï¿½ï¿½e aus Holland :)
Grï¿½ï¿½e aus Berlin
Good morning Jeanette,
> > I'm not sure what you mean with alignment. The
> > and the textfields have height dictated by the
> > size the user set in his preferences
> oops ... just an aside in talking about layout: at
> least the tab about color choosing theme in
> configdiag is not exactly what I would call a good
> layout. Could be a matter of taste but keeping lines
> and boundaries aligned usually results in uis that
> are better to understand (for the user).
Again; I am lost as to what you mean... Sorry. Maybe the border around 'selected color' being a lot lower then the top of the defaults-list ? Thats a bug in Swing and one I can't fix (I sent a patch to the Swing team, but I'm not sure that helps)
See uic.sf.net/fixes bug #37
If I misunderstood; please tell me what you mean!
> okay, I get the impresseion that I misunderstood you:
> I assume the idea is to give the same height to
> widgets in a row? One of your examples does so, and I
> thought that was the fixed one. Probably got it wrong
There are no fixed sizes in any of my layouts.
> Maybe we should replace the button with a comboBox:
> swing has it higher than a textfield in (at least
> metal) LF which makes uis look ragged if they are in
> the same row. Then the goal would be to give the two
> textfields (in different rows) and the one combobox
> (in the same row as one of the textfields) the same
> height. Agreed?
Well, no. Having blank space around the text in a textfield is ugly, and it opens up a can of worms when textfields on another page have a differnt size.
I agree that the baseline offset for each row in a table should stay the same, but that should not mean widgets are drawn bigger.
Naturally the real fix is to put the button outside of the grid and align both the button and the textfield to the same top. But all the same; these fixes are needed in order to always have the optimal UI for any user input (the user being the graphics designer here).
> Again; I am lost as to what you mean... Sorry. Maybe
> the border around 'selected color' being a lot lower
> then the top of the defaults-list ?
yes - that's one issue. Another is that the preview of the color below the combo is not right aligned with the combo.
> Thats a bug in
> Swing and one I can't fix (I sent a patch to the
> Swing team, but I'm not sure that helps)
> See uic.sf.net/fixes bug #37
I'll have a look, thanks. But again, whatever the bug the layoutManager should be able to handle it.
> There are no fixed sizes in any of my layouts.
I did not mean fixed sizes but fixed layout problems :-) But never mind, looks like we disagree a bit on aesthetics of alignments and relative sizes.
> Well, no. Having blank space around the text in a
> textfield is ugly,
Then let's agree to disagree.
> and it opens up a can of worms
> when textfields on another page have a differnt
Ack - cross page appearence _is_ a problem.
> Naturally the real fix is to put the button outside
> of the grid and align both the button and the
> textfield to the same top. But all the same; these
> fixes are needed in order to always have the optimal
> UI for any user input (the user being the graphics
> designer here).
Again: a better example would be an editable combobox instead of the button. Combos are perceived like textfields by users and they get irritated if they don't look very similar.
> yes - that's one issue. Another is that the preview
> of the color below the combo is not right aligned
> with the combo.
Thats a feature; so I can use the cursor to walk through the combo and see the color updated without having to click next the the combo every time.
> I'll have a look, thanks. But again, whatever the bug
> the layoutManager should be able to handle it.
The problem with that is that you can't do it in a consistent manner and the end result will be that
it simply breaks behavior in other panels. I tried that ones and got the feeling the software was working against me, and as a usability pro you know that there should not be made exceptions for things that are not immidiately obvious.
> Then let's agree to disagree.
Have a nice day!
Thomas, I see a lot of QT, on your site.
Is it possible to get an example how your product could save my time when
I do my work with Swing ?
> Thomas, I see a lot of QT, on your site.
> Is it possible to get an example how your product
> could save my time when
> I do my work with Swing ?
Although my name is not Thomas I think I can answer this as well ;)
If you look at the http://uic.sourceforge.net/tutorials/ on the uic page and look at the difference between tutorial 2 and 3. Changes in the UI did not take any development time (just move around the widgets in QtDesigner).
These kind of changes (customers tent to adjust their opinion about a good interface) are now really trivial. And you do not have to know anything about the different layouters available in java.
Futhermore there more widgets or mature versions of the Swing widgets available for download, so that way it takes less time for tweaking as well.
If you for example use the JTable, you get the sorter for free. But not only that you will also have a number of methods generated that allows you to adjust the data in the JTable very easily.
For example if you have the table from tutorial 2/3 you will get the following methods for free:
+--- 7 lines: public void removeAllRowsFromGroceryList()
+--- 10 lines: public void addRowToGroceryList(Object col, Object name)
+--- 6 lines: public void updateRowOnGroceryList(int row, Object col, Object name)
+--- 5 lines: public void removeRowFromGroceryList(int row)
I hope this gives you some information about how this could really take some time off developing the dull stuff..
Roy, is it possible to integrate third part JavaBeans(GUI) with QtDesigner ?
> Roy, is it possible to integrate third part
> JavaBeans(GUI) with QtDesigner ?
> Thank you.
The entire structure is PluginBased. At our own company we have special (tweaked) widgets we use. So the only thing you'd have to do is to create a new plugin based on a widget you can find in QtDesigner.
If you require any help, please send an e-mail to:
Let me know what you're experiences are using UIC. Feedback is appreciated, so we can create a better product.
There is a default plugged C++ editor for QtDesigner, do you have any plans implement plugged editor for java ? Or what did I miss here ?
> There is a default plugged C++ editor for QtDesigner,
> do you have any plans implement plugged editor for
> java ? Or what did I miss here ?
> Thank you.
I don't really know what you mean, but I am going to repeat Roys question to send an email to the UICompiler mailing lists, this is getting too far off topic for java-desktop.
You can find the detail for that on the sourceforge pages.
Frankly, I have never been close to java-desktop :-).
So, Thomas, it seems http://java.sun.com/products/javabeans/beanbuilder/
much better, there is no additional layer between xml and view.
Yes, I did try to find the answer at http://sourceforge.net/mail/?group_id=59493 :-(.
> Frankly, I have never been close to java-desktop
> So, Thomas, it seems
> much better, there is no additional layer between xml
> and view.
I've just taken a quick look at the beanbuilder, and I didn't really like it for a number of reasons. Most importantly it seems to be to tightend to Swing. Since we want to be able to generate to AWT/Zaval as well as swing (maybe even SWT). Altough this is not possible at this moment because of missing the appropriate plugins. It is just that.. write the plugin you need. I wonder how this could work for the bean builder.
And another this is the layouter we use seems more supiriour that the standard swing layouters... :(
> Yes, I did try to find the answer at
> http://sourceforge.net/mail/?group_id=59493 :-(.
Well... want we meant by that is please send an email to this mailinglist so we can keep track of questions being asked (as well as other users can). So they can find answers they where looking for.
> The main reason this is created seems to be that you
> don't directly want to generate Java code.
In my case, that's not exactly right. I have three requirements. In order of importance to me, they are:
1) create good looking, usable UIs
2) quickly create UI boilerplate code
3) easily modify UI later
I don't really care if I do this via UICompiler, XUI, straight Java code, or a form designer in an IDE.
I looked at UICompiler over the weekend, but if there is any compelling reason to use it, it didn't jump out at me. The designer GUI itself reminds me of the MSC++ 5.0 GUI editor I used in 1997. I did appreciate the grid when creating forms, and I liked the horizontal/vertical alignment. It is also nice to set a tab order. But I didn't find any way to align both horizontally /and/ vertically at the same time. I also didn't find a way to anchor components to allow them to stretch as I wanted. (Maybe these things exist and I missed them?)
I didn't look at the generated code, but could you elaborate on how you've changed individual Components to be look better?
SpringLayout looks like it has everything I need, but there is a lot of boilerplate and bookkeeping to do it in straight Java code. I'm going to check out JGoodies Forms next, as it looks promising.
> I looked at UICompiler over the weekend
> But I didn't find any way to
> align both horizontally /and/ vertically at the same time.
You mean to align something top-left (for example).
You use spacers for that in Designer.
If you want a ok/cancel button at the bottom right of your dialog place a horizontal spacer left of those two buttons and group these 3 items in a horizontal layouter. Then add a vertical spacer above that and group these two in a vertical layouter.
> I also didn't find a way to anchor components
> to allow them to stretch as I wanted. (Maybe these
> things exist and I missed them?)
Again; using spacers. I suggest you hit F1 and search for the tutorial that comes with the application.
> I didn't look at the generated code, but could you
> elaborate on how you've changed individual Components
> to be look better?
Its in the little things; if I have a textfield in the same row as a button in a GridBag layout that means that those 2 widgets both take a similar hight. That means that since the button is a bit bigger that your text field is spaced larger then the next textfield. This is solved using the UICTheme which makes the TextField report a correct MaximumSize. Maybe you say that this can be fixed by specifying the value as a coder; but I don't want to do that extra work. And I fear that after the user starts using a bigger font the layout also starts to have problems..
Further things are the JTable that by default fits into Windows (or any other WM) much better then its plain Swing version.
This ranges from the background being white, the rows having alternating colors to the header being sortable by default and the headers not being in that wierd Java 'scaling' mode. I could go on, but I won't.
For a more complete list of things look at the change logs and/or the javadoc. Or even the fixes page: http://uic.sf.net/fixes
> SpringLayout looks like it has everything I need, but
> there is a lot of boilerplate and bookkeeping to do
> it in straight Java code.
Springlayout seems like it needs to have a lot 'manually' coded that just makes it take too long to get a nice result. I just put a 'margin' and a spacing on a layout (in Designer as well as on the NaturalLayout) and be done with it; while SpringLayout seems to require you to repeat the process for each indent.
> I'm going to check out
> JGoodies Forms next, as it looks promising.
Let us know what your findings are!
Ah, the first time though, I missed that you could right click on the form itself to set a layout. I still can't find a way to quickly line up a component's edges with those of both its north and east neighbors, but I can get it close. Anyway, Given the "form" layout setting UICompiler is more useful than I first thought.
I have to weigh the non-standard form designer + non-standard output format against the ease of design + Component enhancements. If I were developing Qt apps, I wouldn't think twice, but I'd like something others can read and edit without grabbing Qt designer. It appears JGoodies will be the better tradeoff in this respect, but I haven't verified that yet.
In my case the 'others' are graphics designers and since this is a tool that graphics designers are the first to understand, that point was one of the points that made me use it.
If your GUI designer is a java programmer (besides the obvios contradiction) this is not a direct benefit, but since the code is there I don't see how this is a problem either.
Oh, also; please consider that moving around widgets, adding bordered-panels etc can be done later with a lot more ease then manually in code.
I tried JGoodies some time ago and when I just added 2 textfield the result looked horrible. Both textfields were 2 pixels wide and the rest of the form was empty.
When I reported that I was told I was using it incorrectly and I should have given a size to the text fields.
In UIC this is considered rediculous; good defaults are 75% of the work and provide a lot more convenient way of working.
If you are thinking about writing the code yourself then I suggest you look at the NaturalLayout that the UICompiler uses, it requires almost no code and the controller code is more understandable then many layout managers I have seen out there.
SpringLayout is the most powerful layout manager I've come across. But from my perspective it's power can only be unleashed when used with a good visual interface builder. Hopefully Philip's Bob project will do a great job. Anyway, there's a fundamental problem with SpringLayout as with most other layout managers:
In my layout courses I've found that most developers do not adhere to essential screen design issues. And they get completely lost when it comes to consistent and style guide compliant design. Most layout systems and visual editors do not provide any assistence regarding these topics.
Why? First off, the JDK layout managers (except SpringLayout) [b]cannot[/b] implement even basic layout features: equally sized columns and rows, stable multi-panel layout, aligned font-baselines. And most layout managers do [b]not[/b] retain proportions if you change the font, font size or screen resolution. The vast majority of Swing UIs breaks almost all reasonable basic design rules. And even most Swing UI solution providers don't do much better.
I provide an article around the weaknesses mentioned above and how to address them. I've just published a short presentation that summarizes some layout essentials. You can find the article and presentation at http://www.jgoodies.com/articles/. The Forms Demo shows style guide compliant panels that you can hardly implement with other layout managers - again except the SpringLayout, see http://www.jgoodies.com/downloads/demos.html
To Thomas: Individual components lack a context and so they can only provide very rough estimates of the minimum and maximum dimensions. For example a button can answer the minimal size where it still is visible. The minimum size in a layout depends heavily on the context: is it in a toolbar, button bar or form, attached to another component or not?; is screen space scarce or not? That's why I agree with Jeanette that the layout context is responsible for the size as well as the minimum and maximum sizes. A human designer adds value to the design and chooses an appropriate context, style and last but not least the sizing rule. And these sizing rules shall not use pixel sizes but pixel-independent sizes, like the MS dialog units. In multi-platform environements even these pixel-independent sizes cannot comprise multiple style guides. Therefore I feel a need to specify many sizes logically, for example the minimum width of an OK button in a button bar is 50dlu on Windows, but not on the Mac. I think the concrete size needs two levels of indirection that involve the platform (for layout style) and the rendering context (for the mapping to pixels).
To Harry: Have a look at the layout essentials presentation at my articles page. You can't do these things with GridBagLayout, GridLayout or FlowLayout. Also, the Forms Demo highlights basically the same advanced layout problems. I'd say there are good reasons to support a more powerful layout manager in JEasy. Candidates are the SpringLayout, Alex Prayle's ExplicitLayout and my FormLayout. All come with license terms that allow a use in JEasy.
> To Thomas: Individual components lack a context and
> so they can only provide very rough estimates of the
> minimum and maximum dimensions. For example a button
> can answer the minimal size where it still is
I guess you mean where all the text and insets are still visible. This is how all the toolkits I have seen define a minium size (including Swing).
> The minimum size in a layout depends heavily
> on the context: is it in a toolbar, button bar or
> form, attached to another component or not?; is
> screen space scarce or not?
In a toolbar you have a different button (or better said; a different set of insets), that means the data definition of the button is diffenent; and thus the minimum size is different. No intervention of a layout manager needed.
In a form, when you have an 'ok'/'cancel' the minimum size of the individual buttons don't change. The way the layout manager handles then does.
If you failt to seperate these layers your gui fails to scale when the user decides to choose a bigger font.
> That's why I agree with
> Jeanette that the layout context is responsible for
> the size as well as the minimum and maximum sizes.
I'll just repeat what I said to her, lets agree to disagree on this :)
> human designer adds value to the design and chooses
> an appropriate context, style and last but not least
> the sizing rule. And these sizing rules shall not use
> pixel sizes but pixel-independent sizes, like the MS
> dialog units. In multi-platform environements even
> these pixel-independent sizes cannot comprise
> multiple style guides. Therefore I feel a need to
> specify many sizes logically, for example the minimum
> width of an OK button in a button bar is 50dlu on
> Windows, but not on the Mac. I think the concrete
> size needs two levels of indirection that involve the
> platform (for layout style) and the rendering context
> (for the mapping to pixels).
This boils down to the always present debate about where configurability should stop and where consistency should rule.
All Mac GUI experts say that the configurability should be reduced; but the users ignore them and choose bigger fonts anyway.
> In a toolbar (...) . No intervention of a layout manager needed.
That's not going to work if you want to comply with the MS layout style guide; this layout style guide requires different toolbar button dimensions for the small and large modes. Let's have an example: we have two toolbar buttons with icons only, one icon is 8x8 the other 10x10 pixels. The JButtons will answer a minimum size of let's say 12x12 and 14x14. The MS style guide demands dimensions of 22x21 for small toolbar buttons and 28x26 pixels in large toolbar button mode.
> If you failt to seperate these layers your gui fails
> to scale when the user decides to choose a bigger font.
Afaik, only the SWT layouts and my FormLayout do honor the font, font size and screen resolution. In other words these layout managers can map pixel-independent sizes to pixels. I've seen no Swing layout system that has a means to layout a single button bar that complies with the MS layout style guide. Microsoft specifies the command button minimum size as 50x14 dialog units, which maps to 75x23 pixel for the common 8pt Tahoma on 96dpi and maps to 100x25 pixels for 8pt Tahoma on 120dpi. For example in the UIC I see no means to specify such a button size.
A typical native Windows application will scale all dimensions with the dialog font, dialog font size and resolution: command button minimum sizes, textfield heights, dialog box dimensions, dialog box margins, paragraph gaps, etc. In the [i]layout essentials[/i] presentation at http://www.jgoodies.com/articles/ I provide a screenshot that shows that pixel-sized layout managers do not retain proportions in this case.
Beyond that I felt a need for two other size mappings. The first just honors the resolution to allow sizes specified in Centimeter or Inch.
> I'll just repeat what I said to her, lets agree to disagree on this :)
I'm fine if we disagree on concepts, implementations and personal preferences. But we all should acknowledge the facts as given by the MS and Apple Aqua layout guides and the requirements of multiplatform screen design.
For example we should acknowledge that the MS style guide specifies a command button minimum size with 50x14 dlu; and that every layout system that cannot map dlus to pixel lags behind native Windows apps.
In addition I'd welcome if we can find a common ground of goals and to a lesser extent concepts that all layout system providers can agree on. Ideally we'd unite or combine our approaches. I think that will help the general desktop community. I have no financial interest in advocating my Forms layout system and I try to embrace other people's ideas and useful concepts. I would be glad if we could at least [i]talk[/i] about the ideal layout system and then iteratively join our efforts and features.
The current FormLayout can replace the GridBagLayout, TableLayout, HIGLayout, and a bunch of other traditional layout managers too. It can't do what the ExplicitLayout can do, and EL doesn't offer all features of the FormLayout.
> > In multi-platform environements even these pixel-independent sizes
> > cannot comprise multiple style guides. Therefore I feel a need to
> > specify many sizes logically, for example the minimum
> > width of an OK button in a button bar is 50dlu on
> > Windows, but not on the Mac. (...)
> This boils down to the always present debate about where
> configurability should stop and where consistency should rule.
That seems to be a misunderstanding. I tried to say that there's a need for layout changes if you switch the platform or l&f. And I'm just saying that a layout system should [i]be able[/i] to adhere to different style guides on different platforms. A Java client should be able to render and layout an 'OK' command button exactly as the related native l&fs - on Aqua and the many different Windows flavors. And that requires non-pixel sizes for Microsoft, and logical sizes for multi-platform deployment.
> > In a toolbar (...) . No intervention of a layout
> > manager needed.
> That's not going to work (...) The JButtons will answer a
> minimum size of let's say 12x12 and 14x14. The MS
> style guide demands dimensions of 22x21 for small
> toolbar buttons and 28x26 pixels in large toolbar
> button mode.
Ok, we are obviously talking about different things here.
> > If you failt to seperate these layers your gui fails
> > to scale when the user decides to choose a bigger font.
> Microsoft specifies the command button minimum
> size as 50x14 dialog units, which maps to 75x23 pixel
> for the common 8pt Tahoma on 96dpi and maps to 100x25
> pixels for 8pt Tahoma on 120dpi.
This minimum size has nothing to do with the button (the Widget) minimum size, and I see now where our confusion comes from.
We fully agree that everything should get bigger when the user chooses a bigger font. Please go to http://uic.sourceforge.net/tutorials/configdiag.jnlp and choose a bigger font and view the results.
The only thing that does not (yet) scale is the spacing between the widgets.
Any Component has calls to minimum/preferred/maximum size. The component always answers that question based on the content it takes. This is basic Object Oriented practice. In the case of a toolbar; you need a layout manager that knows about styleguides.
The point being that the minimum size of the widget does NOT mean that the button will have to be that size; the layout manager will set it however he sees fit.
I guess we agree on this, so how we got here traces back to my claim that the many Swing widgets report a wrong size. This is a big part of the puzzle that needs to be completed, and solving many of these problems has given me good GUIs with minimum manual labour.
The next part of that puzzle (for me anyway) is that advanced users will be able to put extra information into that layout manager and make finetunings like the ones you pointed to. Things like baselines and many other things.
> we should acknowledge that the MS style guide specifies a command button minimum size with
> 50x14 dlu; and that every layout system that cannot map dlus to pixel lags behind native Windows apps.
I won't disagree; I just put that point to be of lower priority to many other problems.
> In addition I'd welcome if we can find a common
> ground of goals and to a lesser extent concepts that
> all layout system providers can agree on. Ideally
> we'd unite or combine our approaches.
I have worked with many GUI systems in the past; and the easiest to use was the Qt widgetset, its C++ which means its hard to code.
The huge advantage it has over swing is that the LayoutManager gets all the infomation it needs from every widget. Each widget provides a good minimum/preffered/maximum size as well as both a horizontal and a vertical scaling policy.
Using this the programmer has to do nothing more then to just place widgets in the layout manager and walk away. No tweaking of scaling-factors or whatever. It just works.
The fixing of the min/pref/max sizes is something I have been doing for quite some time and all major widgets seem to be working nicely. The problem is that its not enough. The Layout manager needs more to be able to correctly distribute extra space. Looking at Qt, this is solved using a scaling policy; each widget has a scaling policy. A JLabel will want to stay is preferred size while a JList will want to grow as big is possible. You can probably provide that info in FormLayout manually, but I want that to be known in the system so the progammer can't do it wrong.
In the respect of accomplishing a natural layout mechanism; the FormLayout fails to provide one. It fails to ask the widget the information it needs and demands the user to manually specify that info. This is the same mistake GridBag made.
I have no problem what so ever with putting extra information into the Layout Manager to override the ones from the Widget. But without any extra info (like a minimum size because the button is on a toolbar) the things should still look good.
If I put a widget in the FormLayout that has a minimum size of 100x100 and it shows up to be 0 pixels wide, something is going wrong. (i.e. you only ask for the preferred size)
If I put 2 labels next to each other, with each having a maximumsize of 100 pixels, and your Layout Manager reports the container they are in to be Integer.MAX_VALUE, something goes wrong. (i.e. you only ask for the preferred size)
What is your opinion on this?
Again; my next feature is stuff that makes GUIs look good; but my main focus was on making it easy to have nice (not good, just nice) GUIs. I like my collegues to be able to create GUIs too :)
I'm pretty much done evaluating JGoodies Forms, UICompiler, and other layouts like SpringLayout. Here's what I found:
JGoodies Forms is absolutely great for (drum roll please) forms! It is quite
easy, as Karsten says, to create forms and to make them look ecstaticly
pleasing using source code. The downside of this is that Forms is really
only good for creating forms. It isn't a general purpose layout manager.
But that's OK with me. I'm planning on using to to layout tab panels in
the "preferences" dialog.
UICompiler is also good, but at creating somewhat more general UIs. I write
"somewhat" more general since not all Swing widgets seem to be implemented.
There doesn't seem to be a templating mechanism a la JGoodies builder, so
layout consistency is harder to achieve without work. :)
I'll probably use a general purpose layout manager for the main section of my UI and use JGoodies Forms for the dialogs.
Although the alignment of font baselines is a fundamental layout issue, none of the Java layout managers can really do it. More generally most widget toolkits or UI frameworks do not provide any assistence that helps the developer or layout system or IDE to align font baselines.
The Swing widgets answer their bounds but do not indicate where the font baseline is. So a layout manager has almost no means to align component labels and will likely use the bounds to align the component. The same is true for perceived bounds: you want to align the perceived bounds and won't take pixels into account that humans do not belong to a widget - for example drop shadows or parts of a pseudo 3D effect. A workaround for the font alignment is to render labels centered inside the component bounds; if you then center align components, your font will often be aligned. That's the approach I've done with the JGoodies l&fs.
I'm glad to hear that you like the FormLayout for forms :) I use the FormLayout for almost all other rectangular layouts too. The primary reason is that I often feel a need to provide an appropriate minimum or maximum size for grouped panels. That's where the FormLayout bounded sizes come in. And I can choose non-pixel sizes like Inch or Centimeter (that honor the screen resolution), or dialog units (that honor the font, font size and resolution).
Also using the FormLayout instead of let's say a BorderLayout or GridLayout makes the layout easier to change. If you change a layout from BorderLayout to GridLayout or GridBagLayout the changes are quite large due to the API differences of these managers. Since the FormLayout can emulate these layout managers you can use a single API - and can use it's power if needed. For example if you are using a BorderLayout and now want to ensure that the north and south parts shall have the same height, you're lost with the BL.
The only layout manager that can do stuff the FormLayout can't do is Alex Prayle's ExplicitLayout; it does a great job when it comes to non-rectangular layouts like curved labels in an application start panel.
> If I put a widget in the FormLayout that has a minimum size of 100x100
> and it shows up to be 0 pixels wide, something is going wrong.
You are the one and only who has ever reported a usability problem with the FormLayout. And I haven't seen a single developer who had experienced problems like you. The FormLayout provides powerful sizing features, among others it can honor a component's [i]minimum[/i] and [i]preferred[/i] sizes; in addition Forms provides a [i]default[/i] size that shrinks the pref size to the min size if container space is scarce. Above that Forms provides bounded sizes.
If you are willing to give the FormLayout a second try, you may consider looking at the tutorial examples to learn about the basic and advanced features. And you can use the debug panel and debug utils to find and fix problems. If that's not going to work, I offer you to review your code.
Regarding the sizing responsibilities: component vs. designer vs. layout manager, I'd say that the component provided sizes are often irrelevant for style guide compliant design: the minimum component size can be an extreme value that should not stiffle the designer's creativity. The component preferred size lacks the content and can often not provide the information required for good screen design - just because good design takes many different values into account: style defaults, contexts, component and container sizes.
I would be glad if we could find a layout manager more powerful and easier to use than the FormLayout and Forms system. But if you ask me to compare layout managers, here's a semi-lattice for layout features: with [i]=[/i] for equal and [i]<[/i] a true superset relation.
a) BorderLayout < GridBagLayout = TableLayout = NaturalLayout < HIGLayout < FormLayout < SpringLayout
b) GridLayout < HIGLayout < ExplicitLayout < SpringLayout
ExplicitLayout can layout some panels that FormLayout can't layout and vice versa. And SpringLayout plus extensions supercedes both FormLayout and ExplicitLayout.
As far as I can see, the NaturalLayout can hardly implement design that follows the Microsoft layout guide lines, and it has no means to layout panels that follow both the MS and Apple Aqua guide lines. 'Hardly' just because you could introduce phantom components (much like custom Springs in SpringLayout) that would add some of the FormLayout features to any grid based layout manager.
If you are interested in a deeper comparison, I invite you to reimplement the panels of the Forms Demo. These have been choosen to demonstrate layout problems that the GridBagLayout, TableLayout and even HIGLayout cannot implement.
I really like the UIC approach and would like us to join our efforts in bringing good design to Java. And I understand that you and me may focus on different issues. It's just that we should be able to clarify the facts about the component sizing stuff and agree on the power of different layout managers. There's so much room to disagree about the ideal approach to make good design easy ;)
> To Mark:
> Although the alignment of font baselines is a
> fundamental layout issue, none of the Java layout
> managers can really do it. More generally most widget
> toolkits or UI frameworks do not provide any
> assistence that helps the developer or layout system
> or IDE to align font baselines.
Pity, I thought for a moment I had missed something. Components do have the alignmentX and alignmentY values which could, at a pinch, indicate the correct alignment point (if they were set to meaningful values).
Around 15 years ago I designed a form layout system that was based on TeX --- the display engine used the TeX output to position all text and other components. It remains the only system I have used which got all the typographic details correct.
Yes, it's a pity that the typographic microdesign of most Java screens lags behind the findings of paper-oriented typography. I just came across a well-designed book layout of 1470 - 15 years after Gutenberg had introduced printing. I think 500 years later we should be able to catch up.
Anyway, the layout of labeled UI components is more difficult than pure glyph layout as in TeX. Often two overlayed grids are sufficient for glyphs: 1) a grid to subdivide the panels/paragraphs/TeX boxes providing a systematic structure, 2) a font baseline oriented grid to align the glyphs.
In contrast component layout may require an extra layer: 3) a grid to align the perceived component bounds. The font-oriented grid 2) leads and the component bounds-oriented gets the details right. For example to align or adjust the component bounds of a JTextField, JComboBox and JButton appropriately.
I demonstrate the latter in the [i]alignment[/i] test of the JGoodies Looks Demo. As said before, I achieve this effect only with a workaround: I center labels inside the components and try to arrange grid 3) in a way that the final layout seems to follow the grid baselines. That's where a feature of the FormLayout and HIGLayout comes in: the ability to ensure that grid rows have equal heights.
Jan Tschichold, Josef Mï¿½ller-Brockmann and Ruedi Rueegg provide professional grid collections of type 1). Kevin Mullet and Darrel Sano present a layout system that structures widgets in relation to the baseline of its typographic labels.
> Yes, it's a pity that the typographic microdesign of
> most Java screens lags
It isn't a uniquely Java problem. Other systems avoid issues by not allowing form resizing (and thus transferring alignment responsibility to the designer). Java makes the task more difficult by having alternate L&Fs. Even in the Windows world there are still far too many applications with dialogs which are horrible on my machine (set to large font mode).
Traditional Windows dialog design only really works provided the design isn't too tight (because fonts don't scale exactly as dialog units) and each language gets a separate design (I think German is the usual example). Java has tried to address many of these issues, but it still needs some work.
Actually I think TeX could cope with aligning perceived component bounds as well. SpringLayout reminds me of a primitive form of TeX boxes. It could do with some springs with font relative sizes as well as the pixel sized constants.
We made a lot of forms in the last years and all our wishes could be realized by the Managers GridBagLayout, GridLayout, CardLayout and sometimes FlowLayout.
Our designer makes it easy to define and use GridBagConstraints. So, we missed no SpringLayout.
Is there a reason to use SpringLayout instead of the others ?
If yes, we will implement it in our GUI designer http://www.jeasy.de.
I believe that the JavaOne 2000 demo was a type of form layout and editor which was abandoned. In J1 2001, the Bean Builder was demonstated in technical keynote in the context of introducing the Java Server Faces project.
The Bean Builder contains an implementation of SpringLayout as the layout engine.
To see SpringLayout in action, launch the Java Web Start version (which loads a sample design), uncheck the "Design Mode" checkbox and resize the frame.
The user guide which explains how to use SpringLayout is in the Bean Builder is here:
The code for the Bean Builder is available in the distribution bundle. The class that wraps the SpringLayout is in beantest.designer.LayoutPane. Grep for SpringLayout in the designer package to find the interdependencies for SpringLayout.
One thing to note is that the Bean Builder is a component assembler (sort of like Bean Box++). You can build applications without writing code. The idea is that all the functionality and buisiness logic is encapsulated in the JavaBeans and this is a tool to assemble the Beans into applications by domain experts.
Thanks. I checked my notes, it was called the "GuideLayout" during the demo.
Wow. Bean Builder is pretty nice for a demo. Adding a bit more functionality like snap to grid, vertical align, horizontal align would make it a great replacement (or addition?) for the GridBagLayout forms in NetBeans.
We're working on a new kind of GUI Builder for
swing. It supports SpringLayout and the other
builder related APIs for 1.4.
We'd be very interested in feedback if you get
time to take a look. Its here:
> We're working on a new kind of GUI Builder for
> swing. It supports SpringLayout and the other
> builder related APIs for 1.4.
> We'd be very interested in feedback if you get
> time to take a look. Its here:
The main reason this is created seems to be that you don't directly want to generate Java code.
It so happens that this kind of product allready exists; and IMO is a lot more finished.
Please consider joining forces with the open source product called UICompiler (http://uic.sf.net), notice that the Apache licence explicitly allows you to reuse the project without open sourcing the target project.
I disagree. Given that Bob works directly with the Swing Object graph, it is inherently WYSIWYG whereas QT designer is not.
> I disagree. Given that Bob works directly with the
> Swing Object graph, it is inherently WYSIWYG whereas
> Qt designer is not.
Since Qt Designer is based around different layouters and more advanced widget-scaling technologies; you are quite right, UICompiler is not true WYSIWYG.
The usage of another widget set will naturally be a bit strange to the developer and irregularities are more then annoying for the graphics designer.
The flip side is that the project gains a very clear goal to work to and we work to enhance Swing to meet the functionality needed and expected by the modern GUI designer.
The Designer is the most 'finished' click/drag GUI designer I have ever had the pleasure to work with, and that is a huge plus on the resources side.
Expect huge steps of functionality increase per release version.
We took a look at QtDesigner. Its an interesting
idea and is, as you say, a lot further along than
most GUI builders, including ours. It seems to me
that Qt's main advantage over builders which are
dedicated to specific languages/toolkits lies in
"economies of scale". When support is provided for
a feature which is common to all the languages and
toolkits it is implemented once rather than once
for each language and each toolkit. That's all
The advantage that GUI builders designed for specific languages/toolkits have is that they can provide full
support for features which are not part of the least
common denominator. Examples in my mind are: Java's
reflection API, third party java/swing components
and the 'uncommon' parts of the swing component
library itself - like tables and trees which tend
to be implemented differently in each toolkit.
> The advantage that GUI builders designed for specific
> languages/toolkits have is that they can provide full
> support for features which are not part of the least
> common denominator. Examples in my mind are: Java's
> reflection API
What's this one doing here?
Reflection is certainly not something which I expect in a gui builder. Remember that Qt Designer is meant to complement an IDE, and the IDE is the place where actual coding is done. NOT using the UICompiler project
I have to admit that my IDE is a bash prompt with vi and ant : )
> third party java/swing components
> and the 'uncommon' parts of the swing component
> library itself - like tables and trees which tend
> to be implemented differently in each toolkit.
I agree that UICompiler does not fully exploit features from widgets like the JTable and other complex widgets. As you might have read from my eariler postings: the purpose of UICompiler is rather broad: [b]To make Swing applications look more professional, and easer to maintain[/b]. Unfortunately, plain old Swing widgets don't have the 'finished' look that is required to just take a widget and use it. Each widget needs extensive tuning for the end result to look good.
For this reason Qt Designer gives me something I can use; a professional looking set of widgets that we can make the Swing widgets look like.
My point, in the end, is that if your view of a GUI builder is to allow plain Swing widgets to be placed and tuned, they you have gained nothing. The user will still be repeating a lot of actions for each table and each JList.
Stealing good ideas is infinitely better then creating bad ones your self.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.