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?
Related
I have an old .jar file that creates a main window with some textboxes for settings.
The problem is that some textboxes doesn't appear in the window (but they exist), if you lower the computer screen resolution they appear, but with higher resolutions, they disappear.
I tried to decompile the .jar file, but no success...
Since I cannot resize the window in any way (size seems to be fixed), is there a way to force it to be resized or set some Java VM parameters for this purpose?
The loader is "JarRsrcLoader". I attach an image showing the problem in Win10:
(They are not only cut, there are more textboxes).
I asked Mr Google for a Windows tool to make unresizable windows resizeable. Got several matches, here is a short list:
http://www.howtogeek.com/howto/11799/turn-non-resizeable-windows-into-rezieable-windows/
https://www.raymond.cc/blog/how-to-resize-an-unresizable-window-or-dialog-box/
http://www.ghacks.net/2012/06/18/resize-windows-with-fixed-sizes/
I actually found a way to scale the Java application to a lower resolution and see it adequately, only for Linux (but it was what I was searching).
From this source (askubuntu.com): script to fix scaling of java applications.
It provides python scripts to adjust the resolution of certain applications (statically and dynamically) when opened (on a high dpi screen). This solution works for my problem.
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 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.
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.
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.