This question already has answers here:
Why is it frowned upon to use a null layout in Swing?
(4 answers)
Closed 8 years ago.
Bonjour.
Upon spending countless hours around this site looking for code to drag a component around the screen, I noticed an odd trend growing in the answers.
...being that everyone shudders at the sound of the null layout.
So I ask, what's the problem everyone has with it? I've been coding for no more than three months, using Swing for no more than one, and the layout has been a breeze to use with endless customisation possible. Why is it bad practice?
The major problem is the complexities involved in trying to make determination about individual platforms with regards to things like fonts and how pixels may be rendered
Even two systems, running the same OS can generate different output due to different hardware drivers and rendering pipelines.
Much of the API has been abstracted in such away that you should never care that one PC is using a DPI of 120 and using DirectX and another is using a DPI of 92 and using OpenGL.
Layout managers remove the developer from the responsibility of having to calculate the size a component (and its child components) at a particular moment in time as well as calculating the relationship between these components and does it in a standardised way.
The core Swing API has been designed to utilise this API, so when a component changes in some way that would represent a change in the size, all the required containers are notified automatically and the entire hierarchy of components can be adjusted as required.
The basic idea of a layout manager is to describe the relation between components on the same container as well as providing information about how much that container might like to have. This allows you to focus on the user-ability follow of the UI rather then trying to spend time trying to update the UI to meet all various possible combinations of hardware and software.
As a former VB developer (no, I'm not proud if it), I can assure you, the most frustrating part of working with it was trying to develop usable, dynamic UIs that didn't look crap on the next clients machine.
Of all the aspects of Swing, the layout management is one of the most welcomed - IMHO
Because it's not a layout. All you are doing is using a GUI editor to place your components in absolute locations. And resizing your window or running your code under a different monitor resolution will look terrible.
looking for code to drag a component around the screen
That is a different requirement. By definition when you drag a component around the screen you can't program the location.
Having said that a layout manager does more then just set the location of a component. Check out Drag Layout for a layout that you can still use in this situation.
For other situations a layout manager (or combination of nested layout managers) if the better solution for designing effective GUI's.
You will loose some points for GUI for using it, because it's hard to maintain, more code, less flexible,... Adding an extra button will lead to a lot of recalculation you have to do.
How i see it : http://leepoint.net/notes-java/GUI/layouts/nulllayout.html
Related
I was reading through the java docs and found that it is easy to make a shaped windows, making them translucent and coloured as long as the platform is supporting such feature, but I couldn't find anything about making them glossy.
Is it possible in either awt or just swing to give frame or a panel a metallic look?
I know this might be a horrible idea from cross platform point of view, but I wanted to know if it's possible somehow without resorting to some third party libraries?
I have found a button gloss example here:
http://www.andygibson.net/blog/tutorial/glass-button-tutorial-in-java/
But it is not exactly a metallic look and if I replicate the method to use rectangles instead of circles it may scale poorly.
I've been looking at JavaFX but it seems to be a massive multipurpose package - an overkill if I just want one eyecandy.
note - if you give a minus, be so kind to explain why - else its just being a jerk. I see nothing wrong with this post and I did indicate what I looked at. From what I see I've fulfilled all formal requirements and this is not a subjective type of question.
What your requesting can only be handled by calling the Windows native API. You'd have to cooperate with the Windows DWM (Desktop Windows Manager) facility. Typically it's handled by calling the DwmExtendFrameIntoClientArea function.
Long time ago, I tried to mimic the glass (AKA Aero/Frost) effect using Swing. It was partially possible. One can easily write drawing code which handles this (and surprisingly even quite performant), providing that the drawing happens on the Java side.
That was possible with Swing (see Glass effect for internal panes) and should be even simpler with JavaFX.
However, to handle your precise request - the windows borders - one has to use the native WinApi. From my little research, I only found that SWT does this in limited way (but doesn't expose as publically accessible methods).
I tried to call the Windows Shell API through the JNA project. I successfully managed to change the glass area, but the effect was unpleasant: the Swing wasn't really well prepared (~JDK 7u5) to handle partially transparent JFrames. I remember, that the JFrame code, during a repaint, was clearing the Window using some color. I had to forcefully change it to other one (which matched the one I specified by calling the Windows API), but ended up in a visual mess.
I tried to debug it and I found that certain versions of Java have different code to clear the JFrame's content. So, even if I managed to correctly set the wanted color, it could easily break with the JDK update.
I am in the process of porting some graphics rendering from java/Android to standard java.
The first thing that I am faced with is - which graphics api to use, Graphics2D or JavaFX.
It was proposed by assylias in my previous question "Porting graphics drawing from android to standard java", that I use JavaFX.
I have seen that this has the advantage of taking doubles and floats as parameters for drawing, as with Android.
However, I have not been able to find anything which confirms that the drawing is antialiased, or that antialiasing can be turned on.
My objective is to generate a high quality image which will be directly saved to disk and not displayed in the application. It will be displayed in another context and not printed.
I need to be drawing text, paths, beziers, lines, ellipses and rectangles.
Is it worth my while digging into JavaFX or do I have no choice but to go with Graphics2D ?
Many (if not all) of the objects that are drawn in JavaFX applications already have antialiasing effect. This is visible to the naked eye. Try to write two identical applications, one in JavaFX, and another in Swing (without antialiasing effect of Graphics and RenderingHints object). The difference is clear, especially when drawing geometric shapes and text. Here you can find some comparisons between Swing and JavaFX, and here you can get to know better the JavaFX 2.X (read the subject "Graphics System" and "Media and Images").
Personally, I would prefer to use JavaFX technology. I previously used a lot Swing. Each of my applications had to be made in Swing. However, after seeing the practicality of JavaFX, its maintainability, its elegance and productivity, I did not think twice. Even if you just want to draw simple things, JavaFX seems to have a much better performance. If I'm not mistaken, JavaFX was developed taking into account the use of video hardware on your platform, and was also inspired by the famous game engines available for Java users, which are made to work with high processing visual effect, screen updates, and among many other things.
For you marvel a bit with the technology and effort that was put, I beg you, visit this address. Look for the download of a JavaFX program named Ensemble. You will find where is written "JDK 7 and JavaFX Demos and Samples". click download and use the demo program Ensemble.
For information on drawing text, geometric shapes and stuff, see the following links:
http://java.dzone.com/articles/javafx-21-beta-improved-font
http://fxexperience.com/2012/01/lcd-text-support-in-javafx-2-1-developer-preview/ (An alternative from the previous link)
http://docs.oracle.com/javafx/2/text/jfxpub-text.htm (Look for "Setting LCD Text Support" and also, with the feature of applying effects to text and various things of JavaFX, you can still improve the visualization of what is shown to the user.)
http://docs.oracle.com/javafx/2/api/javafx/scene/shape/Shape.html#smoothProperty (The "shapes part")
Would you like an opinion of a colleague? Adopt JavaFX in its version 2.X or higher (do not use the JavaFX 1.X). Over time this type of technology will mature. Much still come ahead. The next update of JavaFX, we will have many nice features. And notice that JavaFX is still in its version 2.X. Probably in the near future Swing library will be left out, as happened with the AWT. You better start now studying JavaFX, rather than only in the future you go familiarizing yourself. The market is there.
If you still have some questions, please come back and ask. We'll be here. :)
Good luck.
I wanted to have a discussion on Java GUIs, right now, I'm still in school and I've done light gui development for class.(We briefly covered it.)
Plain and simple, I couldn't do anything I want, I wanted to build a nice clean layout but everything looked off and worse when you maximize it. JButton were huge when put inside a GridLayout, or they spanned the whole row, when I clearly specified the size of the button and etc. It's been one headache after another with Java gui development.
With Microsoft WPF/XAML UI development is more straightforward, it felt like HTML/CSS. Setting the width, height, margin, and padding is great, knowing where my components are going to be puts the mind at ease. And you can even design a custom Look and Feel.
I wanted to know if do you guys have any tips and resources for someone starting Java GUI development. And the one thing I don't get is launch new items with a JFrame, i.e a game.
At Launch your directed to a panel with 4 buttons.
Play Game - Takes you to a new panel to play the game.
Lobby - Takes you to a chat like interface
and etc
Should these be panels? Or more JFrames, like when a user click a button I launch the Play Game JFrame then close the menu JFrame. I really have no ideas with Java guis.
Make sure you understand and are using the appropriate layout managers. This Swing tutorial is very useful for learning how each works: http://download.oracle.com/javase/tutorial/uiswing/layout/visual.html
Also realize that you can layer layouts by putting on panel inside another. This is sometimes necessary to achieve a desired effect while keeping things simple.
For your last question, buttons can just be added to a panel that can bee adding to additional panels before a frame.
First off take a look at Mig Layout. This is a real full featured layout manager and currently is the best one available. If for some reason you can't use external dependencies then you will want to look at GridBagLayout. GridBagLayout will be powerful enough to do everything you need, but it is not as easy to use as something like Mig Layout.
In 99% of the applications you will build you will have a single JFrame and just transition the JPanels to show the different screens.
First off, one of my rules of thumb when building UI panels is to never set directly any location or size.
Then, a second rule is to never set any preferred, minimum or maximum size directly in pixels (thus will bite you when you change from one monitor to another one, with higher or lower DPI resolution). Take a look at this post on my blog, quite old but still useful today.
Thirdly, I try to avoid embedding panels into panels because it leads to components alignment problems and inconsistent component sizes.
Finally, I try to use DesignGridLayout for most of my forms, and sometimes revert to GridBagLayout if the UI layout is too complex (but a complex UI layout may also be a sign of poor UI design).
As a general comment about how to build UI applications (with any UI toolkit in general, but with Swing in particular), there are several recommendations that exist out there, but it is hard to find concrete implementations, you have to read a lot about these, and then try to find the way that works best for you.
Yes, welcome. Compared to HTML /Javascript/CSS you can get nothing like the sophistication and polish for the equivalent level of time spent learning.
(I haven't sourced all the files for you for anything here - google and start looking up).
Swing, in my experience definitely feels like I read 10 million documents, played with some demos, and spend three or four months nightly for 2-3 hours, and you have some idea of how some of the api's work, and then have no idea why some don't. Its great. You want something to work and then implement that, and proceed to f*ck up the rest of your gui.
Java swing, in my opinion, is desperately crying for an open source JQuery type plugin library that will animate your JComponents and render them in a way that you like. Its a definite second class citizen on the desktop, and especially now that CSS / HTML browser rendering sophistication has improved over the last few years.
The nimbus look and feel style is an improvement definitely in the right direction.
You could also move over to JavaFx. Good luck. Apparently its quite nice. I haven't yet had the time or patience.
If you are allowed to use thirdparty library : try JAXX as an option. The idea was to create a css type implementation, where styling elements are separated into a file that can be quickly configured and tested.
Read here for good introduction: today.java.net/pub/a/today/2006/03/30/introducing-jaxx.html
JavaCSS is found in the JAXX project. JAXX is a xml format style implementation of the swing gui interface. You write an xml document, and a css style document, and are able to bind the inputs and outputs of the GUI to your java implementation engine. The css style document allows for rapid sophisticated gui development. Using the jaxx jar engine, the xml code is converted into java code that runs as rapidly as if deployed in a .java class file.
The project has been continued by a French group of programmers and is now to be found here: http://www.nuiton.org/projects/jaxx/files
The demo is at least pretty and most things seem to work.
The latest release is JAXX 2.4.2. The latest update was May or June 2011. Whilst in French, the documentation is still comprehensible in English. Just translate.
The original ethan nicholas files of jaxx were last updated on 17-07-2009
http://sourceforge.net/projects/jaxx/
Please note: www.jaxxframework.org/wiki/Main_Page is a dead link, the site is discontinued. instead a mirror has been made and can be found at: buix.labs.libre-entreprise.org/original-jaxx/www.jaxxframework.org/wiki/Main_Page.html
This documentation is essential to understand the meaning and purpose of jaxx and its use.
If you are patient, have lots of time, and are interested, also look at the timing framework by Chet Haase, to animate your components, it is possible to create sophisticated effects. It requires learning curve and time.
Or pay to get your gui components handled by a professional third party library? (Um, the obvious answer, no-one who has spent the time and effort to learn to create a pretty gui is just gonna hand that over).
So spend three years learning and then ask for moola from others?
Another idea - I am very into exploring but it looks like it might be a nightmare to implement, despite everyone saying its so easy, get an open source webbrowser html / csss renderer embedded, and design your gui on that, using CSS / JQuery / HTML.
But it looks like you have to first compile the web browser (mozilla) from source, and then wrap that in another program (e.g. JRex) and then put the whole thing in a mini- client server like Jetty, just to have a front end implementation that you halfway like.
And that is only if the browser is actually is as compliant with the CSS2 standard and HTML4. Forget about HTML5. That is for the future.
Okay, I am grumpy today, but I don't think the gripes are completely unjustified.
I've seen other answers and hacks around to this question, but none seem to do exactly what I'm after.
Essentially, I'm after a JWindow whose background is translucent but the content of the window itself (buttons, text and so on) are opaque. The methods I've seen so far fall into one of two categories:
Taking screenshots from behind the window and using them (http://onjava.com/pub/a/onjava/excerpt/swinghks_hack41/index.html) - this isn't much good in this scenario since it's too slow, I want to be able to put things like video behind the window and have it show through
Making the whole window translucent (including the components on it which I need to remain opaque.)
Is what I'm asking for possible, and if so how would it be done? If not, will Java 7 provide any methods that would make this easier / possible? I know it's got more support built in for shaped windows so I wonder whether something there could take care of this also. I've been searching around for a while now but with no luck.
Can only be done if you are using JDK 6 update 10 and above. Must also support hardware acceleration. See
http://download.oracle.com/javase/tutorial/uiswing/misc/trans_shaped_windows.html
I have a Windows Mobile application written in Java that uses AWT for the user interface. I am looking at porting the UI to SWT. I got a hold of the SWT libraries for windows mobile and I started looking at what work will be involved in actually porting it over. I think the first thing I have to decide is how to handle a large number of screens in the application.
In AWT the UI is basically a single java.awt.Frame with CardLayout. Each screen is then just an extension of java.awt.Panel, and is added to the Frame. Then whenever we need to change to a different screen we just set that panel to the top-most.
SWT doesn't have such a layout manager (and I'm not even sure if that is the best/most efficient way of doing it anyway, since the system resources associated with every screen in the application are always held). One way I thought of doing it was that each screen would be its own org.eclipse.swt.widgets.Shell. Switching from one screen to another would involve a display manager class creating the new screen (shell) and disposing of the old one (not sure of the performance hit here of creating the shell and all of the widgets every time the screen is shown?). I am not sure though if having multiple shells in one mobile application is a good idea??
Does anyone have any suggestions on the best way to handle multiple screens in a mobile application using SWT? Is there an equivalent to the method we are currently using in AWT, i.e. CardLayout? Or am I right in thinking that this is not really the best way of doing it, given the use of resources for every screen, even if they are not being displayed?
So the answer to my own question seems to be that there is in fact a StackLayout in SWT, which is pretty much identical to CardLayout in AWT. So I can use that and the job of porting from one to the other is pretty easy because they act in the same way.
Not sure how it would play out in Windows Mobile, but MigLayout is a great layout manager for SWT, which may support the kind of layout you describe.
Check out its demos.