>_Chaotic Java

NetBeans 5's Matisse impressions

· IDEs

The impressions I got from NetBeans's Matisse are mainly by comparing the Matisse experience to the experience I get from Visual Studio 2005's user interface editor, and to the only Java user interface editor I so far considered as being the best, which is IntelliJ's GUI Designer. Working with Matisse put a smile on my face; Finally, a user interface editor to match Visual Studio's GUI editor! A claim not easy to make by all means. That said, I thought the same about IntelliJ's GUI Designer which was better until Visual Studio 2005 came out, so I just hope NetBeans' developer team can keep up the good work they're doing in innovating the GUI editor experience. Some of Matisse's features really made me raise an eye brow thinking "How come no one did That before?". I hope Matisse's developers keep up the inspirational work, and use it further to enhance their Java code editor, still not reaching the bar IntelliJ set. I babbled enough. Now for my likes and dislikes:

Dislikes

  • XML representation of forms Frameworks today seem to dive into a new world of separating user interface layout from its logic. Instead of hard-coding your graphical user interface into the code, write only the logic code and describe all the events, layouts and control placements in an extensive XML file. Examples can be seen in XAML for the Windows Presentation Foundation and also IntelliJ's GUI Designer works like that.
  • No Layout Designers Matisse uses its own layout designer, which allows it to place controls anywhere on the form, attaching them to other controls and to the borders of the form. However, if the user wants to use one of Java's Layouts, he cannot.
Not a lot of dislikes, most of them can be treated as minor inconveniences to most users, if an inconvenience at all.

Likes

  • Matisse's Layout Manager The layout manager Matisse uses, org.jdesktop.layout, is just great. It allows you to place a control anywhere: The control will be aligned with other controls by size and location. The location and sizes of controls will be eventually determined by the look and feel of the application when it's being run, and "snapping" of controls will take effect then.
  • The Editor I think what makes the layout manager of Matisse better is the editor Matisse provide for it. Snapping to other controls, both to the location of the snapped control, horizontally or vertically, and to the size of the snapped control, so that both controls keep the same length or height. More importantly, its ease of use is amazing, making a complex design easier by allowing to view the controls as you move them, highlighting the target container of the dragged control, and showing suggestions for alignments to other controls as you drag the control over the form.
  • Relation between controls is saved After a control has been placed, viewing its alignment is as easy as clicking it. Alignment lines will show up to tell you how the control is aligned, hinting at how it will be resized and relocated as the form is manipulated.
  • Easy Designer The designer's user interface itself is very simple and easy to use, and yet very powerful. With just a few buttons it offers you the ability to align groups of controls to one another, to switch between code and design views, and to edit every property, event and code generation aspect of any control or form.
  • Connections The Editor allows to define connections, which are simple event-to-property action connections. With a simple three step wizard you can set a control or JavaBean's property to change as the result of another control or JavaBean's event.
  • Small footprint and high speed Even after adding several controls, panels, alignments and connections to the form, the footprint and speed of the editor showed no significant change.
  • Controls' State State of controls can be set to be saved into files, using normal Java serialization.
  • Form Preview Beside just watching the form in the designer, you can choose to view a preview of it. This is not a special thing in itself, except that it doesn't require you to compile the class file for it, as some editors would require.
  • Generated Code The generated code seems to be cross-IDE, so that's a huge benefit when working with a team that uses different tools to write code. The first thing I love doing with generated code (or XML) of a form is to change it and see how the editor handles it. Visual Studio, for example, just stops displaying the form, or crashes completely at times. To my surprise, the bits of generated code used by the presentation are read only, meaning you can't change them using the NetBeans editor. This is a great feature, preventing mistakes and allowing the generated code to be separated from the form's logic, even if written in the same class file. Obviously it's not protected outside the IDE, so I changed it and it didn't even budge the editor. A quick look to the folder will show a .form file for the form, describing the components in it. The editor uses this file to regenerate the code every time it changes. Surely, the code wouldn't compile after I messed with it - But a quick change to a property regenerated it from scratch and all my hacks were gone. This is robustness I have yet to see in any GUI designer.

Some Conclusions

Obviously, Matisse has won its place as the best GUI editor, for me. It's just great, and I do want to see the entire NetBeans project grow to the brilliance in that GUI editor. Since NetBeans still doesn't reach the level I'd expect a Java editor to reach, I can't suggest it to anyone; But if you're writing a windowed application, you must give it a try. It can really change the way you work, from fighting with GridBagLayout to just placing controls on the form and watching them resize and relocate exactly as you'd expect them to. I still haven't finished my inspection of NetBeans. Inspecting NetBeans' Profiler is just around the corner, and as I work more and more with NetBeans, I see more things I like and more things I dislike about it. As soon as I have a few spare moments, I will post it.

Comments (17)

Rob Abbe
You can use any of the Java layout mangers with netbeans. Just right click on the form and change the layout.
Avah
While I admit I haven't found this option and not right clicking means I wasn't searching hard enough, I've said it before in different forums and I will say it again now: A good user interface doesn't place a feature only in the contextual menu, sometimes referred to as the hidden menu. Why isn't it shown in the properties page of the form/panel? But even after realising my mistake I stick to my words. Matisse doesn't allow you to work with the layouts as you'd expect - I implore you to downloading IntelliJ IDEA to look at what I mean for comfortable work with the layouts. There, editing the grid in GridBoxLayout is as simple as a few clicks - add a column, add a row, rowspan, colspan, anything you'd want - With a very comfortable interface allowing you to quickly create a complex GridBoxLayout form or panel. I'm not saying I prefer it - I prefer the free form, "snappy" layout Matisse provides. But when I'd need a GridBagLayout on a single panel one day, it seems like it's not going to be easy to do on Matisse.
Roumen
There is a second slightly hidden feature for Gridbag called Gridbag Customizer. Check the older 4.1 tutorial for details in section "Using the gridbag customizer to adjust the layout": http://www.netbeans.org/kb/41/form_getstart.html We're working on fixing the discoverability issues... :)
Glenn
Avah: 1. Would you care to comment on Matisse vs. Interface Builder? In other words, how does Matisse compare with non Java GUI builders? Anything missing of substance? 2. Its interesting and very good that the code generation is robust, but this begs a question: why show the code at all, by default? After all, a compiler, by default, doesn't show assember - why should a full coverage GUI builder be any different? If there is a NEED for it, doesn't that suggest a deficiency in the GUI builder? thanks, Glenn
Avah
Glenn: 1. Of course. I will start up Interface Builder, as I haven't used it for quite some time, and write it up. If I get your point clearly, you want to see if up unti lnow the limitations in Java GUI designers arose because almost all Java IDEs are written in Java? 2. Well, I can only give my own idea as to why, but I think this is the right track: The code generated Can be referenced to from the user's code. For example, "the big method", initComponents, which does all the GUI initialisations as defined by the user, is called from the form's constructor. Hiding it would make the code a bit... Odd. More than that - The header of an event method is read-only, while the code inside is user-code. Hiding the method's header would be more than Odd, it would be unreadable. Thanks for commenting!
Avah
Glenn, I started up Interface Builder. I think it's the first time I use it on the laptop, actually. I didn't make a thorough check, and I'm sure I missed some things. I just touched the main points I talked about in this post, and added a few Mac-oriented things. For those who don't know what Interface Builder is, it's a GUI editor for Carbon and Cocoa applications on the Mac. Okay, so first things first: Interface Builder ran Faster. By magnitudes. The reason behind it is simple, I think. Even though NetBeans (and IDEA) require a small amount of memory, the Java framework takes up its initial 100MB. Interface Builder doesn't have that, as it's a native application. Second thing I noticed is how much I missed floating panels. The Apple inspector was always a winning criteria for me with applications, and they've done it again here: The workspace is simple and the windows are small and "floating" - There is no "main window" where the form, toolbox and properties windows try to co-exist (or rather fight each other for space). Last thing I noticed was the simplicity of adding features to a control. For example, adding a formatter was as simple as dragging it from the toolbox onto the textbox you wanted to add it to. Some bad things, though: Even though snaps were there, you couldn't see the snap after placing it. I think it's a disadvantage, as seeing it on the form makes it clear what's going to happen after resizing. Also, snapping sizes is a bit weird and less straight forward than Matisse.. Even though I bet you get used to it pretty quickly. Another is the decoupling between the interface builder and XCode. Because of that, events can't be edited from Interface Builder, and some of the convenience you have is lost. Maybe I'm missing something though? I hope I answered your question... If you have any notes of your own, I'd be happy to hear them. I am interested in what a more complete check would raise!
Glenn
Avah: 1. Its generally considered that, arguably, Interface Builder is the best GUI builder out there, prior to Matisse, at least (if you disagree, no problem - not trying to start a flame war - substitute whatever is the best, in your view). My question was how does it compare to the best? You bring up a good point, however: the question actually has two parts: are their any functional things that Matisse is missing over IB et. al.? How does it feel to use IB vs. Matisse - does it feel "foreign/not Mac Like", pokey? Do Quaqua and Matisse play nice together? 2. Hummm. My point is that all the magic should be hidden unless you turn on the "reveal code" option. This should include, to my thinking, the constructor call. By header, you mean the method signature? If so, that's fair. It sounds like you're saying if you muck with the signature and mess it up, since Matisse "owns" the event handler's interface once it is referenced in the GUI builder, it will rewrite it if it gets mucked with. I think that's reasonable; slick in fact. It also sounds like this will introduce another level of inheritance over what Matisse currently implements. I submit that is ok, even preferred - encapsulate the magic in a super class, as opposed to, if I understand things correctly, the current approach of blending generated + user together it in a single class. Beyond event handler logic, do you NEED to reference/see the generated code? Can you write the complete application in Matisse, that is, double click on a widget, see its events, pick one and have that event handler pop up? (perhaps this is a Version 2.0 feature). The "show me all the events at once" view would still need to be available and synchronized - bring up the class itself. and thank YOU for sharing your thoughts!
Avah
Glenn, I can only guess that somehow you wrote your comment while I was writing mine, and so your comment actutally refers to my previous rather than the later comment. I will answer what's left unanswered, though: There really isn't a flame war coming. I didn't develop any Cocoa application, only toyed with it at the time when I realised XCode was coming free with the OS. About having anything in IB missing in Matisse, and about the Mac's "feel", I think I answered those in my comment, so I'll move on. Regarding to whether Matisse plays nicely on the Aqua theme, I can say that it does. Since Matisse is running over normal Swing, Apple's look and feel for Aqua takes place and it feels at home. The only thing I noticed differently was the "Save" dialog, not looking like a standard Aqua save dialog. I wonder if that's intentional though. By header I actually do mean the method signature. More than that - Even the closing curly bracket, ending the method, is read only. I haven't tried messing the signatures of event methods to see if they can be regenerated, but it's a nice idea. I will try that. Regarding the new level of inheritence, let me see if I folllow: Create a class inheriting from JFrame, place all event handling and component creation code (the auto-generated parts) there, and then inherit from it and leave the inherited class for the user to mess with? I suppose that could be done by the user - As you stated correctly, there usually isn't a need for the generated code except for event handling. Sometimes the components need accessing to in order to retrieve values, but these could also be encapsulated in a smart way in the paret-class. If you take a look at my X2J example application, I wrote That all in Matisse, except for the two button events which needed to be hand-implemented. Obviously, a bigger application would need a lot more of external logic, one that can easily be provided with Jars or even other packages. About "show me all the events at once", I suppose that could be accomplished by just viewing your code: The form's code is nothing but the generated code (closed in some #region style area), and the events. I do appreciate the comments. They stimulate the mind, sort of speak. :)
Glenn
Avah: 0. I haven't been playing with Matisse yet, so my questions are necessarily more general. 1. I gather that you don't find the mix of generated and non-generated code an issue. Theoretically, it seems somewhat messy to have the two co-existing in the same file, plus it would seem to add needless visual clutter. Said another way, if Matisse is separating out the layout and the logic, I submit that it should carry that through to its logical conclusion and have separate files - if developers don't have to futz with the code, they shouldn't have it in their face unless they ask for it (turn on the show-code option). This would partly address your original point about no XML storage of the layout. Sure its not XML, but at least its separated out, and as long as you don't see it, who cares what the format is, assuming you're sticking with Java. In fairness to Matisse, this would seem like a V2.0 polish thing. At least we have something now, for a change, that is functionally competitive with the leaders in this space. It would be slick to have the event handlers pop up from inside Matisse, as I was saying; more v2.0 polish. Interesting that IB doesn't do this - there's polish that IB is missing. 2. Interesting that you find floating windows easier to use than a split pane. Is it possible to "un-pin" them in Netbeans and make them standalone windows/drag them out of the frame? If not, hopefully this will be added, in general - its useful, for all windows. Netbeans 4.1 was starting to get into this - you could collapse pretty much all of the subwindows, and if you were running in full screen mode it was almost as good as floating. You may have even been able to drag them out of the window; memory fuzzy here, for some reason I didn't do that (window title bar too big?). Of course this assumes the windows themselves are small and well designed. Possibly more 2.0 polish there, too. 3. Your speed observation is interesting. Non phone Java, ignoring startup time and memory footprint, is claimed to be competitive with native code, roughly (particularily for non GUI), yet you aren't experiencing that. I wonder if its a memory footprint issue (not enough actual memory/swapping - Java crawls in that case), an optimization issue with Matisse (probably, to some degree; its early after all - we have to be fair), or if Java still isn't quite there yet, at least for gui performance, at least on the Mac. There was some talk that changing the garbage collection parameters helped with performance (stopped gc pauses, which was annoying in 4.1). I believe Apple still hasn't turned on hardware accelerated graphics in JDK 1.5/1.4 - that would probably make a big difference. I wonder how Matisse performs on Doze, where there is hardware accelerated graphics? Perhaps this is more experimentation than you care to do. 4. The cross IDE nature of Matisse is very slick. It sounds like we have a clear winner, at long last - one of the 3 big remaining Java issues, in my opinion, is finished (the other two being multiple apps in the same JVM, JSR 121 (underway, and its taking longer than expected), and orthogonal persistence (the Java object model drives persistence; JSR 20, stillborn)
Avah
Glenn, 1. You don't really see the generated code. It's hidden in a collapsed box you can double click in order to really see inside it. This is similar to dotNet's #region tags, if you are familiar with them, or with the way NetBeans, Eclipse and IntelliJ are collapsing code inside code blocks (between the curly brackets). That's why it doesn't bother me much: It's there, but I don't see it. 2. At work I have two screens for development. I find it highly comfortable to drag out all the frequently used windows such as project explorer and debug windows, so that they are still always open (as opposed to un-pinned) while still getting a full screen window for my code writing. That's why I like floating windows. :) 3. I don't understand "non phone java". However, I agree that your thoughts might be true. I made the IB test on my laptop, which is low on memory in general. A lot of swapping must have occured, which is likely the reason for IB running much smoother. However, it's also due to Java's framework taking up the amount of memory causing a lot of swapping, so it's not free from blame. Thanks again for commenting!
Glenn
1. Two screens - excellent point. I gather you're stuck on one monitor with Matisse/Netbeans - no dragging windows out of frames/no "make a new window on the other monitor and put these windows there" option. 2. By non phone Java I simply meant JSE and JEE (which, in fact, uses the JSE JVM). I should have been clearer. I am specifically excluding JME (my current project) and smaller; it appears those JVMs aren't up to snuff performance wise, although its hard to compare since there isn't that much native code on, for example, phones (plus JME uses a lot more of the native api, which further clouds the issue). On the other hand, there is a robust market in Java games (i.e. computationally aggressive applications) for the phone - go figure.
Avah
Glenn, We are indeed very proud of our two screens setup. I can tell you that it helped productability too - Having the document describing the client request and design to follow on one screen and the code on the other is more helpful than can be assumed.
Spreading the rumour - GroupLayout in Mustang at Chaotic Java
[...] I’ve said it before, there is no competition for Matisse in my opinion. But who knows? Maybe Jetbrains would add GUI refactoring.. // Used for showing and hiding user information in the comment form function ShowUtils() { document.getElementById("authorinfo").style.display = ""; document.getElementById("showinfo").style.display = "none"; document.getElementById("hideinfo").style.display = ""; } function HideUtils() { document.getElementById("authorinfo").style.display = "none"; document.getElementById("showinfo").style.display = ""; document.getElementById("hideinfo").style.display = "none"; } [...]
Mobility pack in NetBeans at Chaotic Java
[...] Read only code Just like in Matisse, the generated code - form traversal, event and sender decisions talked about before - Are read only, preventing the developer from accidently ruining some sensitive auto-generated code. [...]
NetBeans 5 is out at Chaotic Java
[...] It’s just that in the last month, I’ve come to gradually see the major difference the NetBeans team have made in the new NetBeans. Matisse, Mobility, Profiler, the new Editor (which still doesn’t conquer all fields but is certainly on its way) - They all show good work and good thought for user experience, something that was lacking in NetBeans and is lacking in many IDEs today. [...]
Avah
Zell: It sounds like you're trying to write code outside the scope of a class or interface. There are multiple forums and mailing lists available for beginners, and I suggest you go to them with your code example as they're very helpful. :)
Zell
I'm new to Netbeans and java - yes a beginner - and I'm trying to implement an applet source code into the IDE. I think I have finally done that bit but now a section (public void reset) of the code is giving the message that a 'Class or Interface is expected'. Help!