I would like to create system modal dialog. I mean a dialog that blocks the entire system screen, not a particular application. So far I found Application modality and Toolkit modality that might be replaced even with manual disabling blocked frames, but still no function to lock the entire screen as in a native application. How can I do this?
Well, so far I found the answer:
There is a note on docs.oracle.com:
Note : The new modality model does not implement a system modality,
which blocks all applications (including Java applications) that are
displayed on the desktop while a modal dialog box is active.
As I can see, I just have to seek different way for my task.
Related
Is it possible to ignore an SWT dialog's modality when it is raised?
The issue is that I have an Eclipse RCP application which can be displayed on multiple (8+ screens) at any given time; there can be a single modal dialog raised somewhere on any of the screens (i.e. a user clicks on the Help->About Eclipse page, which displays a modal dialog) which blocks/freezes the rest of the screens until the user finds it and closes it. This is quite problematic as it can be hidden somewhere among a mess of other GUIs.
Ideally it should be possible to interact with the rest of the GUI dialogs even though there is a modal dialog open somewhere. Is this possible?
The cleanest solution is to set the dialog to be non modal (of course) either when setting its style or by invoking the setBlockOnOpen(false); method on the configureShell(...). Unfortunately this is not an option, as the application uses built in eclipse plugins, which are set to modal by default. Is there a way to set it non blocking after it has been opened?
You can also force the modal dialog into the viewport via shell.forceActive(), however this is an ugly solution as it also brings the root swt window into view. If there is a way to just bring forward the modal dialog without its parent, this would be an ok solution.
SWT.shell is quite limited, but maybe there is some other way to mitigate this issue?
I'm trying to create a Window class which I can use to open multiple windows, and which will automatically add an event handler to listen for the Swt.CLOSE event, and call the shell.dispose() method when it is called.
My questions are:
Do I need to listen for shell.dispose() in this case, or to only listen for display.dispose() in my main method?
Do I need to run each window in its own thread, or can all the windows share the same UI thread? I've read some reports of buggy behavior related to event handling in case of multiple windows being open.
I recommend you should always have a single UI thread, which the single Display object runs on. See SWT: single vs. multiple displays or even the Eclipse documentation on Display that strongly recommends using a single Display object:
Applications which are built with SWT will almost always require only a single display. In particular, some platforms which SWT supports will not allow more than one active display.
There are even several sample apps available (such as this one) that demonstrate multiple shells in SWT. Calling shell.dispose() when you want to close a window is the way to go.
You should only use display.dispose() when you are shutting down the entire app, basically as a 'last step' - see this example, or this one, or pretty much any snippet on the SWT Snippets page.
Edit
The Eclipse framework itself is an example of an application that can have multiple windows - it still uses a single Display, with a single UI Thread and shared event system. Eclipse documentation on Threading Issues has a basic explanation of this:
Underneath any GUI application, regardless of its language or UI toolkit, the OS platform detects GUI events and places them in application event queues. [...] It determines which window and application should receive each event and places it in the application's event queue.
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
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.
My Java application sometimes stays at system tray, just like MSN messenger does. I need popup a window to display some formated texts. Sometimes there is more than 1 message entry. I need to display them all.
I am new to jave Swing/GUI.
Anyone has idea or experience on this?
I haven't had the opportunity to work with the Java system tray functionality yet, but you might be interested in reading this overview.
One particular section that appears to describe what you want is this:
Finally, if you wish to casually notify the user of a change in application status using a tooltip from the tray icon, use the displayMessage() method. This method displays a popup message near the tray icon, which will disappear after a time or if the user clicks on it. Clicking on the message may trigger an ActionEvent, depending on the platform.
That sounds like it describes what you want to do, but I'm not sure if there are any limitations on it. With that, the SystemTray and TrayIcon classes might be of interest as well, although I'm guessing that you've read them already.
The system tray functionality in Java 6 allows you to do what you want. Namely have an icon there, which your application can then react to. The functionality to show a message bubble is available.
I have found that the display of multiple individual messages varies a lot between platforms, so I would group them together in a time interval and show them together instead of individual bubbles.
Have a look at http://java.sun.com/developer/technicalArticles/J2SE/Desktop/javase6/systemtray/