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).
Related
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):.
They have this very cool drag and drop thing that creates GUI on the fly. But I don't get to learn anything out from this method and I feel guilty about it. Do most of the Java programmers use this method? Because realizing the code it generates, it's quite impractical coding the GUI by hand IMO.
There's nothing wrong with using a GUI builder, as long as you understand what the tool is doing and the implications of using the tool of choice.
The first thing you need to know is what the tool is doing. In this case, you should understand Java Swing and topics such as layout managers, components, concurrency issues that arise when using Swing (this will be handy even when using a tool), event listeners and handlers. Really, you should be able to walk through a simple tutorial, such as this one on Creating a GUI with JFC/Swing. You don't need to be an expert, but you do need to be at least comfortable with reading the generated code and understanding what it does.
The second thing you need to be aware of is the implications of using whatever GUI building tool that you are using. A big implication is that if someone goes to edit the GUI code, they will have to either use your tool or edit the code by hand. If you work in an environment where people are using multiple IDEs and code editors, then someone who uses a different tool then you won't be able to work with your generated code without breaking your ability to use the tool. Most generators lay out their code in a specific manner so that it can be read and processed by the tool - different GUI builders generate different code and won't be able to easily work with each other's code. Also, because of this, editing the code by hand might break the ability of a GUI builder to work with the generated code.
If you understand the tool, what it does, and are willing to accept the risks, go for it. I'm a firm believer in using whatever tools are appropriate to get the job done and that includes GUI builders.
Coding Swing by hand isn't bad at all once you get a grip on layout managers, so it all depends on whether you want to learn Swing. Knowing Swing is far from necessary but it is a pretty well designed bit of code.
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.
I am planning to write a Swing-based application (using Netbeans 6.8).
It seems that Netbeans has a very advanced GUI Editor... Still I have my doubts regarding the code generated by it. Additionally I don't like the fact the part of the code is locked (still I understand the need).
Has anybody used Netbeans GUI Editor with success ?
Does it "scale" ?
Yes, the NetBeans GUI builder is one of the finest around. I was particularly impressed with how well it handles the infamous GridBagLayout.
Borland JBuilder was in my experience the very best round-trip GUI editor; if I remember correctly, it produced code without "locked areas" and would usually continue to work gracefully with GUI code that you had manually tweaked.
Still, I have yet to find a Java Swing GUI editor that doesn't occasionally choke on a complex layout, i.e. enter a state where further editing is no longer feasible and/or requires some backing up or fixing.
Thus, I prefer to hand-code all my GUIs. Heinz Kabutz of JavaSpecialists tells me his GUI editor is vim. However, I admit that most of my other friends and colleagues consider me crazy for doing this.
With the newest versions of Netbeans, you can share projects between Eclipse and Netbeans. So, if you don't like coding in it much, you can use it just for the GUI features and then edit the code in Eclipse. Make sure you create your project in Eclipse first, and then use the importer. They will share the same directory.
http://netbeans.org/kb/docs/java/import-eclipse.html
I have always prefered to write my Swing UIs by hand. I've tried Netbeans but I just didn't trust it to do the right thing for a complex UI (although it was quite awesome for a small simple UI).
I think a lot of us fear writing Swing Layouts by hand because of GridBagLayout. Its not that hard once you've used it a few times. I used to swear by it. However, recently I've moved to a new job and their existing code uses TableLayout instead. Its much simpler and seems just as powerful to me. I've grown to prefer it to GBL. I think you should consider it if you're new to writing Swing.
I'm sorry but I'm not sure about your question of scale.
Best of luck!
Funny side story about JBuilder. My friend who taught me swing taught me to code it by hand, and he always had me put the layout code in a jbinit() method. For several weeks I assumed this was just some code style he used. It was only later I learned that it was an auto-generated method of JBuilder at the time. I didn't need to be using it at all. I was such a n00b :)
I recently (4 weeks ago) switched from eclipse/SWT to Netbeans 6.8/Swing (after being fed up with some plugin licensing issues in Eclipse). I came in cold not being familiar with either Netbeans or Swing and was quickly impressed. I managed to convert 4 years of SWT experience into Swing experience very quickly and now consider Netbeans the best Java GUI editor. Whilst some parts of autogenerated code are read only - this is a good thing. Eclipse allows you to edit the autogenerated code and this can cause major headaches with layouts, alignment and so on if you make a mistake. Netbeans allows you can create custom 'event handling methods' (my terminology only) which gets the autogenerated block to invoke your methodd at particular points in the lifecycle so you can access the 'read only' code whenever you need to.
So stick with NetBeans, its the best Java Swing environment there is.
You do NOT want to code by hand, for any reasonably sized app. Let the GUI do most of the plumbing for you (especially when using the the different layouts - this alone will make you tear your hair out), so you can focus on the service/business logic.
I've used netbeans, WindowsBuilder plugin in eclipse, and resorted to just writing Swing code by hand. I definitely appreciate the fact that netbeans and windows builder write the swing code for you, but I like knowing every inch of the code in my project and know where to go when I want more complex and add details. Having said that I think netbeans is worth a try too but I was a bit nervous of going through the generated java code, whereas if I had written them from scratch, I don't have this worry.
WindowsBuilder plugin for eclipse totally screwed up my eclipse, the content assist became permanently slow, even after removing it. While the Swing Data Binding framework has some learning curve (at least for me because I didn't know it was the same as JFace Data Binding Framework), I had trouble finding documentation for it, and was referred to the JFace wiki....
Overall, you are right, I think you do get to think more about your application logic than writing plumbing code spent on the gui, but if you write them yourself it just gets faster and faster. I also don't like the fact that I need to be dependent on a gui editor to create my application.
I've been told that creating GUI's using drag and drop generates unnecesary code and is frowned upon by most Java developers.
I'm used to dragging and dropping things using Windows Forms **but ** I'm also very comfortable creating things using XAML for WPF applications.
I'm a bit lost however on how to create a basic GUI in Java using only code.
What I'm using: Netbeans 6.8
What I want to do: Create a simple Window that will act as the main one
that opens up when the application
launches.
How can I create a simple Window with the standard window buttons (close, minimize, maximize) and have a little button on the middle of it. Using only code.
Also, what type of project do I create using NetBeans?
Thanks for the help.
I feel like this kind of question is best answered with a link to a tutorial, so here you go:
From java.sun.com, Trail: Creating a GUI With JFC/Swing
The link provided by danben is really helpful. If you really want to lay out everything from scratch, then you have to be able to answer such questions as
What is container? Which components are containers?
How components are positisioned within a container (layout manager)?
The link provided will give you the answer.
I heard that one before. I don't know what is with java developers and always insisting that you have to write the gui by code and can't use drag and drop tools. For me I don't care if it generates unnecessary code. I personally don't think it will make that much of a difference.
The only thing I would never recommend is using a designer for websites since they usually never look the way you designed it when you actually test it on a browser but for windows GUI just use a designer.
I look at it this way. There might be a bit more of unnecessary code but your bosses won't care about that. They will be more concerned why your taking so much longer on something and costing the company so much more money on little to no effect to the final product.
To answer your question you probably can pick up any book from java and they will have tutorials on how to make GUI's by code.
To do it programatically, you have to be able to understand code in general. As far as I know Java does not have a simple XML based layout language for GUI-s. So first you have to learn how to program. (But you can try JavaFX's script language, might be easier to master first.) You can easily learn your way in the simple cases from the generated code, then continue using swing javadoc and google.
GUI builders are handful, nevertheless. It is a plausible that once you are required to mock up a GUI layout as a prototype, tracer bullet, presentation material etc. Generated code might be even completely irrelevant.