What is a top-level window in java awt? - java

I found this line on the java docs tutorial site- "A Frame is a top-level window with a title and a border". Here, what is the meaning of "top-level window"?

A 'top-level window' or 'top level container' is something that can be shown on screen without having to add it to another component. We would start a GUI with a top level container, and then add panels and components to that TLC. E.G. of top level containers..
AWT - Frame, Window, Dialog ..
Swing - JFrame, JWindow, JDialog, JOptionPane ..
Java-FX - Stage (I have not used Java-FX much, so am unfamiliar with the other variants of TLCs, but see the Java-FX API docs for other examples).
See also this answer for many good reasons to abandon AWT components in favor of Swing. As to abandoning Swing for Java-FX, I'll be unwilling to do so until Java-FX is promoted to the Java API's Java docs, and makes it into the official Java Tutorial. Sun, then Oracle, has a bad habit of hyping many technologies only to later quietly drop support & development for them.

In GUI toolkits such as AWT, a top-level window is a window which is usually known to the OS (heavy-weight components).
Side note: AWT (and even Swing) is a pretty old technology. I recommend to use JavaFX where possible.

a window without a parent.
a window can have child windows alright and they have a parent then

Observe difference among these classes.
Frame is top level window because it has border and title. An instance
of frame can have a menubar. Without those it is mere is an instance
of java.awt.Window class.
Window class: It has neither border not title. Window class is not attached to nor embedded within another container.
Dialog: It has border and title. An instance of the Dialog class cannot exist without an associated instance of the Frame class.
Panel: just a generic container to hold components. Its instance provides a container to which to add components.
Note: Revert me back if further clarification is required.

Related

How is a JFrame actually created?

I am curious about how Java actually goes about creating a JFrame in swing; how does a window magically pop up? So, I went ahead and looked at the source code for the JFrame and ended up at the source code for the Window class.
In the Window class, there’s so much going on I can’t tell what hints at the initialization of a displayed window. I am a beginner, and even if it’s really high level stuff, I still want to be to see the actual code for making a window.
Maybe I’m looking at the wrong stuff. If someone could point me in the right direction or provide links, that would be great.
EDIT:
If anyone is confused by what I’m trying to ask, say you were to create a window just like a JFrame but from scratch, how would it be done? How is it done in swing?
Window (or more formally java.awt.Window) is a Java API to the platform native toolkit window. All modern OSes (that support display anyway) come with a toolkit.
JFrame and Swing were a secondary attempt at providing a user interface (UI) toolkit in Java that would look and work the same way over multiple OSes. The classes in java.awt like Frame and Dialog were the first attempt, but they had native peer classes (see java.awt.peer - compiled C/C++ code), and rendered and performed very differently across different OSes.
So what is going on under the hood is that JFrame is first creating the most basic window possible from the OS toolkit, and then dressing it up (adding menu bars, scroll bars, etc) to be a JFrame or a JDialog within the swing Java classes themselves.

Java Swing GUI Size under cross-platform

I have a swing gui which has proper JPanel and JDialog size on windows platform with screen size from 13inch to 15inch. What I refer as proper size is that all the components in JPanel and messages at JDialog are properly shown.
However, when running under Ubuntu linux with Genome/Kde desktop, I find the not all components or messages are fully shown and it appears that either width or height is not enough and the GUI interface is cropped
Anybody has ideas of how to fix it?
To have consistent UIs in multiple platforms you have to use LayoutManagers.
http://docs.oracle.com/javase/tutorial/uiswing/layout/visual.html
There are several graphical editors that support creating swing user interfaces using LayoutMaganers. One example is WindowBuilder for Eclipse: http://www.eclipse.org/windowbuilder/
Call Window.pack() for your JDialog before showing it to make the window just big enough to fit all the components in it. This requires that you are using layout managers.

Reduce overlapping of JWebBrowser in Swing

I am developing application based on Swing.
My problem is I use JWebBrowser and I put one in a scrollable panel. When I scroll down the panel the web browser overlaps the panel/frame of the application.
What can I do so the browser does not overlap the panel?
I don't see an answer here, so as someone who has been down this bumpy road, I can sympathize with these issues and would like provide some guidance.
First of all, the JWebBrowser is an AWT heavyweight component, and does not play nicely in Swing (since it uses lightweight components) without some intervention.
Instantiate JWebBrowser like this for the first step of friendly Swing integration:
new JWebBrowser(NSComponentOptions.destroyOnFinalization(),
NSComponentOptions.constrainVisibility(),
NSComponentOptions.proxyComponentHierarchy())
That instantiation alone should prevent the browser from overlapping the Swing lightweight components, however, it will not work as you would expect with transparencies or layers unless you do some additional steps.
So, during construction, call these:
webBrowser.setDoubleBuffered(true);
webBrowser.getNativeComponent().createBackBuffer();
And then, right before the web browser is to be used with any kind of transparency or layers, call these:
rects[0] = webBrowser.getBounds();
webBrowser.getNativeComponent().updateBackBuffer(rects);
Those calls will repaint the backbuffer right before the component is to be used and so when being used, it will be displayed with that most recent backbuffer and will look pretty much like a regular Swing component at that point.
There are some nuances with all of this, but that's the basics and should be enough to get anyone started with it.

AWT and Swing components in NetBeans

Scenario : In NetBeans, you create Swing components via drag & drop and customize some properties via the given GUI.
Question : Later on, If you see the generated code of these components, either in source or by by right-clicking the component and selecting customize code, we can see that the property changes are implemented via AWT. Why is this so?
As mentioned in Using Top-Level Containers,
Each program that uses Swing components has at least one top-level
container. This top-level container is the root of a containment
hierarchy — the hierarchy that contains all of the Swing components
that appear inside the top-level container.
java.awt.Container, an AWT Componenet, is that container.
Addendum: This overview suggests how pervasively the interface java.beans.PropertyChangeListener is used throughout AWT and Swing.

java swing app with a custom titlebar?

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.

Categories

Resources