I am a Java developer with some expertise in graphical programming but not very skilled with the most recent techniques.
I am developing a Java graphical application using Apache Netbeans IDE 11.2; the application includes many structured panels (split panels, tab controls) and executes 2D drawings on some of them, using Swing and AWT.
The application worked well until now. After the last modifications, I am facing the following problem:
The application properly performs all drawings (polylines, rectangles and so on) on the main panel, but abruptly the panel is cleared and the original background restored, deleting all drawings.
The debugging shows that the clearing is not performed by any statement of the program. So I suppose that it is managed behind the scenes by AWT or something like this.
I understood that Swing automatically implements double buffering (anyway I also inserted a setDoubleBuffered statement), so I made the drawings directly on the screen without using a buffer. On the other hand, this had worked perfectly until now.
My questions are:
How can I detect the event that causes the causes the restore of the background? And how can I prevent this restore?
A solution could be to disable Swing Double Buffering and code it explicitly. I am not sure of this. Any hint?
Thank you very much for any suggestion.
Related
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.
I'm writing a program that currently switches back and forth between different JPanels placed on a JFrame that also has a JMenuBar. (We're required to use Swing.)
I need to write a tutorial and right now I have it giving step-by-step instructions from a popup window. However, it doesn't seem to resonate well with test users and quite frankly it's annoying to switch back and forth between screens.
After checking out JDesktopPane and JInternalFrame it seems to make sense to place my entire program in a desktop pane and then create the tutorial using an internal frame. I'm worried that this will force me to place my different screens each in an internal frame which is NOT what I want to do. I just want the tutorial to be an internal popup(?) that can be minimized and moved around if necessary.
Am I going about this the correct way or is there a more efficient/practical way to implement the same tutorial popup feature?
I'm not 100% clear on your problem -- is it that your tutorial keeps popping up new windows for each step? I would assume that you wish both the main program and the tutorial to both be in view while the tutorial is running, and if this is so, perhaps the tutorial should reside in a non-modal JDialog, and then you swap tutorial screens via a CardLayout. ... unless I'm mis-reading your requirements and problem.
This question might not seem very technical but, out of curiosity,I want to know that:
How does bare/raw Swing code written by me, turn into a wonderful graphical application?
For example:
Like when we make a JFrame visible, or when we place a JButton on it. Who makes it happen? OS or Java or JVM.
Who makes the colors come up?
What is the process going on behind the scenes?
I ask this maybe because its the first time in my life that I made a RealWorld graphical application and these questions popped up in my mind!
Thanks in advance!
In Swing, all the GUI components are written entirely in Java and are rendered using Java. For example, JButtons would be drawn by Java and not by any internal OS stuff. Thus, Swing components are called "light-weight components" because they are managed and rendered by Java instead of by the OS (or any native widget toolkit).
Note that Java also has a toolkit called AWT. Swing is based on nested and inherited methods from AWT, except that it creates native widgets using the OS.
So at some point, Swing will have to create a window on the screen and draw on it. The magic that actually creates the window is handled by AWT. Notice that JFrame extends from java.awt.Frame which means that although JFrame may be rendered mostly by Java, it is backed by a heavy-weight native OS window.
In short, there's an AWT toolkit, which is the layer that does all the window management and drawing. It is calling native platform specific code inside the JVM. It is also responsible for java2d drawing. It can use accelerated directx or opengl pipelines.
Swing is developed on top of it. Swing actually draws every button and every object with plain java code. The drawing is handled to a current look and feels that decide how to draw components. So you can override their paint methods, and add some extra things without any problems.
Metal and Nimus LaF are 100% java2d drawn, so inside of them you will find things like drawRectangle and drawLine to draw components. Native look and feels, like windows, gtk, access current operating systems theme to draw something that looks similar to native widgets. That is why they do not always look like native applications.
There are also other gui toolkits for java, like SWT, used, for example, in Eclipse. What it is doing, is getting the window from the AWT, and then putting 100% native widgets on it. It is much better integrated with the OS, looks better, works faster, uses less memory. But with it, you'd have to distribute your application with os specific native libraries and it is less customizable, compared to Swing.
I don't know all the details, but the actual graphics are displayed/rendered via the swing/awt packages through the JVM itself.
I have a Java application that run as a background service, i.e. no GUI. But when starting it, say through a batch script, I have some preparation works to be done at the very beginning of my program (something like communicate with server).
I want a busy cursor appear at this busy moment. Is it possible to do this without using any Swing component? Thanks for any suggestion or alternative approach.
I'd go for a console-based "progress bar". It's possible to use Swing but it would render your solution useless in a headless environment. Drawing progress bars with characters in terminal is quite a common practice.
You can either implement it yourself or use a ready class. Just take a look at github or bitbucket and you'll find something for sure.
A busy cursor could even be displayed as a caption with alternating last character (as simple as possible), with "frames" like these (rotating bar)
LOADING DATA /
LOADING DATA |
LOADING DATA \
LOADING DATA -
Implementing something like this wouldn't take much time. We're talking about minutes here.
If the only thing that prevents you from using Swing is an appearing window, you can change its appearance thanks to window translucency. This way you'd get an animated image overlaying your screen. It wouldn't work in a terminal though.
If you're able to use Java AWT (Abstract Window Toolkit) I beleive you can use the setCursor of Component class to change the cursor.
More on this : http://www.roseindia.net/java/example/java/awt/ChangeCursor.shtml
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.