I know why these components are called heavyweight components. What I'm really interested in is why they were not implemented as lightweight. Thanks
These components are windows of different kind. If you want to create a window in the operationg system you need to call some OS native code, because there is no way to do it in Java. More than that, all the user input events (mouse, keyboard, etc) are dispatched by the OS to the appropriate OS window. Java components listen to these events in the native code and send them to the java level via JNI. To sum up: it is just impossible to do them lightweight.
Related
I code in java. I wrote a keylistener for the frame and it prints all the keystrokes when the frame is active, but when i minimize it or deactivate it, the program obviously stops and no keystrokes are printed. I wanted to make a small game where i enter a key and using the robot class, it presses another set of keys but this game is in flash. any idea as to how i would capture keystrokes when window is deactivated.
edit: I only code in java so is it possible using only java or at most combining it with native machine... i use windows
By its nature, Java is sandboxed by the JVM, so you will have to incorporate some kind of native methods. There already exists a very flexible and helpful library to accomplish this under open source, called JNativeHook. It's very easy to hook in, especially if you're already familiar with Swing event handlers. Same basic concept, except it leverages native code written in C. It supports all of the basic operating systems (Windows, Mac, *Nix).
JFrame is Extending Frame. Then, How JFrame is lightweight but Frame is heavyweight?
I red this article but still i didn't get how JFrame achieves its lightweight property?
I got from here that JFrame is heavyweight but other Components starts with J* are lightweight. How other Swing components achieves this. I need bit of technical details.
Technically it's not. Both are heavy weight components, but because JFrame has been setup to support the JRootPane, which contains the content pane (and possibly) the glass pane (as well as the JMenuBar), it is consider "light weight", because it's been deliberately configured to support light weight components
Essentially JFrame and JWindow have been modified as light weight containers that support light weight components
it is still a heavyweight component because it(JFrame) inherits from the Frame.And it is not belong to the JComponents which is lightweight components.
Heavyweight means each Java component has a native peer associated with it. A native peer is an OS-specific component... AWT is heavyweight, so if you create a AWT Button, on the Windows platform an MFC button is created, on *nix a Motif button is created, etc.
Lightweight means that there is not a native peer associated with the java component. This is done by having only the top-level component be heavyweight and all the lightweight components are drawn on to it. Swing is lightweight.
Of course, AWT and Swing are specific to standard Java (J2SE). Under J2ME it depends on what sort of device you are using. If you are using a more powerful device, like the Sharp Zaurus, then you have AWT and functionality pretty close to J2SE levels. If you have something like a Java-Enabled cell phone, you don't have all the capabilites that you need for a fully featured GUI, so there are special libraries used for making these applications. You'd need to look at the APIs provided by the device manufacturer most probably.
JFrames are heavyweight, since it's impossible to create a task-view-level window in most OS without creating a "heavy" AWT window. Lightweight components can replace internal widgets with java-based stuff that doesn't require JNI calls, but windows are the special case. JFrame does let you do custom renders, though. Also, if you're using other lightweight stuff, then I suggest using JFrame as well since it makes the rendering more efficient overall than mixing light and heavy components.
It is still a heavyweight component because it(JFrame) inherits from the Frame. And it is not belong to the JComponents which is lightweight components.
Multi-window applications often have a main-window, and all other windows are kind of 'parented' to it. Minimizing such a sub-window will hide its content and show the title-bar at the bottom-left of the screen. Also, these windows do not have their own Icon in the Task-bar, only the main-window does.
How can I make a window being attached this way to another window?
If that is possible, is it also possible without a referenfe to the actual main window?
#2: I'm embedding Java into such an application and I would like to be able to use awt or swing additionally to the native dialogs, which have this behavior by default.
See How to Use Internal Frames.
have look at JInternalFrames for MDI application
read Oracle tutorial, try code example
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.
How can I disable OS-level keyboard shortcuts (e.g. Alt-Tab, Ctrl-Alt-Left/Right, etc.) on a [Ubuntu] Linux machine? I'm developing a full-screen Java Swing app and don't want the user to be able to task switch away from the program arbitrarily. It's not enough to toggle the "always on top" flag; users mustn't be allowed to switch workspaces, migrate focus or any other such things. The machine must function normally before and after the application is executed. Google says that this will require JNI or JNA but I'm looking for a bit more hand-holding.
There's no point in trying to do this in your application because any of these changes are going to need to be handled by X11 and/or the window manager since those are what respond to the commands. Assuming that you have control of the platform, choose a window manager which supports a kiosk mode. Then use the window manager's settings to start your application and enter kiosk mode.
Options for window managers which can do this include KDE or twm-kiosk.
(And if you don't have control of the platform, you're not likely to be able to have your application intercept things like ctrl-alt-backspace anyway.)
Edit:
In response to a scaled-down version of the question in which he's willing to let things like ctl-alt-backspace go and just wants most of the keys including alt-tab or other similar application switching key combinations, the following should work:
You should be able to do this using XLib's XGrabKeyboard method through JNI. This Java/XLib JNI keypress capture tutorial should be a good starting point. However, it uses XGrabKey which just passively listens for keys and does not prevent other applications from receiving them. You'll instead want to use XGrabKeyboard which actively snags all of the normal keyboard events (which, if the premise of this StackOverflow question is correct, includes the task switching keys).
Note that as a side-effect, key capture in Swing will also probably stop working because your Swing windows are going to be separate from the window you create in C. As such, you will probably have to use your JNI interface to get key presses to your program when needed. (Although I would definitely advise testing it first before writing the code.) You might be able to avoid this if you can get the window using Java AWT Native Interface to get the window ID. (Note that Swing is built on top of AWT, so this will work for Swing.) However, I'm not sure how to do this. It looks like you might be able to navigate the window tree by getting the root window from the Display and going from there to find your Window, but it's all kind of weird. It would be nice if the AWT NI just told you the window ID, but it doesn't look like it does that.
As this warning Reminder: XGrabKeyboard is not a security interface notes, this doesn't make it impossible for other programs to see the keys, but it seems likely that window managers will not be using XQueryKeyMap so it is likely to prevent task switching.