This question already has answers here:
How to use JavaFX Preloader with stand-alone application in Eclipse?
(2 answers)
Closed 7 years ago.
I was wondering what are the specific differences between preloader and splash screen in java. It seems to me that both the features gives the same output (i.e. holding the attention of the end user while loading the main application) but have different technique and system to implement.
Theoretically the specific differences between them would help a lot. TIA.
Assuming that you are talking about JavaFx ... this document from Oracle states that:
Initially there is a splash screen; so that would be the very first panel shown to the user; right after startup; to let him know that something is going on
And then some time later, the JavaFx is turning into "preparation" mode ... including the "preload" stuff
Of course, depending on your context; there might be other definitions. Back in the good old days of AWT or Swing; one would implement a splash screen completely by himself (and for example try to only use AWT components to do that; to avoid the noticeable delay that kicks in when using Swing components to achieve the very same thing).
Related
Java programs start slowly.
I program a JavaFX desktop software. When I double click the executable jar, it costs nearly 5 seconds to show the window. I think the JVM spends a little time to load the class.
But when I open Eclipse, the progress GUI is showed immediately. How can I do that like Eclipse? Does it use other technology to show the GUI without JVM?
The 'eclipse' executable is actually a small C program (source code is here).
This reads the eclipse.ini, displays the splash screen if it is specified and then initializes the JVM using the parameters specified in the eclipse.ini and starts the main Eclipse Java code. So the JVM initialization and Java startup is done with the splash screen already displayed.
The Java code is given a reference to the splash window so it can update the progress and close the window when done.
If you write an Eclipse RCP the same code is used to start your RCP.
The secret is: which classes are used to display that "splash screen"?!
Guessing here: the eclipse people have fine-tuned that code. It might be possible that they use AWT only components there. Well, I stay corrected: they are not using java at all for the splash screen (see the other answer). No surprise.
Beyond that, anecdotal answer on splashing with Java: many years ago I wrote a Swing application. Of course, the customer wanted a nice splash screen, with the company logo and a progress bar; showing the amount of loaded "modules". I coded the first version using swing panels. That panel came up after 15 seconds (no SSDs back then), and 3 seconds later, 100% were reached. Solution back then: I wrote a new version that went with a minimal number of AWT components. In the end, that splash screen looked a little bid "less nice" - but it came up after say 3, 5 seconds.
I think I even tampered with class loading order to ensure that all "expensive" classes were loaded after I pulled the stuff required to show the splash screen.
( and in case this doesn't result in "enough delay" between "splash showing up" and "application fully loaded" ... one could simply extend the "life time" of the splash screen by simply having it sit there a bit longer. sure, you don't tell the customer about that ;-)
I was reading through the java docs and found that it is easy to make a shaped windows, making them translucent and coloured as long as the platform is supporting such feature, but I couldn't find anything about making them glossy.
Is it possible in either awt or just swing to give frame or a panel a metallic look?
I know this might be a horrible idea from cross platform point of view, but I wanted to know if it's possible somehow without resorting to some third party libraries?
I have found a button gloss example here:
http://www.andygibson.net/blog/tutorial/glass-button-tutorial-in-java/
But it is not exactly a metallic look and if I replicate the method to use rectangles instead of circles it may scale poorly.
I've been looking at JavaFX but it seems to be a massive multipurpose package - an overkill if I just want one eyecandy.
note - if you give a minus, be so kind to explain why - else its just being a jerk. I see nothing wrong with this post and I did indicate what I looked at. From what I see I've fulfilled all formal requirements and this is not a subjective type of question.
What your requesting can only be handled by calling the Windows native API. You'd have to cooperate with the Windows DWM (Desktop Windows Manager) facility. Typically it's handled by calling the DwmExtendFrameIntoClientArea function.
Long time ago, I tried to mimic the glass (AKA Aero/Frost) effect using Swing. It was partially possible. One can easily write drawing code which handles this (and surprisingly even quite performant), providing that the drawing happens on the Java side.
That was possible with Swing (see Glass effect for internal panes) and should be even simpler with JavaFX.
However, to handle your precise request - the windows borders - one has to use the native WinApi. From my little research, I only found that SWT does this in limited way (but doesn't expose as publically accessible methods).
I tried to call the Windows Shell API through the JNA project. I successfully managed to change the glass area, but the effect was unpleasant: the Swing wasn't really well prepared (~JDK 7u5) to handle partially transparent JFrames. I remember, that the JFrame code, during a repaint, was clearing the Window using some color. I had to forcefully change it to other one (which matched the one I specified by calling the Windows API), but ended up in a visual mess.
I tried to debug it and I found that certain versions of Java have different code to clear the JFrame's content. So, even if I managed to correctly set the wanted color, it could easily break with the JDK update.
This question already has answers here:
Show JFrame in a specific screen in dual monitor configuration
(12 answers)
Closed 8 years ago.
I work on a java application . When I tried to connect an external monitor to my laptop (to use it in extend screen mode) and tried to run the application from the extended monitor it still opens the application on my laptop window and not on the extended window. I am not really sure if I need to add a java code for this or is it something to do with Windows options. Basically everything , the error popups and everything come on the laptop window and not on the extended screen . Is there a way out to ensure the application and its popups come on the correct screen?
The position of windows on the monitors can be set by code.
If you use two monitors with extended desktop, you have to use positions, that match the second monitor.
Simple example:
You have two monitors, each with a resolution of 100x100 (for the sake of demonstration).
If you use the extended desktop, your desktop is of 200x100.
You need to set the windows x coordinate to be above 100 to be on the second monitor.
But be aware: If you switch back to only one monitor, the window will still be places at e.g. 150 and will be offscreen then.
This question already has answers here:
Why is it frowned upon to use a null layout in Swing?
(4 answers)
Closed 8 years ago.
Bonjour.
Upon spending countless hours around this site looking for code to drag a component around the screen, I noticed an odd trend growing in the answers.
...being that everyone shudders at the sound of the null layout.
So I ask, what's the problem everyone has with it? I've been coding for no more than three months, using Swing for no more than one, and the layout has been a breeze to use with endless customisation possible. Why is it bad practice?
The major problem is the complexities involved in trying to make determination about individual platforms with regards to things like fonts and how pixels may be rendered
Even two systems, running the same OS can generate different output due to different hardware drivers and rendering pipelines.
Much of the API has been abstracted in such away that you should never care that one PC is using a DPI of 120 and using DirectX and another is using a DPI of 92 and using OpenGL.
Layout managers remove the developer from the responsibility of having to calculate the size a component (and its child components) at a particular moment in time as well as calculating the relationship between these components and does it in a standardised way.
The core Swing API has been designed to utilise this API, so when a component changes in some way that would represent a change in the size, all the required containers are notified automatically and the entire hierarchy of components can be adjusted as required.
The basic idea of a layout manager is to describe the relation between components on the same container as well as providing information about how much that container might like to have. This allows you to focus on the user-ability follow of the UI rather then trying to spend time trying to update the UI to meet all various possible combinations of hardware and software.
As a former VB developer (no, I'm not proud if it), I can assure you, the most frustrating part of working with it was trying to develop usable, dynamic UIs that didn't look crap on the next clients machine.
Of all the aspects of Swing, the layout management is one of the most welcomed - IMHO
Because it's not a layout. All you are doing is using a GUI editor to place your components in absolute locations. And resizing your window or running your code under a different monitor resolution will look terrible.
looking for code to drag a component around the screen
That is a different requirement. By definition when you drag a component around the screen you can't program the location.
Having said that a layout manager does more then just set the location of a component. Check out Drag Layout for a layout that you can still use in this situation.
For other situations a layout manager (or combination of nested layout managers) if the better solution for designing effective GUI's.
You will loose some points for GUI for using it, because it's hard to maintain, more code, less flexible,... Adding an extra button will lead to a lot of recalculation you have to do.
How i see it : http://leepoint.net/notes-java/GUI/layouts/nulllayout.html
I've seen other answers and hacks around to this question, but none seem to do exactly what I'm after.
Essentially, I'm after a JWindow whose background is translucent but the content of the window itself (buttons, text and so on) are opaque. The methods I've seen so far fall into one of two categories:
Taking screenshots from behind the window and using them (http://onjava.com/pub/a/onjava/excerpt/swinghks_hack41/index.html) - this isn't much good in this scenario since it's too slow, I want to be able to put things like video behind the window and have it show through
Making the whole window translucent (including the components on it which I need to remain opaque.)
Is what I'm asking for possible, and if so how would it be done? If not, will Java 7 provide any methods that would make this easier / possible? I know it's got more support built in for shaped windows so I wonder whether something there could take care of this also. I've been searching around for a while now but with no luck.
Can only be done if you are using JDK 6 update 10 and above. Must also support hardware acceleration. See
http://download.oracle.com/javase/tutorial/uiswing/misc/trans_shaped_windows.html