I use ubuntu 10.04, but have discovered this on other ubuntu distributions as well.
When I start the first JFrame of an application, it won't start in its default size (specified by setSize()), but instead is maximized all over the screen.
I have one workaround for this, which is to use setResizable(false) (which brings the
window to its intended size), then I set it back to true (I still want to be able to resize).
Anybody knows where this bug is from? Is there any elegant way to deal with this?
Thanks,
It is a window manager preference. Either disable it in ubuntu or modify your program live with users wanting to resize your program.
To disable (from ubuntu forum post):
Open System->Preferences->Startup-Apps
Find the entry for 'Maximus' and uncheck it
Logout/login
Related
Hi I'm working on a group project and the code works on my teammate's PCs but I keep hitting MacOS specific errors. And this time I seem to be stuck (no easily Googleable answer).
In a previous post I discovered I need "-Djava.awt.headless=true" as VM setting to properly run my simulation. Now when I try to spawn in some JFrame they are all met with a lovely "java.awt.HeadlessException" Exception because of that VM flag.
Trying to achieve
I want to be able to spawn those JFrames on my MacBook also.
The problem
I need -Djava.awt.headless to be both true and false at the same time for my program to run properly on Mac. Which if I understand my problem correcly, means I have a big problem on my hands.
EDIT: running it in a VM on my Macbook allowed me to run the project properly. This is far from an ideal fix. I'm still searching for a solution to this obscure problem.
What I tried
not running with the VM option: the problem described in previous post occurs. Thus this is not a viable option
running with the VM option: this throws a -Djava.awt.headless when creating a JFrame.
The best way to fix this may be by going back and solving your original problem a different way.
You must make sure that you are not initializing your BufferedImage in the main thread (GLFW thread), it MUST be done separately. It is hard to tell from your original question, but that looks like part of the cause there. Start a new thread to do the image processing instead.
See my solution and recommendation at the bottom of this answer for a quick summary, and also see here for someone else that had the same issue: Java Creating Instance of BufferedImage Freezes Program
A quick note on why your code works on Windows and not Mac: that is because both OS often run different implementations of openGL, and typically Mac can lag behind and miss out on a bunch of updates/changes that may solve problems like this one so that it doesn’t freeze when initializing a BufferedImage on the openGL thread.
If the above didn’t work then lets first look at what headless mode is. (Emphasis mine):
See link at bottom for full article and more info.
Headless mode is a system configuration in which the display device,
keyboard, or mouse is lacking. Sounds unexpected, but actually you can
perform different operations in this mode, even with graphic data.
Where it is applicable? Let's say that your application repeatedly generates a certain image, for example, a graphical authorization code
that must be changed every time a user logs in to the system. When
creating an image, your application needs neither the display nor the
keyboard. Let's assume now that you have a mainframe or dedicated
server on your project that has no display device, keyboard, or mouse.
The ideal decision is to use this environment's substantial computing
power for the visual as well as the nonvisual features. An image
that was generated in the headless mode system then can be passed to
the headful system for further rendering.
So when should headless mode be used:
On a machine that has no display device, keyboard, or mouse.
That is not you is it? However if that is you (LWJGL?), then lets look at how you can work with headless mode:
An image that was generated in the headless mode system then can be
passed to the headful system for further rendering.
This means that you should have a special piece of headless code that does your headless image stuff, but then passes the image back to a normal JFrame with a head.
So why does it fail for you:
Many components are affected if a display device, keyboard, or mouse
is not supported. An appropriate class constructor throws a
HeadlessException
Button
Checkbox
Choice
Dialog
FileDialog
Frame
Label
List
Menu
MenuBar
MenuItem
PopupMenu
Scrollbar
ScrollPane
TextArea
TextField
Window
Solution to the problem:
some classes, such as Canvas or Panel, can be executed in headless mode.
Perfect, so we just need to be careful what is used in headless mode. You asked how you can both use and not use headless mode, well rather than globally setting headless mode with VM option -Djava.awt.headless you can do it programmatically within your code using System.setProperty("java.awt.headless", "true"); where needed. A JFrame should be normal (not Headless), but you can spawn a JPanel as headless without issue.
I recommend:
You create a normal headed main thread with no VM option that spawns JFrames, and then use that main thread to spawn a new child thread and set your LWJGL bits in that thread to be headless, and that way you can run your LWJGL code without issue, and at the same time you can still have JFrames from your main thread. Remember to make sure that the Buffered image is not done in the main LWJGL/OpenGL thread.
Headless info source:
http://www.oracle.com/technetwork/articles/javase/headless-136834.html
On windows, my LWJGL application is able to be maximized, as shown here:
Maximization allowed http://img28.imageshack.us/img28/8428/maximize.png
However, the same application on Mac does not allow you to maximize the display, as shown here:
http://img805.imageshack.us/img805/6653/maximization.png
Is there a line of code that I am missing?
I am able to re-size the window manually to fit the whole screen, however, it would be nice to know if it would be possible to enable the maximize button for the sake of ease.
One try would be to use the nightly builds of LWJGL found here:
https://www.newdawnsoftware.com/jenkins/view/LWJGL/job/LWJGL/
If you aren't using it already. It contains many fixes and additions, maybe even for this problem.
Otherwise the changelog from 2.8.3 just states that it got added and there is no line of code manipulating it. Do you have the same version of LWJGL on your mac?
Is there any option which i can use to Control Window State of another App. from a Java Application .
Like if i need to minimize or maximize another app. window on Ubuntu Enviroment (if it's matter's im using Gnome Window Manager).
Bests
Two bad options:
1) use java.awt.Robot to click the appropriate coordinates where the window is. (You have to hard code these)
2) use jni
I'm having trouble with my SWT application where the shells/dialogs always open underneath other windows by default ("pop-under"). if I set the SWT.ON_TOP bit, the window opens properly on top, but then I block other applications, which isn't really desirable either...
I'm wondering if there's a proper way to specify that I want the window to pop-up, rather then underneath other applications.
Thanks!
I think this question is a duplicate of this SO question. What's your SWT version? It should be resolved in the latest version, as is explained there. Also see this bug report at Eclipse.org.
This is driving me crazy. When I set an appropriate size for my window in design-mode it just ignores this size and uses something else when I compile and run. Even tough I set the minimumSize and preferredSize it just ignores this... Why? How can I set my own size?
Even if you've set the size with minimumSize and preferredSize, you might have forgotten to call Window.pack() in which Swing will resize the components (and all of it's subcomponents) according to the sizes set.
You call it in your window (or whatever is building your window) after all the preferred sizes are set.
Alternatively you can use the Component.setSize() method but it comes with some caveats.
Have you checked if you really set the size of the JFrame or of a contained JPanel?
Have you tried setSize?
I've found myself in a similar situation while using netbeans ide. I had a read of the following thread, that helped:
http://forums.netbeans.org/ptopic28011.html
Seems as though the swing application framework is saving the app's window size in a subfolder within your home dir (for Windows, the "Application Data" folder, for Linux, in your "~/" home folder).
For example, for my application 'CrapApp', swing had saved some last-window-size info into the sub-folder "~/.CrapApp/", into a file called "mainFrame.session.xml".
So no matter how I re-sized the window within the designer, upon running, it seemed to have ignored it and instead loaded the window size from the preferences within this sub-folder.
So my solution was to delete this preserved-settings sub-folder, eg, in my case, "rm -rf ~/.CrapApp/"
Then the problem went away and I could re-size within the designer and run the app with this re-sized window now visible.
This made me want to learn what triggered this issue. I noticed that simply running the app within the netbeans ide and closing it didn't generate the sub-folder.
After a bit of tinkering with my app, I noticed the following action triggered the generation of this "~/.CrapApp/" sub-folder.
Going to my app's "Help >> About"
Click the "Close" button in the about dialog that appears
Exit the app
And now the "~/.CrapApp/" sub-folder re-appears. This help/about dialog was auto-generated by netbeans ide, so I didn't really tinker with it, but this seems to have been the culprit in my case.
Perhaps it may be a bug in the netbeans ide, I'm using a somewhat old version (v6.8), which seems roughly from the era of your original post too.