I'm having problems with the way SWT child shells behave on different operating systems. On Windows, when I click on the minimize button of a child shell, only that shell will be minimized, i.e. resized/docked in the bottom left corner of the screen (which is the preferred behavior). In Linux, child shells minimize to the taskbar (which is not really a problem). However, in Mac OS X 10.5, minimizing a child shell will cause the parent window to minimize as well (which is a problem).
Child shells are created simply by passing the parent as the constructor argument, e.g.:
Shell editor = new Shell(Display.getCurrent().getActiveShell());
Any help would be much appreciated.
Assumed there is different window management behavior on different platforms which might not be SWT's fault - can you guarantee that getActiveShell always returns the common parent shell?
Another solution is simply to hide the child shells - should work the same on every platform, but might not fit in the context of your application.
Anyway, I see plenty options for replacing multiple child shells. Maybe the TabFolder or the ExpandBar could just be right for the job? Get an overview at the widgets page.
If these options are not possible, you could contact the SWT project. Maybe the developers can help you with the internal workings of the Mac OS implementation. A very radical (and from normal point of view unnecessary) step would be porting over to Swing.
Related
I'm looking for a really simple widget: tree view on the left pane, folder contents on the right, switchable between icons, thumbnails, or detail view. Basically a functional (not pixel for pixel) emulation of Windows File Explorer, but within the Java app. How to do this using only built-in Java libraries? Or a very lightweight framework?
NOT A DUPLICATE
My question is different from the above and I now realize it's a little harder to explain than I initially expected. Two clarifications:
My question is not about a File Chooser. I'm asking about a File Explorer type of dialog. The difference is that a File Chooser is really focused on one task, choosing a file. A File Explorer is a little less focused, and lets the user browse around without a clear objective.
My question is not about native operating system UI / L&F emulation. At all. I'm asking about the basic capability to display the contents of the filesystem using icons and thumbnails. The style and borders etc are not part of my question.
EDIT
I'm looking for something like this
Notice how it's different from this (JFileChooser)
JFileChooser will do that if you are wanting something built in to Java.
https://docs.oracle.com/javase/7/docs/api/javax/swing/JFileChooser.html
If you are not using Swing but SWT (like Eclipse) you can use SWT FileDialog
You could use the AWT library to customly render the entirety of Explorer. Whilst the only hard part about this is correctly using layout managers to get components exactly where you want them and adding event listeners for each button, using AWT wouldn't make it look like Explorer on different operating systems because AWT uses the native system components.
You could check if the OS is not Windows and then use Swing if it isn't. In that case, you'd have to retexture every single used component such that its look and feel is the same as your targeted Windows version. Even if you did that, you'd still have to somehow change the JFrame's look and feel, which is possible using dark magic, but quite obscur. You can do this in a very quirky way, just setUndecorated(true) and manipulate the JFrame's boundaries until it lets you draw outside the JFrame, so that you can draw the Windows' decoration around it without resizing the Window. On top of that, you'd also have to check if it's maximised, as maximized windows don't quite look the same in Windows.
To cut things short, just use JFileChooser if you just want to allow the user to select one or multiple files. There isn't really any point in recreating Explorer, but if that's what you want to do, I'm not stopping you.
I'm developing a JavaFX Application, In here, the outer elements of the JavaFX Window Changes across different Operating System's, i.e. The Position of Close, Minimize and Maximize Window is on left on Mac OS X and on the right in the Windows, Also there Shapes are Different as The OS Changes.
Also if the Application is Running Under OS X, it has drop shadow effect along the boundaries, which in case of Windows is Not Present :
And Want My JavaFX Application to look exactly the Same, Regardless of Operating System, it is Being Run On. How Can i Achieve this ?
Use the undecorator project.
Decorate undecorated JavaFX stages with custom skin. This helper brings a custom look to your JavaFX stages.
See also:
JavaFX entirely customized windows?
I have a modular Java application: a single jar launches a 'control panel', from which the user can open several modules. Each module uses its own jFrame. (A discussion of whether this is a good or bad practice can be found here - in my case the modules all talk to one another but perform different functions).
Running on Windows, each module (jFrame) gets its own icon on the taskbar, and is selectable via ALT-tab. On OS X I only get one dock icon and one icon in the Application Switcher (CMD-tab). This makes it quite awkward to switch between modules, several of which will be open at any one time.
How can I put each module (jFrame) in the OS X dock and Application Switcher separately?
Iterestingly, if I iconise one of the jFrames, it does appear in the dock, in the right-hand area by the Trash.
I am testing this using Java 7 on OS X 10.10 (Yosemite). I have made a cheat's .app which launches the jar via a shell script, in order to provide cmd-line arguments (Xdock:name etc) and icons - so I do have an info.plist file.
You can't. The OS X user interface just doesn't work that way.
Iterestingly, if I iconise one of the jFrames, it does appear in the
dock, in the right-hand area by the Trash.
This is user-configurable. See Preferences > Dock > Minimize windows into application dock.
Rather than fight against the normal OS behavior, come up with your own "module switcher" feature, perhaps making it part of your control panel. You will find that application switching and dock icon behavior differs a lot across operating systems. Trying to make OS X behave like Windows, or vice-versa, outside the bounds of your application will be a big headache.
That said, if you don't want to heed the above advice, the only way I can think of to do what you want is to create dummy applications, that don't display any windows, but that do show up in the dock. The dummy applications can be started by your main application. When a dummy application is clicked, it can then signal your main application (perhaps listening on a local open port) to make one of the modules active. This would give the illusion that each module had its own place in the dock. This would probably work with the Alt-Tab switcher as well.
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.
Hopefully no one has asked this question - didn't see it, but I apologize if it's a duplicate.
Anyway, I'm building some plug-ins with Eclipse RCP and am using SWT for my UI. I have a Composite that contains some panels and other items - anyway, I've noticed a bit of a difference in the appearance of the UI depending on how my OS is set up.
I'm running windows XP but am using the "classic" look/feel which is that of Windows 98. When it's like this - the UI looks fine; however, when I switch to the newer XP look/feel with that tacky blue bar and what not - labels and borders in my composite are different.
Is there a way I can force SWT to use the classic look/feel?
You need a javaw.exe.manifest bound to your application.
Here is an article that describes the problem:
http://www.javalobby.org/forums/thread.jspa?threadID=15414&tstart=0
I think it is a design decision of SWT to make it inherit the platform look and feel. I imagine this is partly to address the usual "java apps look rubbish/out of place/different" comments and partly to make it easier to load the relevant fragments at startup.
I don't know of any way to override the standard values.
Does them being different somehow interfere with the operation of the application? SWT is designed to inherit your user's preference for UI presentation. This is basic HCI - let your user decide what is tacky.