In Swing, it appears there are two ways of setting the theme/look-and-feel of the application:
JFrame.setDefaultLookAndFeelDecorated, and
UIManager.setLookAndFeel
I'm wondering what the difference is between these is and when/why to use either of them.
Only the UIManager.setLookAndFeel(...) methods allow setting the look and feel of the application. This is the method you want to use to set a specific look and feel to your application.
Using the static JFrame.setDefaultLookAndFeelDecorated(...) will only affect how newly created JFrames will have their windows "decorated" (i.e. window title bar, close/minimize button etc). Either by the LookAndFeel or by the system (or the "window manager"). It does not affect the look and feel of the application in general.
From the docs:
If defaultLookAndFeelDecorated is true, the current LookAndFeel supports providing window decorations, and the current window manager supports undecorated windows, then newly created JFrames will have their Window decorations provided by the current LookAndFeel. Otherwise, newly created JFrames will have their Window decorations provided by the current window manager.
Personally, I rarely find good use for the latter method.
I have a task to create a desktop app and I decided to use Swing as I have some experience with it. Also I am using Intllij and I noticed it have a form creator visual interface so I want to use it because its easier.
Samples of my interface is attached here. Its not hard but I dont know which controls to use in order to make something like this. On startup I need to have some text on the right side of the window, then on press on different button on the left to change that text with some other controls like fields labels check boxes etc. Its bit like tabs but I cannot use the JTabbedPane because it become with too different design. Could you advice me which controls to use and how to use them in order to achieve this design ?
Here is the design:
Also I am using Intllij and I noticed it have a form creator visual interface so I want to use it because its easier.
It isn't easier as you end up spending time learning the IDE instead of learning Swing. Any code that is generated will not be maintainable if you ever need to switch to a different IDE.
Learn how to create/maintain the GUI forms manually.
, then on press on different button on the left to change that text with some other controls like fields labels check boxes etc
Start with the standard BorderLayout for the frame. Then you create a panel with your buttons to display on the left. You create a second panel that uses a CardLayout in the CENTER of the BorderLayout. Then when you click a button you swap the panel that is displayed in the CENTER.
Read the section from the Swing tutorial on Layout Managers. There are sections on:
How to Use BorderLayout
How to Use CardLayout
to get your started with working examples.
If you are creating a commercial application(rather then as a leaning experience) consider using JIDE Common Layer as the MultiplePageDialog provides the functionality you seem to be describing:
In this case a series of buttons on the left controlling a panel on the right
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I'm developing an application which displays images, and plays sounds from a database. I'm trying to decide whether or not to use a separate JFrame to add images to the database from the GUI.
I'm just wondering whether it is good practice to use multiple JFrame windows?
I'm just wondering whether it is good practice to use multiple JFrames?
Bad (bad, bad) practice.
User unfriendly: The user sees multiple icons in their task bar when expecting to see only one. Plus the side effects of the coding problems..
A nightmare to code and maintain:
A modal dialog offers the easy opportunity to focus attention on the content of that dialog - choose/fix/cancel this, then proceed. Multiple frames do not.
A dialog (or floating tool-bar) with a parent will come to front when the parent is clicked on - you'd have to implement that in frames if that was the desired behavior.
There are any number of ways of displaying many elements in one GUI, e.g.:
CardLayout (short demo.). Good for:
Showing wizard like dialogs.
Displaying list, tree etc. selections for items that have an associated component.
Flipping between no component and visible component.
JInternalFrame/JDesktopPane typically used for an MDI.
JTabbedPane for groups of components.
JSplitPane A way to display two components of which the importance between one or the other (the size) varies according to what the user is doing.
JLayeredPane far many well ..layered components.
JToolBar typically contains groups of actions or controls. Can be dragged around the GUI, or off it entirely according to user need. As mentioned above, will minimize/restore according to the parent doing so.
As items in a JList (simple example below).
As nodes in a JTree.
Nested layouts.
But if those strategies do not work for a particular use-case, try the following. Establish a single main JFrame, then have JDialog or JOptionPane instances appear for the rest of the free-floating elements, using the frame as the parent for the dialogs.
Many images
In this case where the multiple elements are images, it would be better to use either of the following instead:
A single JLabel (centered in a scroll pane) to display whichever image the user is interested in at that moment. As seen in ImageViewer.
A single row JList. As seen in this answer. The 'single row' part of that only works if they are all the same dimensions. Alternately, if you are prepared to scale the images on the fly, and they are all the same aspect ratio (e.g. 4:3 or 16:9).
The multiple JFrame approach has been something I've implemented since I began programming Swing apps. For the most part, I did it in the beginning because I didn't know any better. However, as I matured in my experience and knowledge as a developer and as began to read and absorb the opinions of so many more experienced Java devs online, I made an attempt to shift away from the multiple JFrame approach (both in current projects and future projects) only to be met with... get this... resistance from my clients! As I began implementing modal dialogs to control "child" windows and JInternalFrames for separate components, my clients began to complain! I was quite surprised, as I was doing what I thought was best-practice! But, as they say, "A happy wife is a happy life." Same goes for your clients. Of course, I am a contractor so my end-users have direct access to me, the developer, which is obviously not a common scenario.
So, I'm going to explain the benefits of the multiple JFrame approach, as well as myth-bust some of the cons that others have presented.
Ultimate flexibility in layout - By allowing separate JFrames, you give your end-user the ability to spread out and control what's on his/her screen. The concept feels "open" and non-constricting. You lose this when you go towards one big JFrame and a bunch of JInternalFrames.
Works well for very modularized applications - In my case, most of my applications have 3 - 5 big "modules" that really have nothing to do with each other whatsoever. For instance, one module might be a sales dashboard and one might be an accounting dashboard. They don't talk to each other or anything. However, the executive might want to open both and them being separate frames on the taskbar makes his life easier.
Makes it easy for end-users to reference outside material - Once, I had this situation: My app had a "data viewer," from which you could click "Add New" and it would open a data entry screen. Initially, both were JFrames. However, I wanted the data entry screen to be a JDialog whose parent was the data viewer. I made the change, and immediately I received a call from an end-user who relied heavily on the fact that he could minimize or close the viewer and keep the editor open while he referenced another part of the program (or a website, I don't remember). He's not on a multi-monitor, so he needed the entry dialog to be first and something else to be second, with the data viewer completely hidden. This was impossible with a JDialog and certainly would've been impossible with a JInternalFrame as well. I begrudgingly changed it back to being separate JFrames for his sanity, but it taught me an important lesson.
Myth: Hard to code - This is not true in my experience. I don't see why it would be any easier to create a JInternalFrame than a JFrame. In fact, in my experience, JInternalFrames offer much less flexibility. I have developed a systematic way of handling the opening & closing of JFrames in my apps that really works well. I control the frame almost completely from within the frame's code itself; the creation of the new frame, SwingWorkers that control the retrieval of data on background threads and the GUI code on EDT, restoring/bringing to front the frame if the user tries to open it twice, etc. All you need to open my JFrames is call a public static method open() and the open method, combined with a windowClosing() event handles the rest (is the frame already open? is it not open, but loading? etc.) I made this approach a template so it's not difficult to implement for each frame.
Myth/Unproven: Resource Heavy - I'd like to see some facts behind this speculative statement. Although, perhaps, you could say a JFrame needs more space than a JInternalFrame, even if you open up 100 JFrames, how many more resources would you really be consuming? If your concern is memory leaks because of resources: calling dispose() frees all resources used by the frame for garbage collection (and, again I say, a JInternalFrame should invoke exactly the same concern).
I've written a lot and I feel like I could write more. Anyways, I hope I don't get down-voted simply because it's an unpopular opinion. The question is clearly a valuable one and I hope I've provided a valuable answer, even if it isn't the common opinion.
A great example of multiple frames/single document per frame (SDI) vs single frame/multiple documents per frame (MDI) is Microsoft Excel. Some of MDI benefits:
it is possible to have a few windows in non rectangular shape - so they don't hide desktop or other window from another process (e.g. web browser)
it is possible to open a window from another process over one Excel window while writing in second Excel window - with MDI, trying to write in one of internal windows will give focus to the entire Excel window, hence hiding window from another process
it is possible to have different documents on different screens, which is especially useful when screens do not have the same resolution
SDI (Single-Document Interface, i.e., every window can only have a single document):
MDI (Multiple-Document Interface, i.e., every window can have multiple documents):
I'd like to counter the "not user friendly" argument with an example that I have just been involved with.
In our application we have a main window where the users run various 'programs' as separate tabs. As much as possible we have tried to keep our application to this single window.
One of the 'programs' they run presents a list of reports that have been generated by the system, and the user can click on an icon on each line to pop open a report viewer dialog. This viewer is showing the equivalent of the portrait/landscape A4 page(s) of the report, so the users like this window to be quite big, almost filling their screens.
A few months ago we started getting requests from our customers to make these report viewer windows modeless, so that they could have multiple reports open at the same time.
For some time I resisted this request as I did not think this was a good solution. However, my mind was changed when I found out how the users were getting around this 'deficiency' of our system.
They were opening a viewer, using the 'Save As' facility to save the report as a PDF to a specific directory, using Acrobat Reader to open the PDF file, and then they would do the same with the next report. They would have multiple Acrobat Readers running with the various report outputs that they wanted to look at.
So I relented and made the viewer modeless. This means that each viewer has a task-bar icon.
When the latest version was released to them last week, the overwhelming response from them is that they LOVE it. It's been one of our most popular recent enhancements to the system.
So you go ahead and tell your users that what they want is bad, but ultimately it won't do you any favours.
SOME NOTES:
It seems to be best practice to use JDialog's for these modeless windows
Use the constructors that use the new ModalityType rather than the boolean modal argument. This is what gives these dialogs the task-bar icon.
For modeless dialogs, pass a null parent to the constructor, but locate them relative to their 'parent' window.
Version 6 of Java on Windows has a bug which means that your main window can become 'always on top' without you telling it. Upgrade to version 7 to fix this
Make an jInternalFrame into main frame and make it invisible. Then you can use it for further events.
jInternalFrame.setSize(300,150);
jInternalFrame.setVisible(true);
It's been a while since the last time i touch swing but in general is a bad practice to do this. Some of the main disadvantages that comes to mind:
It's more expensive: you will have to allocate way more resources to draw a JFrame that other kind of window container, such as Dialog or JInternalFrame.
Not user friendly: It is not easy to navigate into a bunch of JFrame stuck together, it will look like your application is a set of applications inconsistent and poorly design.
It's easy to use JInternalFrame This is kind of retorical, now it's way easier and other people smarter ( or with more spare time) than us have already think through the Desktop and JInternalFrame pattern, so I would recommend to use it.
Bad practice definitely. One reason is that it is not very 'user-friendly' for the fact that every JFrame shows a new taskbar icon. Controlling multiple JFrames will have you ripping your hair out.
Personally, I would use ONE JFrame for your kind of application. Methods of displaying multiple things is up to you, there are many. Canvases, JInternalFrame, CardLayout, even JPanels possibly.
Multiple JFrame objects = Pain, trouble, and problems.
I think using multiple Jframes is not a good idea.
Instead we can use JPanels more than one or more JPanel in the same JFrame.
Also we can switch between this JPanels. So it gives us freedom to display more than on thing in the JFrame.
For each JPanel we can design different things and all this JPanel can be displayed on the single JFrameone at a time.
To switch between this JPanels use JMenuBar with JMenuItems for each JPanelor 'JButtonfor eachJPanel`.
More than one JFrame is not a good practice, but there is nothing wrong if we want more than one JFrame.
But its better to change one JFrame for our different needs rather than having multiple JFrames.
If the frames are going to be the same size, why not create the frame and pass the frame then as a reference to it instead.
When you have passed the frame you can then decide how to populate it. It would be like having a method for calculating the average of a set of figures. Would you create the method over and over again?
It is not a good practice but even though you wish to use it you can use the singleton pattern as its good. I have used the singleton patterns in most of my project its good.
We are going to use Swing for our next project which will be a lightweight desktop app.
I've been reading the Swing tutorials on Oracle's website and have started to get the hang of it.
I was told that instead of switching JFrame I need to work within one JFrame and switch JPanels.
My questions to you would be the following.
Can I create the JPanel designs (or their templates) in design mode (WYSIWYG editor) and call jframe.setContentPane(nameOfJPanel) or do I do them programatically in code?
Secondly, how do I structure my code... If I dynamically add new JPanels and bind their events to an event handler.. all my logic and code will be in one HUGE class with tens of methods. I just don't know how to proceed and nowhere can I find an example with multiple (more than 6 let's say) panels on the internet.
To WYSIWYG or not WYSIWYG
This is a debatable question at the best of times.
I encourage all my junior developers to start out hand coding UIs as it teaches them important basics about how to use layout managers and how to handle compound layouts.
This tends to take longer as you need to verify the layout with each change.
I personally use the form editor in Netbeans for most of my general work, but will hand tweak UI's
Structure
Think about boundaries of responsibility, reuse and reduce strategies.
What you don't want is some huge master class that does EVERYTHING. It will be difficult to maintain and update (I live with this horror every day).
Instead, identify the distinct areas of responsibility and either use getters and setters or models to move the data around the application. The more you can decouple your code, the easier it will be to update and modify.
Identify like work and model it as interfaces and abstract classes where you can. Basically where ever you start thinking about coping code is probably a good indication that your design is off and you should consider implementing abstract classes to cover the overlap.
Take advantage of the Action API for replicating commonly used concepts (copy and paste is an example of this. You would want menu items, possible toolbar items and maybe even popup items, these can all be handled by the same Action class).
Separate the data from view. As I said before, take advantage of models. The data shouldn't care how it is collected or modified, only that it can be. Equally, the view shouldn't care about how the data is managed, only that it is.
If possible, define interfaces between the separate areas of your application. This way you can further decouple of the application and no one part becomes reliant on any one implementation (hello my world :P)
Don't be tempted to simply dig through a component hierarchy to gain access to that field, it will produce a nightmare if you need to change the code!!
The JFrame will be the main window of your app and the panels will be the brick composing it.
You should create each panel in its own class and you can arrange them by functionality in packages. You'll have panels for holding content of logical part of your application and panels that contains real stuff.
A logical panel could be the main view and the menu bar. An application panel would be a form, a menu, a canvas...
You'll have to put application panels inside logical panel and to change the content of the logical in response to users actions.
You should study how layouts work in order to compose the view inside the JFrame and to layout components inside panels.
For example the BorderLayout is a classic when defining the main area of an application:
- menu and toolbar on top
- browser on the left
- status bar at the bottom
- main panel on the center
You can use WYSIWYG editor, but avoid doing all design inside the same class. Else you'll have an horrible HUGE class. Create your panels in separate classes and compose them in your main view.
You can use empty panels as placeholder to help you create the structure of your application.
You'll have to bind your domain data to the view in order to not mix the two layer.
Bind means that you will write a way to go from a java bean to a form and the reverse.
Basic binding is handwritten, but some tools exists to do that.
If it is a small application, it is maybe better for you to handwrite everything.
Building a Swing application can be very tricky (you'll have to know about the event dispatch thread, layout management, event management, widgets (label are trivial, but JTable can be very complicated to handle);
I'll recommend to find a book about the topic, and to find some open source swing application in order to study how it structured, before you start your project.
This is how I organize my code:
class Panel1 extends JPanel{
//code for panel1 and its Components
}
class Panel2 extends JPanel{
//code for panel2 and its components
}
// and it follows.
class ApplicationFrame extends JFrame{
/// LOGIC to switch between panels
}
class Main{
//contains main() function
}
Any HAND-CRAFTED GUI code, is better than a COMPUTER GENERATED WYSIWYG -APP Code.
*EDIT 2: I just discovered that this is a compiz+java GUI problem. It apparently happens where those two elements intersect.
I'm running the latest Ubuntu 11.04 (classic desktop, not Unity) with all updates. The problem happens with both Sun java and OpenJDK. It is related to using the Window-Rules Compiz plugin -- which I need to use.
As stated in comments below, I previously verified that my controls are added to the correct thread. Now I found that disabling the Compiz Window-Rules plugin resolves my issue. Since I need to use the plugin, I am looking for a solution.*
Original post: I am working on a Java swing application. It was built with NetBeans 6.9. It uses GridBagLayout manager. The look and feel is currently Nimbus (but that doesn't seem to have any effect on the issue I'm going to describe). Most users run the app on Linux. A few use Windows. Most of the time the app works fine. But at random times a view will open without some of the GUI buttons. For example, the Save and Cancel buttons might be missing. The other GUI elements will usually be present (although once I have heard that a view was completely empty with no GUI elements -- just an empty gray window).
If the user closes that view with the "X" in the upper corner and simply re-opens it, it will be drawn correctly. The missing buttons issue happens less than 1% of the time. The close/reopen sequence fixes it almost 100% of the time. (A second close/reopen may have been needed once, if I recall correctly.)
Typically, if some buttons are missing, the other elements are still drawn correctly. This does not affect the whole view (form). It seems to affect the lowermost panel, but I'm not sure if that is actually a repeatable pattern. It is very difficult to reproduce this. I use the software every day and I see this less than once a month. A few users see it more frequently, but it is still rare.
There are no error messages. I have no idea what to try next. This behavior has persisted across different computers, different Linux distros (although all are based on Debian), and many different code changes, including changing the layout manager. (We used the NetBeans GUI designer previously.) Any ideas?
EDIT: 2011.07.05
This is what the code looks like in general:
public void show_some_view() {
setTitle(...)
setLayout(new GridBagLayout());
JPanel butnPanel = new JPanel();
butnPanel.setLayout(new GridBagLayout());
try {
//add stuff to panels (butnPanel, etc.)
} catch (Exception e) {
Logger.log(e);
}
setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
int[] wh = ApplicationContext.get().getDisplayWidthxHeight();
setSize(wh[0], wh[1]);
setFocusable(true);
setVisible(true);
}
But at random times a view will open without some of the GUI buttons.
Make sure you add the buttons to the GUI on the EDT. Read the section from the Swing tutorial on Concurrency for more information.
Make sure you add the buttons to the GUI BEFORE invoking setVisible(true);
I had the same problem: sometimes my JMenu wouldn't draw (also on Ubuntu 11.04).
I fixed it by just adding
menuBar.setVisible(false);
menuBar.setVisible(true);
To my code, right after I added it to my JFrame (Which was alreasy set to visible).
I know it's messy but it solved my problem so I'm fine with it.
Hope this helps!