I'm creating a cross platform application using Swing and Netbeans (Group Layout). Is there a trick I am missing to help develop dialogs with say OK, Cancel buttons in the correct order for different platforms - specifically Windows (OK-Cancel) and Mac (Cancel-OK), rather like the JOptionPane does? I can derive my own class from JDialog with two buttons on it, and swap text and actions around - I just wondered if there is something 'out of the box' I've missed. (This is not a question about which way round buttons should be, or the use of verbs e.g. Save instead of Ok.)
MiGLayout supports this out of the box. Either use this layout manager, or look how it does its magic.
Eclipse SWT also provides platform-aware layouts.
Related
I know in java-fx to make the window transparent, you need to set the stage style as stage.initStyle(StageStyle.TRANSPARENT);. However this will also remove any stage decorations so this does not solve my problem.
The reason I need this is because my application will need to use stage.setAlwaysOnTop(); at certain points, but this feature is not well supported on the target system (centOS). The application also requires stage.setIconnified();, but this does not work if the stage is undecorated.
Any suggestions will be appreciated.
Thanks
The short answer would be "no, you can't" ... because the minimize/maximize/close buttons are part of the decoration. No decoration - no buttons. It would be a contradiction in itself.
If you need the functionality of those buttons, you would have to create your own buttons as a part of your UI and emulate the behaviour of the decoration buttons. That's what many apps do that come with no default decoration.
Anyway, if you want to manipulate the window behaviour in this way (stay-on-top/iconify, etc.) you always need to take the underlying operating system into account. Any apps (not only Java apps) are only allowed to interfere with window management as far as the OS windowing system allows them to do so.
For example, in various MS Windows versions, the OS behaviour changed several times at this point.
Is there any possibility to hide/remove the buttons of the org.eclipse.swt.widgets.Spinner control without completely reimplementing it?
The easiest way I can think of would be a style-Flag but I was not able to find one which influences the buttons.
Maybe it is not possible at all since the OS manages the implementation of those controls.
Looking at the source of the Spinner class there is no support for leaving out the buttons.
I looked at the Mac, Windows and Linux versions of the source.
I developed a Java application in Netbeans, and I'm going to release it soon so I'm working on making it less ugly. Since I'm developing on a Mac, the GUI builder uses the Mac Look & Feel, which looks decent, but many of my users won't be using Macs. The default L&F is Nimbus, which looks fine except for the buttons, which have annoying borders that are not overridden by the manually setting the borders (you can see how the manual borders look in the image). With the manually set borders, the Nimbus L&F adds its own odd border inside the border I made, which just looks idiotic. Without the manually set borders, Nimbus's borders overlap in visually unappealing ways, and in order to avoid overlap I have to space the buttons really far apart, which I also don't like.
I tried using the other L&Fs available in Netbeans (Metal and something else), but they're just too ugly to stand.
Basically, I would like some advice on how to customize the way buttons look in this application. I don't want to write a button drawing function from scratch or design my own images. I just want a way to change the settings so things don't look stupid. I read in various places that the Substance L&F is good, but I can't find where to download it anywhere. If someone could link me to a download page for Substance or recommend another popular, simple and not stupid-looking L&F, I would greatly appreciate it.
Yeah pretty much all the L&Fs you'll find in Netbeans are worse than the default. The program will use the default Look & Feel of the operating system - so if it's being run on Windows it will have the "Windows-esce" buttons and fonts and on Mac will have the Mac style.
It all depends on what you're looking for. If you're application is meant to be professional and you don't mind it having different styles depending on the OS of the user then I'd leave it as default. It lends familiarity to your program which can truly make the user feel much more comfortable.
If you're after an indetical look for all users then, as you know, you just need to include the L&F with your program. I couldn't find a download for Substance but there are a few L&F's here - both commercial and free.
http://www.java2s.com/Product/Java/Swing/Look-And-Feel-LaF.htm
I am currently toying with the idea of converting a small/medium sized project from AWT to SWT, although Swing is not totally out of the picture yet.
I was thinking about converting the main window to an SWT_AWT bridge object, but I have no idea how the semantics for this work. After that, I plan to update dialog for dialog, but not necessarily within one release. Is this possible?
Has someone done a conversion like this and can give me some hints? Is there maybe even a tutorial somewhere out there? Is there maybe even a tool that can automate parts of this? I have tried googling, but to no avail.
Update: One additional thing is: Currently, this is a netbeans project. Might be of help or not, I don't know.
We have done this quite a few times. But only because we are going from a Swing application to an Eclipse RCP application not because we like messing with things. This project will really let you know whether you've separated your controller/model code from your view code.
One suggestion is to not try and convert everything all at once. You will end up with a bunch of mixed code that doesn't work at all. You can start at converting portals. I would consider a portal anything within a Tab, Dialog, or Window, essentially self contained unit. If you have a window that opens up, create the Window in SWT, but make it's contents the existing AWT/Swing. This should be fairly straight forward and allow you to get used to the (I really hope they weren't drunk and had a good reason for this) way of instantiating and associating parent/child controls.
One gotcha that can occur is with transparent components. Swing, with the exception of a "window" class is all rendered in Java. This makes it very easy to render things the way you want them. In SWT, there are some restrictions:
Borders. If you use SWT.BORDER you are stuck with whatever color the native component uses. Your best bet is to use a PaintListener and render your own borders if you want them in a different style or color.
Transparent labels, progress bars. I have not been able to get Labels or Progress Bars to have a transparent background. If you want them to take on the parent color, or drawing you will need to render the text and other controls yourself.
Controls. There are composites and controls in SWT. Think of Controls as the basic native controls that do all the native API calls. These cannot be subclassed, which makes things difficult.
Tables will give you the most trouble. Make sure everything is stable before you attempt to convert a JTable to a Table or TableViewer. You will spend some time on these, especially if you have custom editors and viewers.
I have not researched why SWT was designed the way it was. I am guessing there HAD to be a good reason. It would be great if someone had a blog or defense to it's design so I don't have to search for it. Once it's posted I'll remove these lines since they have no relevance to the question.
Addition
I want to add that since you have an existing product I assume works. The best piece of advice I can give you is to never let your code get into a state that it cannot compile and run. If you work on your conversion and whatever you check in always runs and executes (despite the visual differences between SWT/AWT/Swing) you will save yourself many headaches in the long run. The worst thing you can do is try to tackle this all at once and get your code in an unstable state for weeks at a time.
I would suggest importing it into a WindowBuilder project, as WindowBuilder gives you the ability to parse existing code and create a GUI mock-up, then morph components to either SWT or Swing.
If you're thinking of using a mix of SWT and Swing in the same application, this Eclipse Corner Article will be immensely useful.
We are preparing the same step: Swing to SWT/JFace. First we try to determine the bottlenecks: reimplement special components derived from JComponent with SWT/JFace, search for a replacement of JIDE docking (we want to use SWT/JFace, not RCP to avoid too much hassle). The worst thing we already imagine is, that in Swing you could create components and adding it later to the parent. With SWT this is not possible: the parent component must be passed as a reference to the child component's constructor. This will require major refactoring in the Swing application before using SWT.
Frankly, we rate the conversion a very heavy change, because we expect the time where nothing can be compiled as quite long. We try to decrease this time by preparing everything as good as possible, but we'll see how good it will work.
Update from April 6th 2011:
We now refactored our Swing application to always create components with their parent (as in SWT). Our subclasses of JFrame and JDialog got refactored to just have a JDialog instance to make it easier to switch to SWT's Shell. In parallel, we rewrite sophisticated components in SWT.
Is there a way to write a Java Swing application with a custom chrome? Please take a look* at the frame for Microsoft's Zune 4.0 software.
I realize that colors, the shape of scroll bars, etc. are controlled by skins or looks and feels. Right now I'm trying to tackle the native window which houses the java components--the title bar mainly.
Thanks
(*) http://www.winsupersite.com/zune/zune4_shots.asp
By default the frame of a JFrame is native. This can be removed by calling Frame.setUndecorated. The Sun Window PL&F does not provide a title bar. You could hack aJInternalFrame so that it draws the frame, although that probably isn't going to be as easy as it may seem. Of course, if you are going the full custom route, you can draw whatever you want. From 6u10, Sun's JRE also provides APIs to make windows transparent and non-rectangular.
No part of a Swing component's look and feel is "native" in any way. Swing components are "lightweight", which means they are entirely drawn on the Java side, and not at all on the windowing system side.
To create custom "chrome" you create the UI delegates for one or more components. In yor case, you'd want to muck around with the delegates for JRootPane and JInternalFrame.
The Look and Feel of Swing apps are pluggable..that is it can change on the fly. You can create your own look and feel but its not a simple undertaking. To get started this tutorial explains. This article does a little more.
This project demonstrates what could be done. So its up to your imagination.