Joshua Marinacci's Blog

A Response to GUI Building: tool vs hand coded

The debate of hand coding your GUI screens versus using a tool has come up again. I suspect that Stuart wasn't expecting quite the volume response that he got. For some of you this is old hat and I suspect we aren't going to come to any conclusions here. I would like to say one thing, however. We need to split issue into two separate items that are actually independent, though related.

We like to say it's a matter of writing your GUI by hand using GridBagLayout (which is the one layout manager always discussed) vs. using an proprietary opaque visual tool like NetBeans GUI Builder or Apple's Interface Builder (even more opaque). I think this is wrong. There are distinct issues here that should be handled separately.

Visual Tool vs Hand Coding

First there is the issue of using a visual tool instead of hand coding your GUI. I think there really is nothing to decide. Laying out your GUI is a visual task. Use a visual tool! End of story. I wouldn't design a newsletter without a visual tool like Quark Express. I wouldn't edit photos without a visual tool like Photoshop. Why should I design my GUI without using a visual tool like NB? That's madness!

Now notice I didn't say that you have to only use a visual tool. It's perfectly acceptable lay out your GUI initially using NetBeans and then add tweaks afterwards. In fact, I do this all the time. NetBeans will create an uneditable method initComponents() called from your form's constructor. initComponents() does the initial layout but you can then customize it however you like after that. You've got field references to every component. You can use them to do all sorts of cool things like adding painters, tweaking the layout of certain components, changing defaults, adding bindings, and pretty much anything else you want to do with hand code. It's not one or the other. You can use hand code and the GUI builder.

But what about the noneditable code? It's too complicated to understand! Why yes, that's right. It is complicated (though actually fairly straightforward, if verbose). However, you are never supposed to edit that code. That's why it's in an noneditable block! :) The form XML file is the definitive representation of your GUI. The generated code is simply an implementation detail with a few nice side benefits (like not needing to have NetBeans running to compile your code with Ant). We could just as easily generate bytecode directly and never show you the Java at all. Or we could parse the XML at runtime instead of compile time. You should never have to deal with that generated code just as you should have to directly deal with the bytecode generated by javac.

Proprietary vs Standards based

This is the other big thing I see mixed up in the hand code vs GUI builder issue, but it is an entirely separate issue from the previous one. I agree that standards are better because you do not want to be locked into a tool. Imagine you tried to move away from Visual Studio for your .NET apps. You'd find it pretty difficult to modify VS's form files. But the solution here is not to throw away visual tools. The answer is to use a tool that saves in an open and hackable format, preferably with open tools.

NetBeans is an open source product (and has been for many years). The GUI builder (formerly called Matisse) has even been ported to Eclipse. The form files generated by NetBeans are straight forward XML files that are actually pretty easy to modify by hand when necessary. So you can see that NetBeans's GUI builder is not the lock-in with proprietary specs that some people might think it is. It's actually quite open and hackable.

So we have reduced the problem to one a lot smaller. The only downside to NetBeans GUI builder is that it's not a standard format, meaning it hasn't been documented and there is no DTD. The format could change in the future as we add new features. Opening up the form.xml format would be a great thing. This is an issue we are aware of and hope to address in a future release of NetBeans. [Disclaimer. I'm not the keeper of the NetBeans roadmap and I'm not saying that we have immediate plans or that it's scheduled for NB 6.0 (it's not). I'm simply saying that it is on our horizon and something we would like to do. Everything in this post is my opinion only.]

Conclusion

So I hope I have split the issue successfully into manageable parts and cleared up some misconceptions (you'd be surprised how many people aren't aware the form files exist and think that NetBeans would read back their changes if only they could edit the 'blue' code blocks). Please send us you feedback. We really do listen and we really do want to hear what the community wants.

Thanks, Josh

Comments

• A few years ago I thought that re-parsed code (how Eclipse does it) for JavaBeans and layout code was a bad thing. Now I don't think so anymore. I think that NetBeans should move towards parsing the code and do away with the proprietary XML altogether, just as SwingDesigner does for Eclipse with great success. IT would be OK to have some requirements for the re-parsable code, like that it needs to be in a special method and have no funky stuff, but that would be OK. Especially since the IDE could warn you about un-parseable code directly as you type. The only other alternative is a 100% standardized XML format and a great push to make all the important IDEs support it.

  The problem with lock-in will always be there with both source and proprietary XML. There's no way around it and a lot of projects can not use an IDE tool just for that reason. MS don't have this problem, there is only one IDE...

  I would also like to push for a better layout manager for manual coding. MiG Layout (www.miglayout.com) can do everything that FormLayout from JGoodies and GridBagLayout can but it is also resolution independent, has per platform gap defaults and is super simple to use.

  Matisse that writes code for a layout manager like MiG Layout with no XML stuff would make the tool a lot more transparent as you could easily switch back and forth between GUI and pure code layouts. Of course, for this to really be viable (dispensing of the XML) we also need a new JavaBean spec that gets rid of the single method call property setting. Since the value of a property must be expressed like a single argument you simply can not create advanced beans that still have decent usability.

  Posted by: mikaelgrev on June 14, 2007 at 11:18 AM

• I'd prefer a visual form editor that wasn't tied to a particular IDE (or two). I am not too bothered if the resulting form descriptions are run time parsed (XML) or generated code.

  Posted by: mthornton on June 14, 2007 at 01:04 PM

• Counter-example: If I have to design a single newsletter or a single webpage, then I will use a visual tool. But nobody designs each and every page of a big, full-blown website with these tools. A decent content-management system will provide a sophisticated templating mechanism. The main layout templates may be initially designed with a visual tool, but typically they will be hand-crafted carefully. The designers will have a deep understanding of every single line in their CSS stylesheets. A single page will be composed of a few well-defined layout elements. These page definitions will not contain any visual boilerplate. Non-editable and non-understandable code in each and every page is unacceptable in this scenario.

  Posted by: scotty69 on June 15, 2007 at 03:19 AM

• The main layout templates may be initially designed with a visual tool, but typically they will be hand-crafted carefully. The designers will have a deep understanding of every single line in their CSS stylesheets.
  To some extent this is a result of the poor level of compliance by browsers with expected CSS behaviour. You have to hand code to get round those bizarre results that are otherwise seen by users of browsers such as IE6.

  Posted by: mthornton on June 15, 2007 at 03:29 AM

• I personally welcomed the WYSIWYG form editor Matisse, it took long for Java to get one and it does feel awfully inspired by the layout mechanism of Visual Studio even if few Java developers admit to even look over at the dark side.

  But imagine the standpoint of other IDE's who worked hard to get decent WYSIWYG editor through the GridbagLayout or FormsLayout (JDeveloper for instance): http://blogs.oracle.com/shay/2006/03/02#a74

  In the perfect world, hand written and generated UI code could be parsed and edited all together. However this simply does not work, I've seen it happen so many times. Initial layouting works great but sooner or later your builder fails to render and its bye bye to easy maintenance.

  So for the time being, I too subscribe to the way NetBeans does it, locked code or not. I do hope time will help come up with a less rigid initComponents and that it will become the standard way across various IDE's.

  Posted by: mrmorris on June 15, 2007 at 04:01 AM

• Netbeans suffer the eternal code editor problems.. .I am trying here, but it is still not comparable to Eclipse.. The Java community is skeptical but also able to change.. the first impression when I tried Netbeans 5.5.1 was "why the code-complete is so slow ?" and "why the code formatter don't detect mistakes like Eclipse?"In my new open source projects, I am free to innovate, then I am really betting in Netbeans and dreaming with the fantastic 6.0 showed during J1, but for now the basic features like code editing and formatter still being anti-marketing.. (and, of course, Matisse is fantastic).

  Posted by: felipegaucho on June 15, 2007 at 04:21 AM

• I like the ease of use Netbeans gives me, but the XML is stored in an external file. Around here everyone is afraid that this will complicate source code management, now people have to remember to check in 2 files instead of just one. Can we put the XML IN the source code, say in some special comment block?

  
  /*{
  XML stuff do not hand edit blah blah
  }*/
  

  Posted by: aberrant on June 15, 2007 at 06:09 AM

• Also can anyone point me to something that talks about Clearcase integration with Netbeans? How one sets it up, how it interacts with views and stuff.

  Posted by: aberrant on June 15, 2007 at 06:14 AM

• Josha, the problem with the Netbeans editor (to me at least) is about *separation of concerns*. I should be able to do visual layout using a visual editor and coding using a code editor. The problem with Netbeans is that it insists that I only modify the code inside the guard-blocks from within its menus. It simply isn't natural! I should be able to modify code from within the editor directly.

  Let's be honest about things: the *only* reason Netbeans don't support this is because it is extremely difficult to implement. This is not one of those "by design" things that they wouldn't change even if they could.

  Gili

  Posted by: cowwoc on June 15, 2007 at 06:20 AM

• I think GUI builders are getting better all the time, but I'd quibble over the idea that laying out a GUI is strictly a 'visual task'. I remember a Usenet discussion on a similar theme many years ago about the evils (or otherwise) of WYSIWYG tools for web page design, and one contributor punctured the relentless to-and-fro with a single, very telling, criticism. He said, very simply, that the problem with a WYSIWYG tool is that it gives the user the misconception they are in control. (They aren't The user's web browser is.)

  While I agree that hand coding is back breaking work, I think UI editors would do well to drop the WYSIWYG metaphor and represent the UI more symbolically, as a hierarchy of components with layout behavior, who's ultimate form will only be decided at 'runtime' by the graphical environment (screen size, fonts, language...) of the user's computer (or mobile device.)

  A few months back I did consider writing such a tool, based on some rough 'back of an envelope' sketches. The GUI is seen as a nested series of panels which the user can drill down into and work with one at a time. The 'visuals' for each panel are not 'literal' ("this is what you will get") but 'functional' ("this is how the children will be anchored, sized, balanced, etc...") The tool has its own little 'icon grammar' to describe at a glance how a layout manager would control each cell. The problem is, writing a UI builder is a huge undertaking, which involves more than just writing the visual tool itself, and I didn't have the time to spare. So it was a bit pointless even starting. :)

  Posted by: javakiddy on June 15, 2007 at 06:38 AM

• Just use what works. Consider this. My mind's eye is my visual editor. I "see" my UI before I start coding it. Code generators are a hurdle that get in my way. If I can't layout something simply using Border or Flow, I write my own. I probably have a fatter bus to the right side of my brain that most do though. Point is, nobody knows you better than you. Screw what "they" say. Do what works for you.

  Posted by: raytucson on June 15, 2007 at 08:25 AM

• cowwoc NetBean does let you edit the code with the editor and the visual layout using a visual tool. The problem is that we have the uneditable code blocks that you can't edit. The solution isn't to allow editing of them. I think the solution is to remove them completely. The XML should be converted to bytecode at compiletime or else parsed into the onscreen components at runtime. Presto, no more uneditable blocks to worry about. We already have the separation of concerns by having the XML files. We just need to get rid of the rest (IMHO).

  Posted by: joshy on June 15, 2007 at 08:30 AM

• felipegaucho: I think you will be very happy with NetBeans 6. It has a brand new code editor and modeler, as well as many new features. On the Matisse side, something that we didn't show at JavaOne is our new visual editor. I'll cover it here on my blog once we get M10 out the door.

  Posted by: joshy on June 15, 2007 at 08:33 AM

• May I suggest GOLA at http://gola.mathnium.com which I call the GUI Objects Layout Assistant. It allows you to visually layout GUI components for Swing, and generates the requisite code which is quite readable, all within the context of the Pagelayout layout manager at http://pagelayout.sourceforge.net. Both are completely free.

  Posted by: varan on June 15, 2007 at 08:39 AM

• The separation of the issues is a very valid point. Initially, I gave up on visual editors because of the second issue: tool lockup. Having done so, I delved into the GridBagLayout and studied it really well. This has done a world of good to my GUI coding (even if I say so myself). Knowing what really goes behind the scenes and having a fine-grain control over dynamic behavior of the GUI goes a long way.
  And besides, I do use a visual tool: paper and pencil :-).
  In general, I believe GUI tools should write java code, so that when the screen gets too complicated to maintain visually you could "switch to manual" and take it from there.
  Incorporating a one of the existing external layouts into swing might help too - it might be worthwhile to do a poll about who uses what and why. As for me, it's mainly GridBagLayout and Box.
  

  Posted by: mich_barsinai on June 15, 2007 at 09:25 AM

• I'd like to ask another question here. Is there anything you'd like to do with your GUI that you *cannot* accomplish by adding code after the initComponents() method is called?

  Posted by: joshy on June 15, 2007 at 09:30 AM

• GUI Builders are improving and are nice tools for static layouts and to learn layout management. Achieving dynamic layouts, where you rearrange components at runtime is difficult to do with GUI Builders, thats why I code it by hand (correct me if I am wrong). To predict the right resizing of a complex GUI only works If you understand the way the LayoutManager works. I used Matisse some time ago and tried to produce the same layout twice. The static result looked the same, but on resizing I saw that they where slightly different. There should be an easy way in the GUIBuilder to visually show the resize behaviour at construction time.

  Posted by: javanewf on June 15, 2007 at 11:35 AM

• @joshy

  Here is a list of what I think can't be done.

  If I have a group of components that can be displayed horizontally or vertically then I need to hand code it. Either that or I have to let initComponents() run then rearrange myself later, but that seems like a waste.

  I can't use custom components in layout managers where insertion order controls display order. Example: BoxLayout, FlowLayout. Actually I don't know how I'd use a custom component in the designer anyway. I'm sure I'd have to package it up separately and add it to Netbeans. Thats not always an option.

  Use a custom class the inherits from JFrame or JDialog in the designer.

  Use a custom JPanel class in the designer.

  Add some kind of listener before initComponents() is called.

  Use factory methods to construct my components instead of whichever constructor is chosen for me.

  Use a method to build my component that I can override in a sub class.

  Use a JTable without it calling setModel and creating a useless tabemodel.

  Posted by: aberrant on June 15, 2007 at 11:44 AM

• Josh--although Swing apps aren't what I'm usually working on, I've used NB for several projects and appreciated what the form editor had to offer. That said, there are some problems--I'll mention two.

  1) Once you've started working on a form, you simply cannot safely edit that file (esp. the guarded blocks) in an external editor. I realize there are comments, etc. but it's certainly happened that I went in for a "quick fix" and either made the form unloadable in NB, or lost my changes when I opened NB. That's a bummer.

  2) The "code" properties panel is 90% ludicrous. For any element, you, what, click on the code block you want to edit, open up a separate window, and type in the code? Who designed that? It's the silliest GUI approach I've ever seen. There are too many steps to get anything done, and too much that is potentially hidden in individual elements.

  Point 2) highlights what I think is more fundamental--it's all well and good using a visual editor until the editor doesn't do what you (think you) need it to do. Then you're stuck, doubly so if you can't safely edit the code by hand.

  I'm glad you've picked up the theme again, but the discussion is not over.

  Regards, Patrick

  Posted by: pdoubleya on June 15, 2007 at 11:46 AM

• Sorry about the formatting, let me try again.

  If I have a group of components that can be displayed horizontally or vertically then I need to hand code it. Either that or I have to let initComponents() run then rearrange myself later, but that seems like a waste.

  I can't use custom components in layout managers where insertion order controls display order. Example: BoxLayout, FlowLayout. Actually I don't know how I'd use a custom component in the designer anyway.
  I'm sure I'd have to package it up separately and add it to Netbeans. Thats not always an option.

  Use a custom class the inherits from JFrame or JDialog in the designer.

  Use a custom JPanel class in the designer.

  Add some kind of listener before initComponents() is called.

  Use factory methods to construct my components instead of whichever constructor is chosen for me.

  Use a method to build my component that I can override in a sub class.

  Use a JTable without it calling setModel and creating a useless tabemodel.

  Posted by: aberrant on June 15, 2007 at 11:46 AM

• Josh, I think the issue is about why there is such a thing as "uneditable code" in the first place when an interpreted language like Java should make it easier for tool builders to implement visual design tools that can manage any editing of the code from the user (like Borland use to do - granted it was AWT at the time). So use byte code manipulation if you have to or real time round trip conversion to some internal format during design, but don't burden the developer with "uneditable code" or xml for that matter. For those of us who code for various platforms and possibly other JVM implementations, there will be times when yes you may have to tinker with initComponents(). The visual tool should be smart enough to deal with it and not take the easy way out. The question should be, why isn't reflection and AOP techniques enough for visual tools to handle editable GUI code?

  Posted by: dljava on June 15, 2007 at 11:50 AM

• javanewf NetBeans does provide some visual indicators of a components resizability, but I agree it's confusing and could be better. That's something we need to address.

  patrick It's true that you shouldn't edit something in the uneditable blocks. However, NB shouldn't break if you do. It should just overwrite the changes. Could you provide me with an example of where it broke? That's a bug we must fix.

  patrick We are building a new code customizer that should make it a lot easier to tweak the generated code. I think you will all like it.

  aberrant

  
  yes you can dump the layout and re-lay out things again. All though NB supports layout managers besides group layout. You can visually use boxlayout, for example, to get horz or vert components.
  you can change the order of components using the context menu or dragging them in the inspector. You can use a custom component by adding it to the palette or just dragging it from the project view to your open form (this is new in 6.0, i think).

  You can use a custom subclass of jframe, jdialog, or jpanel by changing the constructor in the properties sheet to use your own class.
  yes, you must add listeners after the components are created. the same as hand code. why is adding listeners after initComponents() not okay?
  you can call factory methods by customizing the constructor
  Yes, the jtable will be created with an empty model and then your new model will replace it if you call setModel() after initComponents(). This is less than a millisecond of code and maybe 1000 bytes of ram that is then garbage collected. not a big deal.

  Posted by: joshy on June 15, 2007 at 12:14 PM

• dljava. I agree that we should get rid of uneditable blocks. The solution is not to make everything editable, though. The solution is to get rid of the code for generating the GUI. GUIs must be created using a declarative syntax. The language used to declare the GUI is an implementation detail. The various options all have their strengths and weaknesses (XML vs uneditable javacode vs a binary blob vs NIB files... etc.). However, the key here is that they are all declarative. Using Java code as the storage of this declarative description is a bad idea since it's tempting to edit the code when really you can't.

  Now you can edit the code in limited ways using the code customizer (which is getting a *lot* better in NB 6, btw.) but you still can't have full reign. And here's why.

  The dirty secret of round tripping to code (by which I mean full turing complete Java code, not HTML "code"), is that it is impossible to do 100% correctly. You cannot represent visually every possible GUI that can be created using Java code. But of course that's why you have the option to do both. Here's an simple example of something that you could never parse back in and show on screen:

  
  JPanel panel = new JPanel();
  for(int i=0; i

  Ignoring my obviously incorrect JDBC calls, you can see that any layout which is calculated cannot be parsed and displayed on screen. The only way to show it is to execute the code, which in this case means you have to run the project completely and connect to the database. Not what you want your visual designer to be doing.

  Now in practice this is not a problem because 99% of gui code actually is declarative, and for the few times you need to do something like this you can do it after the initComponents() method [or by customizing the constructor].

  Posted by: joshy on June 15, 2007 at 12:22 PM

• I would like to see support for jgoodies in Netbeans. I used Netbeans visual editor, but with jgoodies it is much easier to hand code and final design is much cleaner.

  Posted by: gvozden on June 15, 2007 at 12:52 PM

• Josh, if I see another case where either the form file or the .java file is unparsable, I'll report it. It was over a year ago that I was doing any work with NB. Thanks for the reply. Regards, Patrick

  Posted by: pdoubleya on June 15, 2007 at 01:52 PM

• Hi Josh,
  I think the main problem that most people have with GridBagLayout and similar types of GUI code is that while they were written to be "toolable" they're virtually unusable without a tool. This was the philosophy that was applied when they came up with GridBagLayout and again with JSF. The lack of tool support for JSF (outside of NB) continues to make it difficult to work with.

  I've looked at the JGoodies layout and the TableLayout and have found the TableLayout easiest to use. It would be nice though if we had something that was closer to the way an HTML table worked.

  Regards,

  Mark

  Posted by: phidias on June 15, 2007 at 03:52 PM

• I say runtime parsed is way better than prerendered code. It may need runtime support, but it also means that you can easily load alternatives. Side comment, why do we still do so much HTML coding in text several years after good WYSIWYG came out? That provides some interesting food for thought, I think.

  Posted by: tompalmer on June 15, 2007 at 10:05 PM

• But thanks for the comments on form XMLs. I didn't know they existed.

  Posted by: tompalmer on June 15, 2007 at 10:07 PM

• @joshy

  I relent! I tried to stump you failed. Now if I could just figure out the best way to use Netbeans with clear case I'd recommend it as the replacement for JBuilder here at work.

  Posted by: aberrant on June 16, 2007 at 06:02 AM

• personally I don't like the FreeLayout in NetBeans. I still prefer the GridBagLayout since it is easier to control and to refactor. The Mattisse designer is not that reliable when working on complexer forms and it happens frequently, that things get completely messed up when inserting a new component in a well populated panel. It also happens quite often, that in designmode everything looks fine but at runtime on a client's desktop the form gets messed up because of different screen sizes. Don't rember having seen this when using the good old GridBagLayout.

  On the other hand, the NB layout designer for the GridBagLayout looks like a prehistoric tool and is a mess to use for serious layout design. Would like to have JBuilder X's layout designer which worked very well for GridBagLayouts.

  Often I choose to edit the layout properties (GridBagConstraints) in the component's property pane. But the annoying behavior of NB to scroll the fields out of view, after every change makes it practically unusable.

  Concerning the closed code block containing the layout stuff is not such bad. The only thing I'm really missing here is a possibility to change the component type after having inserted it. Say be able to change a JTextField into a JComboBox for example. This happens really often and it's just tedious to have to edit the java and form files outside NB to accomplish such a basic task.

  Finally, I agree that GUI lay outing is a composite task of some designer tool and developer's manual intervention in the constructor. But I would very much like to have a better GridBagLayout support in NB

  Posted by: interact on June 16, 2007 at 11:33 AM

• Josh, I couldn't see the code above but you've made your point and it's valid. When the GUI layout is computed in this manner you'll run into parsing problems for any design tool, but I would argue that "computed" layouts should use some type of flow layout and the design tool should accommodate for variable length components.

  I think the following blog entry points out some more fundamental issues with the separation of concerns between the initial painting of the GUI and the wiring of the controller aspects and how ultimately productivity is affected by either approach. IMO, the tools should try to satisfy both camps.

  "Has Matisse Really Changed Anything?"
  http://www.javalobby.org/java/forums/t97468.html

  -dario
  

  Posted by: dljava on June 17, 2007 at 12:52 PM

• I think this didscussion is based upon the video produced by a guy who did not bother to look at what was available to 'handcode' the GUI other than GridBagLayout. GridBagLayout may not be extremely programmer friendly but there are so many other layout managers that could have done his job only in a few lines of code, without the need for any 'GUI builders' which proclaim to do everything that you want to do.

  It is astounding that the ignorance or laziness of one persone has led to so many people pontificating on the subject.
  

  Posted by: jproguru on June 17, 2007 at 07:11 PM

• Josh, first of all thanks for your job in netbeans IDE, I've been using it since 3.1 release
  , and Has improved a looooot !!!! It's a nice IDE very easy to use.

  The only 'problem' I have is Matisse. Well not matisse, these xml forms that it generates. In My company we work with jbuilder foundation, now that JBuilder 2007 has a 'bad' designer in my opinion (Eclipse VE), I would like to port my JBuilder projects to Netbeans 5.5. Impossible ! I cannot port my JBuilder generated GUI and open it with matisse! . So my thoughts are that we need a GUI builder that should parse java code, without XML. I would like also to be able to edit the code and see the changes in Matisse.

  Please, I would like to port my company's JBuilder foundation projects to netbeans !!!!

  Thanks and keep on the good job !!
  

  Posted by: aleixmr on June 19, 2007 at 10:58 AM

• I strongly disagree with this "use visual tools for visual tasks" thing. And I'm surprised to see this "end of story" comment. I've found that visual tools can increase or decrease the design and layout productivity. It depends.

  
  You mix design and implementation, and don't mention meta design. To design is more than doing a layout. The design process may include steps poorly supported by today's visual tools.

  
  Matisse for example poorly supports designing a whole bunch of consistent and style-guide compliant screens, as is the case with most visual tools. They don't work on meta designs. The layouts done with these tools are almost unrelated. And its costs a lot to make 100 or 200 screens consistent in a team.

  
  I wouldn't build a local bus schedule with 100 pages with a tool like Matisse. If design matters than consistency matters. A simple and cost effective way to achieve consistency is a meta design, where you specify the design decisions common to a set of designs: fonts, sizes, colors, orientations, layout, layout positions. Most professional designers use grids to further speed up their design process.

  
  But none of the visual builders I'm aware supports a meta design based production process. Therefore I recommend to developers to check whether they can achieve consistency with other approaches: custom layouts, design builder classes, Java coded Meta Designs.

  
  If a Meta Design also involves runtime state information and user access rights, visual tools lag even more behind the productivity you achieve with non-visual builders.

  
  I recommend to use an appropriate design production process, that may or may not involve visual tools depeding on your goals, team members, design quality, level of consistency, etc.

  
  Karsten Lentzsch, JGoodies

  
  

  Posted by: karsten on June 19, 2007 at 12:28 PM

• 2 Joshi: Regarding Matisse I personally have two pet peeves that caused me to abandon Matisse learn how to hand code GUI in JGoodies.

  
  Fragility of the form -- adding or moving/resizing of a component causes total collapse of the form's layout. In addition it is extremely difficult (I have not found any easy way) to adjust the layout. If you ever have tried to position few images in a document in the MS Word, then you know what type of experience I'm talking about.
  Abundance of JLabels -- on my panels, circa half of components are JLabels with some static text (e.g. Name, Street, ZIP). Actually, I need no reference to any of those texts. In JGoodies there are methods addLabel and addSeparator, so I don't need to have 30+ private attributes in class, half of it useless.

  Posted by: kolisko on June 19, 2007 at 01:58 PM

• It seems that my experience is very similar to Kolisko's one. I'm sure that Matisse will keep getting better but in it's current state it's very frustating when you drop a new control or you just resize a component and you loose your layout.

  Another thing I dislike about the protected blocks is that sometimes your source loses format and for some reason the automatic formatter ignores protected code and you can't indent it manually. It has happened to me sometimes. I know, I should have filed a bug if it's not already there.

  So I started coding my layouts using ZoneLayout http://www.zonelayout.com and i'm very pleased with it. It looks a little weird at first but it's very easy and you get some sort of visual representation of your controls layout.

  Posted by: phantom22 on June 19, 2007 at 04:02 PM

• I recently worked on a large scale Swing UI in a large developement team (all with various levels of Swing experience). Using a GUI builder in this case would have been an unmitigated disaster.

  Our visual designers had gone to great lengths to define the various layout rules, gap sizes, colors etc that were to be used across the project.

  We created a suite of form builders tailored to the visual design requirements. The builders (along with a custom value model framework) lead to extremely fast development times and highly consistent results. Developers could turn a UI design into a working layout in a few lines of code.

  Of couse this would be a lot of effort to go to for a simple swing app writen by one person, but even then I still use builders (c:

  Cheers
  Andrew

  
  

  Posted by: pietschy on June 19, 2007 at 10:29 PM

• Joshua: Just by the number and style of responses, you can tell that people are not (completely) happy with Matisse. For more specific details look at each post specifically.

  As for the .form files, it might be as open as possible, but it still not Java! If Eclipse or any other builder came out with their own format, none of the community would like it. Now, if at least it solved all of the problems people have it could be better accepted.

  I liked Karsten's (JGoodies) post.
  It made me think, that Matisse could be an excellent layout tool (after you have constructed your form manually), and if it produced code that can be readable and tweakable.

  Posted by: montechristos on June 20, 2007 at 12:15 AM

• I second to pietschy's comment.
  In projects with a large number of windows even a small paper checking all 'meta' design rules and give guidelines for builders is more helpful than any visual builder.

  regards
  Wolfgang R.

  Posted by: wrostek on June 20, 2007 at 09:36 AM

• Sorry, but "madness" is getting carpal tunnel syndrome from all the mousing around between the form window and the properties and the component tree (renaming all the components I want to reference) struggling to get Matisse or any other GUI builder to put the components where I want them and understand that I'm not trying to align A with B, I'm trying to align A with C.

  I use a visual tool called paper and pencil. It's always faster for me, and my hand and wrist don't hurt.

  It's not black and white. OK? Can we move on now? Thanks. I have some hand coding to do. :-)
  

  Posted by: detorres on June 20, 2007 at 09:46 AM

• While I, too, like to use paper and pencil (+ an eraser) and hand code, I think that good GUI builders are essential.
  Sure, an experienced swing programmer might or might not like hand-coding more than visual GUI building, but for the newcomer they are life savers. And a community must make life easier for newcomers if it wants to survive.
  I have a friend who is toying around with programming. He really likes VB.net, not because of the language itself, but because of the drag-drop-run process of building an application in visual studio. Matisse goes a long way in bringing people into java/swing, and that is a worthy target by itself.
  

  Posted by: mich_barsinai on June 22, 2007 at 02:46 AM

• I wouldn't agree with " laying out GUIs is a visual task".

  The term GUI has far more meaning that just a static dialog or a form that a GUI builder can deal with.

  I'd say, laying out static forms or dialogs is a visual task.

  Posted by: viswanath_b on June 23, 2007 at 09:42 PM

• Posted by: sunshine18 on July 22, 2007 at 12:23 PM

• why cant netbeans use an approach that is used by MS VB6 ide
  in that
  - we don't get to know the implementation code that is used to place the

  component .
  - the coding for form design is independent of logic coding(form designed is

  saved as 'form file').
  this simplifies the problem of re-editing the form.ide will load the form file and

  let you re-edit it.
  having said this, the GUIBuilder should be very accurate and shouldnt disappoint

  developer in any case (as he has to rely only on this for gui design)
  and if the 'form file' is standardized then we'll no longer be locked to one ide,

  each ide will render the components on form according to 'form file'.
  - to code the logic we simply double click the component and respective event

  handling block appears to code it there directly.
  with this approach developers can become more productive as they'll spend less

  time in designing UI (than they used to)

  
  

  Posted by: sunshine18 on July 22, 2007 at 12:28 PM

• sunshine18 This is roughly what NetBeans does right now. The implementation code is hidden and readonly. The coding for form design is independent of logic and is stored in a .form file. The implementation code is simply regenerated from the .form file. You can right click to write event handling code for any component. The only thing we don't have yet is a standard cross-IDE format for the .form file. I hope we'll get something like that in the future.

  Posted by: joshy on July 30, 2007 at 04:59 PM

This work is licensed under a Creative Commons License.