Visual Editor vs Manual code - java

I'm not sure how it is using other frameworks but this questions is strictly regarding Java swing.
Is it better to use a Visual Editor to place objects or to manually code the placement of the objects onto the frame (Layout managers or null layouts)?
From my experience I've had a lot of trouble using Visual editors when it comes to different screen resolutions or changing the window size. Using manual code to place objects I've found that my GUIs behave a lot better with regard to the screen size issue. However when I want to change a small part of my GUI it takes a lot more work compared to using a visual editor
Just wondering what people's thoughts were on this?

I never use a visual builder for my Swing UIs.
The ease to build a new UI generally becomes a pain point during software maintenance: some builders can't easily modify existing screens (in particular if they have been manually modified for some good reason); imposing a GUI builder to the people in charge of maintaining your software generally also means imposing their IDE as well, people may lack productivity if they have to use an IDE they are not used to or, worse, that they don't like.
Of course, manually building UIs comes at a cost: understanding the complexity of various LayoutManagers. However, there is a broad range of Swing LayoutManagers out there (mostly open source), some being both easy to use (and maintain) and powerful.
Two examples:
DesignGridLayout will work for
all forms-like windows and is not
only easy to use (less than 1h to
understand and use) but also enforces
good looking UIs and is the only one
(that I am aware of) where you can
"visualize" the shape of your UIs by
just reading the java code.
MigLayout is more powerful, but
a bit more complex to use and it
won't prevent you to design ugly UIs
;-)
One additional point: NEVER use absolute position/size in your UIs, this is looking for problems (your UIs may be truncated on some monitors/systems...)

You need to develop skill with both: one will always be faster than the other for some particular task. Having said that, without some manual skill, a designer will slow you down.

Personally i use layout managers over visual editors, the result is more readable, maintainable code. Also, you're not tied to any specific visual editor which may change (or stop being supported).

I personally have used over the years a lot of GUI designer - in Eclipse, NetBeans, IntelliJ. And I was never happy with the restrictions that they imposed and the code that they generated. In the end I had so much custom tweaks that using the designers hindered my work instead of assisting it. And then I found MigLayout - for me this piece of software is Godsend. It managed to take out the unneeded complexity out of my Swing labs and let me design superb layouts with minimum efforts. I don't think that MigLayout is harder to use(as someone above mentioned) - it's certainly to harder to use than CSS.
Even if you don't like MigLayout, my advice is to stay away from GUI designers. A simpler alternative of MigLayout is JGoodies Forms Layout(which MiG supercedes), jide-oss features some nice simple layouts as well. If you want to use a designer, however, my advice would be - IntelliJ IDEA Forms designer + JGoodies Forms - imo it generates much more maintainable code then say NetBeans Matisse.

Related

Custom Java Swing GUI vs. Netbeans Drag n' Drop Editor

Are there any advantages to hand-coding your Java Swing GUI rather than using the Netbeans Drag n Drop editor? Maybe such as run-time? It seems to me that the Editor auto-creates quite a bit of extra code but I don't know if that has much impact on the runtime of loading the views. The only reason I'm currently using the editor is because it makes the GUI building quick and simple. But are there things you can do only by hand-coding that isn't possible through the editor?
Also is there a better GUI Framework? I've peeked at Java FX, but I really want the kind of effect that the Github desktop software has. It looks so slick and clean, almost like a webapp. Although I'm sure they did that in C++. It just seems to me like there isn't much for Java when it comes to graphics. One of my friends commented that all Java programs look the same and so far it seems true.
I know there are similar posts, but quite frankly they aren't very recent, such as Write gui programatically, or using an advanced gui editor (Java Swing)? which was posted in 2010 or Learning Java Swing (GUI builder or not?) which was also in 2010. If there's nothing new, sorry to bother you.
Are there any advantages to hand-coding your Java Swing GUI rather than using the Netbeans Drag n Drop editor?
There are lots, but lets start with the obvious...
Doesn't lock you into a single development environment. This means your code is sharable to others who may not be using Netbeans. This is of particular importantance when you are using things like Maven based projects
Encourages you to learn the API. You get a good understanding of how the API actually works and learn plenty of tricks to make fluent and flexible interfaces.
Encourages greater separation of respobsibilty. It's all to easy to simply keep dragging components onto a form, which does nothing for encapsulation or management. By dividing your UI into areas of responsibility it makes it easier to mange the distinct states and relations between your components. It also makes the code generally easier to read, as you don't need to keep discarding content which is not relevant to what you are trying to figure out.
Better extendability. Extending components is not easy at the best of times, but is made next to near impossible with form based components (or at least an order of magnitude more difficult)
Netbeans form editor code is...a mess...
Don't get me wrong, I use the form editor, but I've been hand coding Swing GUI's for ten years before I picked up the form editor. I like the form editor for laying out final screens and tend to use hand coded UIs for every step up to that point, putting the pegs in the hole so to speak.
The short answer is - until you can make a multi-level GUI by hand, stay away from the form designers - IMHO.
I know some people think they make great learning tools, I think the opposite, I think they allow you to develope lazy and bad habits which will affect everything you do into the future.
While the development enviroment shouldn't make a difference, not everyone will want to use Netbeans, best to learn to do without
Also is there a better GUI Framework?
That's rather a matter of opinion. Swing brings a concept of skinning through the use of the look and feel architecture, which provides you with the ability to change the way that components look and feel.
JavaFX provides similar functionality through the use of CSS
Swing is also highly customisable, it's very easy to get into the "paint" level of the components and even generate your own should you want to.
The ability to make a "slick" UI isn't about the toolkit but down to the developer. It's easy to just drop fields and other components onto a container, but it will take a developer with a good understanding of the underlying API and some talent for what actually looks good to make it look "slick".
Pretty doesn't always equal functional. The best UI's are ones you don't have to think about, that don't get in your way and just work. When you've been working with a program for hours, days, weeks, you're not going to be looking at how pretty the UI looks but how well it lets you get what you want done - IMHO
The #1 thing that hand-coding accomplishes that the GUI Builder cannot is: dynamically changing interfaces.
For example:
If you wanted to build a form that involves several JTextFields, but you aren't sure how many there will be when you build your GUI. The program will need to populate the JTextFields dynamically. This is impossible with a GUI Builder.
Also, when you have complex interfaces, the resizing behavior of GroupLayout can be cumbersome and confusing. On the flip side, hand-coded layouts are a lot of work when you are writing a complex interface (but, at least their resize behavior is predictable).
A classic GUI builder should be used for prototyping your GUI. Once you know exactly what you want, you should get rid of it and clean the code (factorize it, document it, ... in short make it simple & readable).
One of my friends commented that all Java programs look the same and so far it seems true.
Not absolutely true: JavaFX look is customizable through css. Swing is also fully customizable through the LAF system or by overriding the paint* methods (more time-consuming I admit).
If you look for something easy without the drawbacks of generated code I recommend you have a look at ReflectionUI: easy appearance customization (and that's not the only benefit):.

How to learn Java Swing and make GUIs quickly?

I've been coding in Java for the past year, and i think I have solid OO and
basic OOD skills. I'm looking to build a Java GUI on-top of an existing project which is not complex, but I want to finish it as quick as possible. So I'm looking for an API that would abstract all the nitty gritty implementations and let me focus on the core of my minimal viable product.
I really prefer coding with eclipse and not wasting time trying to learn to get used to another IDE. What would you suggest I do?
Here is the crash course in swing.
First thing to learn is the layout managers.This is the big hurdle, they are finicky things and you have to master them.
Second is listeners,without them nothing happens.
Third is the JComponents themselves,you will slowly learn them as you go along. I would recommend using NetBeans GUI builder to play with them and get a feel for them.
Note that most JComponents have different models you can use rather then the default.
Also the only difference between JPanels and JComponents that I can find is that JPanels have layout managers.
A good place for various swing hacks and tutorials is here:
http://www.java2s.com/Tutorial/Java/0240__Swing/Catalog0240__Swing.htm
http://www.java2s.com/Code/Java/Swing-Components/CatalogSwing-Components.htm
Well, actually the GUI Builder in Netbeans is your best bet to make a GUI really fast. You can do it in a matter of minutes if you have the picture in your head about how it's supposed to look like. After that, the only thing left to do is to bind it to your application; more specifically: make the ActionListeners of your buttons for example do whatever they should.
This of course depends on the application's size. If it's small, then making a GUI for it is easy. If, on the other hand, it has 2000 classes, then it can be more complicated, since the GUI will probably be more complicated.
If the application can be modelled as a Model-View-Controller architecture, that would help you a lot.
I think you'll find out that there is no royal way to GUI in Java. Every approach is a pain in the (*). Even if you use a visual GUI builder, it will STILL be a pain in the (*). As a long-term investment in your skills, I recommend you to bite the bullet and learn to build the GUI programmatically. That's what every experienced Swing dev does anyway, so better head for that goal straight away. You could also start with SWT/JFace, but that APi is more difficult and quirky than Swing. RCP adds yet another layer of quirkiness and complexity over SWT/JFace, so I'd stay away from that while still a beginner, and in fact at all times except if making a massive GUI application.
Sounds to me that eclipse RCP could be your friend (if you're looking at a rich client solution). Just grap a distribution of eclipse for plugin development (much faster than installing the plugins to your existing copy), create one of the sample projects and start hacking.
For web applications, I'd recommend the playframework. It integrates quite well with eclipse.

What is the preferred visual editor Eclipse plugin for Swing apps in 2011?

I know this question has been asked before, but those answers are over 2 years old in many cases.
I've heard that the Eclipse Visual Editor project has been dormant for a while, the VisualSwing4Eclipse update site doesn't appear to contain anything (perhaps it doesn't support Helios?). There is also Jigloo, but its website looks rather amateurish and does not inspire confidence.
My preference is either a free tool, or free for non-commercial use.
NetBeans Matisse. Since you ask about Eclise - on a GUI project that I was working on, we were using NetBeans to just 'draw' the UI, and then switched to eclipse to write the code.
Google has recently given Windowbuilder pro to Eclipse.
It's free and you can build swing, SWT and GWT screens.
It's not totally mature but really worth trying.
http://code.google.com/javadevtools/download-wbpro.html
In general, I would advise against using a UI designer for Swing, because most often the generated code is just unreadable, hence unmaintainable.
In addition, some designers enforce your whole team to use one IDE, not necessarily their favourite one, hence potentially reudcing their productivity.
For UI design with Swing, I much prefer using LayoutManager that makes it easy to code your UI directly (I don't talk about GridBagLayout of course), such as:
DesignGridLayout
MigLayout
there are probably others...
You may want to take a look at this link, where several LayoutManagers are compared, although it is a bit old, it is still worthy of interest. There, you have a broad view of existing Swing LayoutManagers and you can see the code needed, with each, to produce the same UI.

What to use for writing a user interface?

I've written a series of classes to interperet data from a serial port. This data needs to be displayed on the screen. I am trying to go for straight up eye candy with a refined look.
Swing UI- Easy to program, yields mediocre results
Open GL- Hard to program, yields good results.
Are there any other options?
Give SWT a go, the API is a lot simpler than Swing. Here is a recent question outlining the differences between SWT and Swing.
I'm not aware of any alternatives, but in my opinion it is possible to write beautiful GUI with Swing. Just changing the ugly default look and feel goes a long way. Visual appeal just doesn't seem to be a top priority for most Java coders and therefore you have to make an effort to make anything pretty.
JavaFX maybe? Didn't tried it yet, it obviously offers some eye candy.
You can use NetBeans combined with JOGL (Java bindings for OpenGL) or simply with Java2D.
NetBeans has an easy GUI Builder for Swing applications -- you can make beautiful interfaces (if you get into it), easily change the Look&Feel, etc etc.., and you can use Java2D or JOGL for visualizing your data and embed it in the GUI to display it.
There's a plugin for JOGL for NetBeans so getting started is hassle free.
use html, css, javascript. Much easier to get wizz-bang UI than using Swing or related technologies.
For my projects at work, we have purchased a licence of JFormDesigner.
This is really a great tool that saved us a lot of time.
Writing Swing application by hand can be a real pain and is awful to maintain.
This tool choose the right approach : The model-view-controller.
The GUI builder creates XML files for you that represent the interface. These XML files are loaded at runtime and transformed into Swing objects. The builder also generates Java stubs that you can fill with event handlers.
It also handles Localization and nice layout goodies.
Give it a try.

Matisse or Jigloo?

We have a dilemma; developing desktop application using Matisse or Jigloo..
Matisse has this XML form files which we are afraid of maintaining later, we don't even know should MyEclipse further support Matisse, even Netbeans - do you think they will give up OS support of Matisse?
More or less Jigloo and Matisse have similar behaviour, although Jigloo obeys more designers wish, Matisse has this strange alignment behaviour from time to time.
Jigloo generates Java code which can be edited and which in turn can cause visual editor not being able to draw form. That is probably the reason why Matisse wants to have definition of elements in more stable XML form from which it generates java code.
Matisse would not help much if there is an error in instantiating a GUI element, so putting custom elements can be also nightmare.
When typing code in Jigloo, the visual editor likes to erase picture so you have to wait for picture to show up after editing code. In Matisse you can have errors in class and still editing GUI.
Please help us by voting, what do you prefer more and why.
Please don't use either! As with this answer, it's my strong opinion (after writing Swing GUIs for 10 years), that using GUI builders is, in all but the most edge-cases, a bad idea. HAND CODE YOUR GUI!
Whether you choose Matisse or Jigloo, it is not a standard, will fall out of favour and a better tool will come along. At that point, you will have legacy code that is nigh on impossible to maintain. This has already happened several times in the history of Java GUI builders.
You should avoid forcing your developers to use one IDE and it is a huge overhead to expect devs to switch to a particular IDE when looking at the GUI code. They'll be frustrated as they can't remember key bindings, project setup is out-of-date, they have the wrong version installed etc. People will make quick-fixes without the builder. At this point your code is unmaintainable in both your IDE of choice, and in the GUI builder istelf! The whole thing is a mess.
Designing a GUI is not, in my experience, a particularly onerous task and probably accounts for no more than 5-10% of the total development time of an application. Even if initially using Matisse or Jigloo provides you with a 50% time advantage over hand-coding the GUI, this is insignificant in the grand scheme of things. It is certainly not worth the hidden costs and impending maintenance disasters that lie ahead.
GridBagLayout is not hard. It just isn't! It's really simple, in fact. It will take you a few minutes to learn and after that you'll never look back. Your GUIs will look like how you want them to look and your code will be more maintainable as a result. Use GridBagLayout!
I have spent a good deal of time warning people about this before and been proven correct.
I have personally had a handful of occasions where the XML file backing a Matisse form somehow became out of sync with the code and had to resort to a backup to get it working again. This was enough to scare me away. I have no experience with Jigloo, though.
My current projects use TableLayout, extensively. It is easy to understand and (of all the layout managers I've tried) maintain. I have not found any other solution in GUI design for Java that I feel more comfortable with than coding the GUIs by hand. Moving forward, it seems like the best "future-proof" way of coding my GUIs.
I agree with Chintan on using Matisse or similar to mock up your design and then convert the layout to another layout (like TableLayout). Personally, I like using pencil and paper to do most of it. Not exactly high-tech, but it gets the job done.
I wouldn't go with either. The best thing I've found so far is Instantiations Swing Designer. It is not free, but not expensive either. It supports all major Swing layouts and DOES NOT create any additional artifacts except pure Java code.
Here is the link, if your are interested.
I would prefer Matisse since Netbeans is backed by Sun Microsystems and the possibility of the project being scrapped in the near futures seems blissfully low.
Also, I do not know the size of your project but I have developed some small ones and I personally use matisse to see how the layout would look and then go ahead and code everything using the Miglayout library. It increases the amount of coding a lot but gives good control and flexibility. And there is a possibility this library might be included in Java 7, consequently embedded into Matisse.
I prefer Netbeans Matise. Even if it is impossible to edit generated code, it's much more easier to design complex screens with Mattise(because of FreeForm layout).
I haven't tried Jigloo, but I would throw a fourth one in the mix.
JFormDesigner is the best Swing UI designer that I have ever used.
Like Matisse, it does create XML form files, but that is the only negative about this tool.
It supports all standard layout managers, plus some popular ones (such as JGoodies FormLayout). It has plugins for IntelliJ and eclipse and can also run as a standalone tool.
Here is the link
hth
Koen
What you can expect when you mess a file generated by a tool? Mess, isn't it?
This is a very very important always forgotten by developers.
Take Matisse as an example. It generates a XML file for you and a .java file for you.
Why on Earth developers start changing these classes?
Later they complain that everything is messed and they point out to Matisse as the guilt of it, because Matisse doesn't do A or doesn't do B. The only thing Matisse is guilty is not being able to fix the mess promoted by developers. This is problem in the domain of Artificial Inteligence and I personally do not expect any solution soon.
There's a more or less simple solution for it: OOP.
I explain: one of the most important concepts of OOP is 'responsibility', which means that a certain class has a limited and well defined responsibility in a broader and more complex problem domain.
So, Matisse generated the UI for you, which basically consists on UI elements, event handlers, etc.
Then you say: well... I need to add some logic to it otherwise the UI is innoperative. True. This is another responsibility, which cannot never be implemented in the same class generated by Matisse. Because either people is lazy or do not understand what 'responsibility' means in OOP, people implement whateber they need, add lots of variables and promote all sort of madness in a class which is definitely not responsible for business logic.
By a very simple thing like inheritance you can separate business logic in a extended class. The base class is the one produced by Matisse. The extended one is your class implemented by hand which contain implementation of event handlers, initialization of UI elements, etc.
Many developers are tempted to edit by hand the .java file produced by Matisse.
The golden rule is: never, never edit the .java file by hand. Matisse provides you means of defining whatever you need and call whatever you need. Never editing resources (both .xml and .java) produced by Matisse, you guarantee that it (Matisse) will be able to load it again in case you need to change the GUI in future. Probably you will find yourself tempted to edit the .java or even the .xml file directly. Please resist this temptation and educate yourself; you will thank yourself in future.
So... you can use whatever tool you wish or whatever provides the sexiest UI elements.
All tools will fail if you fail to separate UI from business logic.
All tools will succeed if you succeed in your main task as programmer which is: produce decent code.
Use WindowBuilder and be happy.
https://projects.eclipse.org/projects/tools.windowbuilder
Eclipse WindowBuilder is composed of Eclipse SWT Designer and Eclipse Swing Designer and makes it very easy to create Java GUI applications without spending a lot of time writing code. Use the WYSIWYG visual designer and layout tools to create simple forms to complex windows; the Java code will be generated for you. Easily add controls using drag-and-drop, add event handlers to your controls, change various properties of controls using a property editor, internationalize your app and much more.
Generated code doesn't require any additional custom libraries to compile and run: all of the generated code can be used without having WindowBuilder installed. WindowBuilder can read and write almost any format and reverse-engineer most hand-written Java GUI code. It also supports free-form code editing (make changes anywhere, not just in special areas) and most user refactorings (you can move, rename and subdivide methods without a problem).

Categories