How can I globally compress Matisse-generated GroupLayout and perhaps other gap spacings to make Swing dialogs generated with Matisse and GroupLayout more compact?
I have used Matisse to re-implement in Java Swing some large dialogs originally developed for Windows in Visual Basic's GUI builder.
The results in the Swing Windows L&F are very similar to native (of a certain age), except more "spread out." At lower res they leak off the screen. This is a real problem for the app.
Measuring shows all the gaps proportionally bigger than the Windows defaults. (The way Swing scales for different resolutions is not helping either.) This includes ContainerGaps emitted by Matisse and L&F-controlled gaps between GUI components.
I have looked at GroupLayout documents and the Matisse documentation I can find. I've looked at L&F parameters and the ContainerGap and related classes in the GroupLayout source. Nothing is taking me where I need to go.
All insight appreciated.
There are too many ways this could be wrong and no single point of adjustment that will fix it. The Visual Basic version surely looks good on its single target platform. By design, Swing relies on pack(), which "Causes this Window to be sized to fit the preferred size and layouts of its subcomponents." The preferred size may vary by platform, as shown in this nested layout example. Instead, study available layouts and use the GUI designer in a focused way, as suggested here.
There's no easy way to fix layout problems in the GUI designer without understanding Swing layouts; happily, the GUI designer is an excellent way to study the effects of various Swing layouts.
Related
JFrame is Extending Frame. Then, How JFrame is lightweight but Frame is heavyweight?
I red this article but still i didn't get how JFrame achieves its lightweight property?
I got from here that JFrame is heavyweight but other Components starts with J* are lightweight. How other Swing components achieves this. I need bit of technical details.
Technically it's not. Both are heavy weight components, but because JFrame has been setup to support the JRootPane, which contains the content pane (and possibly) the glass pane (as well as the JMenuBar), it is consider "light weight", because it's been deliberately configured to support light weight components
Essentially JFrame and JWindow have been modified as light weight containers that support light weight components
it is still a heavyweight component because it(JFrame) inherits from the Frame.And it is not belong to the JComponents which is lightweight components.
Heavyweight means each Java component has a native peer associated with it. A native peer is an OS-specific component... AWT is heavyweight, so if you create a AWT Button, on the Windows platform an MFC button is created, on *nix a Motif button is created, etc.
Lightweight means that there is not a native peer associated with the java component. This is done by having only the top-level component be heavyweight and all the lightweight components are drawn on to it. Swing is lightweight.
Of course, AWT and Swing are specific to standard Java (J2SE). Under J2ME it depends on what sort of device you are using. If you are using a more powerful device, like the Sharp Zaurus, then you have AWT and functionality pretty close to J2SE levels. If you have something like a Java-Enabled cell phone, you don't have all the capabilites that you need for a fully featured GUI, so there are special libraries used for making these applications. You'd need to look at the APIs provided by the device manufacturer most probably.
JFrames are heavyweight, since it's impossible to create a task-view-level window in most OS without creating a "heavy" AWT window. Lightweight components can replace internal widgets with java-based stuff that doesn't require JNI calls, but windows are the special case. JFrame does let you do custom renders, though. Also, if you're using other lightweight stuff, then I suggest using JFrame as well since it makes the rendering more efficient overall than mixing light and heavy components.
It is still a heavyweight component because it(JFrame) inherits from the Frame. And it is not belong to the JComponents which is lightweight components.
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
This question might not seem very technical but, out of curiosity,I want to know that:
How does bare/raw Swing code written by me, turn into a wonderful graphical application?
For example:
Like when we make a JFrame visible, or when we place a JButton on it. Who makes it happen? OS or Java or JVM.
Who makes the colors come up?
What is the process going on behind the scenes?
I ask this maybe because its the first time in my life that I made a RealWorld graphical application and these questions popped up in my mind!
Thanks in advance!
In Swing, all the GUI components are written entirely in Java and are rendered using Java. For example, JButtons would be drawn by Java and not by any internal OS stuff. Thus, Swing components are called "light-weight components" because they are managed and rendered by Java instead of by the OS (or any native widget toolkit).
Note that Java also has a toolkit called AWT. Swing is based on nested and inherited methods from AWT, except that it creates native widgets using the OS.
So at some point, Swing will have to create a window on the screen and draw on it. The magic that actually creates the window is handled by AWT. Notice that JFrame extends from java.awt.Frame which means that although JFrame may be rendered mostly by Java, it is backed by a heavy-weight native OS window.
In short, there's an AWT toolkit, which is the layer that does all the window management and drawing. It is calling native platform specific code inside the JVM. It is also responsible for java2d drawing. It can use accelerated directx or opengl pipelines.
Swing is developed on top of it. Swing actually draws every button and every object with plain java code. The drawing is handled to a current look and feels that decide how to draw components. So you can override their paint methods, and add some extra things without any problems.
Metal and Nimus LaF are 100% java2d drawn, so inside of them you will find things like drawRectangle and drawLine to draw components. Native look and feels, like windows, gtk, access current operating systems theme to draw something that looks similar to native widgets. That is why they do not always look like native applications.
There are also other gui toolkits for java, like SWT, used, for example, in Eclipse. What it is doing, is getting the window from the AWT, and then putting 100% native widgets on it. It is much better integrated with the OS, looks better, works faster, uses less memory. But with it, you'd have to distribute your application with os specific native libraries and it is less customizable, compared to Swing.
I don't know all the details, but the actual graphics are displayed/rendered via the swing/awt packages through the JVM itself.
My Swing Application's GUI is built using Window Builder Pro GUI editor. Layouts used are MigLayout and AbsoluteLayout. Application is developed using Windows Machine, So UI is well aligned and neat in Windows, but when I run the same application in Mac OS X, Application's Frame couldn't accommodate the components inside its bounds. I mean, size of Components inside the frame changes across platforms. When I give extra space(Increased frame bounds), it looks nice in Mac but weird in Windows. Is there any way to have Frame or Panel to grow with respect to its contents or Components.
Don't use the absolute layout. Layout managers are used precisely to avoid the kind of problems that you're facing.
Assuming you used AbsoluteLayout because none of the existing layout managers suited your needs,
Have a look at Creating a Custom Layout Manager and use one instead of AbsoluteLayout.(Before that make sure none of the present layout managers suit your need)
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.