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.
Related
While java programs are platform independent, the JVM itself is platform dependent. I am interested in knowing how Java draws the application GUI (buttons and text) on the screen.
Under Windows, control objects such as buttons are usually created using a window(from user32.dll) or a rectangular region(from gdi32.dll), text is drawn later to the corresponding window/region handle using the provided user32/gdi32 text draw functions.
I tried running a simple two button Java gui application using swing and hooking the majority of create region/window and text draw functions from gdi32.dll and user32.dll, but so far, it seems the Java program is just using these native dlls for drawing the main window frame only.
Does Java.exe uses some other dlls to draw buttons and other controls on the screen ? And if so, why is this case when there are already available native dlls for drawing ?
On Windows Java2D uses Direct3D renderer to draw primitives by default. You may disable it by specifying -Dsun.java2d.d3d=false. In this case GDI renderer will be used.
Add -Dsun.java2d.trace=log,verbose option to trace which Java2D primitives are called in your Swing application.
From the Wikipedia Article:
Unlike AWT components, Swing components are not implemented by platform-specific code. Instead, they are written entirely in Java and therefore are platform-independent. The term "lightweight" is used to describe such an element.
I was reading through the java docs and found that it is easy to make a shaped windows, making them translucent and coloured as long as the platform is supporting such feature, but I couldn't find anything about making them glossy.
Is it possible in either awt or just swing to give frame or a panel a metallic look?
I know this might be a horrible idea from cross platform point of view, but I wanted to know if it's possible somehow without resorting to some third party libraries?
I have found a button gloss example here:
http://www.andygibson.net/blog/tutorial/glass-button-tutorial-in-java/
But it is not exactly a metallic look and if I replicate the method to use rectangles instead of circles it may scale poorly.
I've been looking at JavaFX but it seems to be a massive multipurpose package - an overkill if I just want one eyecandy.
note - if you give a minus, be so kind to explain why - else its just being a jerk. I see nothing wrong with this post and I did indicate what I looked at. From what I see I've fulfilled all formal requirements and this is not a subjective type of question.
What your requesting can only be handled by calling the Windows native API. You'd have to cooperate with the Windows DWM (Desktop Windows Manager) facility. Typically it's handled by calling the DwmExtendFrameIntoClientArea function.
Long time ago, I tried to mimic the glass (AKA Aero/Frost) effect using Swing. It was partially possible. One can easily write drawing code which handles this (and surprisingly even quite performant), providing that the drawing happens on the Java side.
That was possible with Swing (see Glass effect for internal panes) and should be even simpler with JavaFX.
However, to handle your precise request - the windows borders - one has to use the native WinApi. From my little research, I only found that SWT does this in limited way (but doesn't expose as publically accessible methods).
I tried to call the Windows Shell API through the JNA project. I successfully managed to change the glass area, but the effect was unpleasant: the Swing wasn't really well prepared (~JDK 7u5) to handle partially transparent JFrames. I remember, that the JFrame code, during a repaint, was clearing the Window using some color. I had to forcefully change it to other one (which matched the one I specified by calling the Windows API), but ended up in a visual mess.
I tried to debug it and I found that certain versions of Java have different code to clear the JFrame's content. So, even if I managed to correctly set the wanted color, it could easily break with the JDK update.
I just wanted to know if there are Java libraries that allow for smooth transitions between Java Swing Containers.
Suppose I have a Java GUI application with a single JFrame. Based upon user actions I would like to change the JPanel contained in my JFrame. Now, this I can do. However this change is instantaneous. What I would like to do is have a slow transition/animation so that it is not too hard on the users cognition.
Concrete Example:
Say the JFrame I have isframe having 2 buttons and I have two JPanel, panel1 and panel2. Depending on which button the user clicked, I would replace the frame with either panel1 or panel2. However I would like this change to be slow/animated (whatever you call it), a fade-in effect per se. So my question is
Is there some Java library that allows for such transitions?
If not, are there other desktop development language(s) that I can use for such transition. I already know of Javascript frameworks like JQuery that allow for this. But, I am looking for desktop development (if not Java then anything else is also fine).
Something like that?
I had the same need: smooth transitions and animations of components, panels and screens in my app, to create a fancy UI. Since I once made an animation engine (Universal Tween Engine) for java, I quickly setup a very small and easy-to-use library to create such animations in swing UIs, the SlidingLayout library.
If that's what you're looking for, there is a dedicated forum in case you need help to setup the lib in your project.
I can think of two animation libraries that would be capable of producing the effect you're after, but you'll have to do the work of getting the transition to actually work
TimingFramework
Trident
You should also check out:
http://weblogs.java.net/blog/kirillcool/archive/2007/04/who_doesnt_want.html
For a possible implementation
I'd also suggest checking out http://filthyrichclients.org/ for further insights
I want to make an application which will have the following:
a jframe (or frame, or whatever) with some java style menus (Jmenu) on the side, and on the other side of the jframe, a OpenGL canvas (which only occupies part of the jframe) and let them integrate together.
meaning, for example, I want to change a slide, and it will change the view of the opengl.
Is it even possible to embed an OpenGL inside a Jframe?
Also, a recomandation for an opengl library that would support such thing. I played a bit with JOGL, but also saw that there are other open-source, and also LWGL and stuff
EDIT:
Added an image from a project made with JOGL which is exactly what I'm after.
A canvas of JOGL inside a Java GUI
for hight Graphics performance is required to use AWT Component exclusively,
I'd suggesting not mixing AWT with Swing
maybe JOGL could be right way, maybe not
I have a Windows Mobile application written in Java that uses AWT for the user interface. I am looking at porting the UI to SWT. I got a hold of the SWT libraries for windows mobile and I started looking at what work will be involved in actually porting it over. I think the first thing I have to decide is how to handle a large number of screens in the application.
In AWT the UI is basically a single java.awt.Frame with CardLayout. Each screen is then just an extension of java.awt.Panel, and is added to the Frame. Then whenever we need to change to a different screen we just set that panel to the top-most.
SWT doesn't have such a layout manager (and I'm not even sure if that is the best/most efficient way of doing it anyway, since the system resources associated with every screen in the application are always held). One way I thought of doing it was that each screen would be its own org.eclipse.swt.widgets.Shell. Switching from one screen to another would involve a display manager class creating the new screen (shell) and disposing of the old one (not sure of the performance hit here of creating the shell and all of the widgets every time the screen is shown?). I am not sure though if having multiple shells in one mobile application is a good idea??
Does anyone have any suggestions on the best way to handle multiple screens in a mobile application using SWT? Is there an equivalent to the method we are currently using in AWT, i.e. CardLayout? Or am I right in thinking that this is not really the best way of doing it, given the use of resources for every screen, even if they are not being displayed?
So the answer to my own question seems to be that there is in fact a StackLayout in SWT, which is pretty much identical to CardLayout in AWT. So I can use that and the job of porting from one to the other is pretty easy because they act in the same way.
Not sure how it would play out in Windows Mobile, but MigLayout is a great layout manager for SWT, which may support the kind of layout you describe.
Check out its demos.