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.
Related
I'm new here and not so much familiar with applets.
I searched the site and many other forums for answer but i found nothing.
I have made an application in Java which starts with an applet login form, and continues with JFrame subforms which are doing several things like running JOptionPanes for example when a customer make a change in his profile.
My problem is that when the JOptionPane appears, the applet start form comes on top even if i have opened 2 or 3 JFrames.
I forgot to say that my app is big so i cannot post any code (and i think is not needed).
Thanks in advance!
Avoid mixing frames and applets, your working with competing paradigms. If you MUST use an applet, use something like a CardLayout or JTabbedPane to allow the user to switch between forms.
If you can, try using Java Web Start, which will allow you to start your application off the web, but have the same restrictions as that of any embedded GUI.
As to your problem, it sends like you are mixing the native peer for the JOptionPane. Make sure that the parent reference is correct (ie references the frame or child of the frame)
I have a program that uses a JFrame. I would like to make it so people could play my game from a website. Is there an easy way to turn JFrames into JApplets?
I have a program that uses a jFrame. I would like to make it so people could play my game from a website. ..
Launch the JFrame directly off a web site using Java Web Start. JWS offers many neat features, like auto-update & desktop integration (menu items, desktop shortcut).
..Is there an easy way to turn jFrames into jApplets?
When it comes to applets, nothing is easy.
It is always a matter of dealing with how different (versions of different) browsers, on different (versions of different) OS, using different (versions of different) Java plug-ins interact with each other. And that can often be summed up as 'poorly'.
I think the best way is to code your application to be contained within a JPanel. Then in the main method create the JFrame and adds that JPanel to it. Likewise, you can create a JApplet that gets created and just add the JPanel. This way your Swing application will be generally agnostic with regards to the top-level container.
You can simply create a JFrame from the applet. This JFrame then is a new OS window, and not still embedded in your browser.
Our program shows an example of this (of both popping up an external JFrame (or JDialog) and having components inside the applet, actually). (No source available, though.)
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.
I'm writing a genome browser designed primarily to view the history of chromosomal rearrangements. Right now the project is a series of proof-of-concept demos written using Processing. At this point if I don't make any radical changes the final application will be a web applet with a gui built of swing components that open PApplets to actually show the rearrangements happening.
My question is: Should I give up on processing and switch over to pure Swing/AWT? This is my first big java project. I'm building in eclipse, but I can use netbeans as well. If I could embed PApplet objects inside a JFrame, for example, that would make my day.
processing.core.PApplet extends java.applet.Applet, so it should be possible to embed
a PApplet in a java.awt.Frame, as discussed in the article Applet ⇒ application: Hybrid Switch Hitters. See also, Mixing heavy and light components.
Addendum: From the API, "Processing runs in a Frame and not a JFrame. However, there's nothing to prevent you from embedding a PApplet into a JFrame," except for the limitations mentioned above.
Keep in mind that I know almost nothing about either Processing or your project, so I can only give you general advice.
The question that you should ask yourself before every major design change: what problem am I trying to solve by making this change? If the current architecture works, then you should keep it. If it's not working, then you should start by defining the specific things that are wrong with it (which I notice you didn't do).
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.