Some swing code I write in my computer behave different on my colleague's computer, and in my PC, and in my notebook.
I wonder, is there something I can do to my Swing applications behave the same in every computer?
I want to have sure a algorithm I've tested in my computer will work the same way in my clients computers.
E.g.
Problem to focus JTextField works fine in my notebook with Windows XP, but not in my collague's computer with Windows XP, nither in my work computer with Ubuntu.
obs. the specific JTextField problem is not the subject of this question.
Problems with Swing apps on different platforms are common and they are caused by the simple fact that no matter what level of abstraction Java offers it has to play ball at some point with the native components of the underlying operating system. Event though Swing only uses the windows(frame) and draw everything by itself - discrepancies are very very common.
I develop a mutliplatform Swing application - and users on Windows are reporting all sorts of issues that Linux users don't have and vice versa. Sadly there is no silver bullet for such problems - extensive testing and nasty fixes are the only game in town.
And everything come exceptionally buggy and dirty in the area of pluggable look and feels. For example - resizing a JSplitPane with metal or nimbus is super fast(as expected), but if you use GTK+ plaf, everything goes to hell. This is a more serious(performance) problem - visual problems(missing borders, components not fitting properly containers, etc) have no end... Despite all of this Swing continues to be one of the best bet for multiplatform desktop applications.
I wonder, is there something I can do
to my Swing applications behave the
same in every computer?
I'm working on a complex Java Swing app that is shipped on OS X / Windows / Linux so just like Bozhidar answered, the issues are all far too real.
For some components, if you happen to have some UI design/programming skills, you can simply write your own component: I realize it's probably not a helpful answer, but it works.
For example, we wanted a drop-down "find-as-you-type" popup list (like the one that appears when you start a search on Google's main search page) that would look and work the same on Linux/Windows/OS X. After trying countless of "solutions" full of Swing idiosynchrasies that would not work everywhere (like, guess what, focus issues ; ) we decided to simply write our own component "from scractch".
We can intercept mouse and keyboard events on both OS X / Windows / Linux: we can write a component that not only looks but also behaves identically on all three platforms.
In addition to the "find-as-you-type", we also wrote our own tooltip-popup component, a dual progress bar (to progress bar in one to show producer/consumer style progress in a single bar) and a complex component involving several "text fields" which was absurdly complex and broken when we tried to do it using Swing (and broken in different ways on different platforms, like weird focus issues or caret not showing, etc.). So we "went dirty" and rewrote the entire component ourselves.
Result? Working identically on all platforms where Java can give you notifications about mouse and keyboard events...
I realize this may not be what you want to hear: I happen to have worked on both games UI and mobile apps UI back in the days and I have some graphic skills so it's not "hard" for me to write good looking UI components.
Sadly if you want some Java UI component to look and behave identically on all platforms, it's sometimes your only alternative...
I want to have sure a algorithm I've
tested in my computer will work the
same way in my clients computers
An "algorithm" should work fine.
You get problems when you rely on the ordering of events, which may be different on various platforms. One of the most common I know about is holding down a key so that is repeats:
a) on Windows you get keyPressed, keyPressed, keyPressed, .... keyReleased.
b) on Unix you get keyPressed, keyReleased, keyPressed, keyReleased ...
By the way a comment would be nice as to whether my suggestion in your "textfield" posting works or not. As I mentioned, I don't have a Ubuntu platform to test it on, so I'm curious as to the result.
Related
In this page the CheerpJ conversion of the applet in this page (with identical byte-code) does not seem to recognize mouse dragging past the applet frame boundary. It would be nice if that were possible.
Is this just a problem with my client-side setup (Linux Debian 9.2), or do others see the same behvior?
What is very strange, is that the original behavior is converted correctly on the not-supported-by-CheerpJ iphone browsers (I have checked safari and firefox there). Could investigation of this fact help CheerpJ developers understand how to make the MouseMotionListener interface recognize mouse dragging anywhere on the screen, not just within the applet frame?
Maybe this is impossible, but I thought it was worth asking.
Edit: Changed title to be less negative about CheerpJ (which overall I find almost too cool to be true!) and more reflective of actual the question.
The mouseDragged method is correctly implemented to the best of our understanding. The Java event is derived from the mousemove JavaScript event which is not delivered when the mouse is outside of the applet surface. With the legacy plugin applets are displayed on native windows which have different behavior.
It could be possible that using different JavaScript events, like mousedrag would make CheerpJ behavior more similar to native, but reworking this without causing regressions would require significant work and it is not currently a priority for us. Especially considering that our customers normally have full screen Swing applets which cannot exhibit the problem
On mobile devices the touchmove event is used, which is probably what causes the difference you see.
If you want to report a bug you can do it here: https://github.com/leaningtech/cheerpj-meta/issues
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.
I developed a Java application in Netbeans, and I'm going to release it soon so I'm working on making it less ugly. Since I'm developing on a Mac, the GUI builder uses the Mac Look & Feel, which looks decent, but many of my users won't be using Macs. The default L&F is Nimbus, which looks fine except for the buttons, which have annoying borders that are not overridden by the manually setting the borders (you can see how the manual borders look in the image). With the manually set borders, the Nimbus L&F adds its own odd border inside the border I made, which just looks idiotic. Without the manually set borders, Nimbus's borders overlap in visually unappealing ways, and in order to avoid overlap I have to space the buttons really far apart, which I also don't like.
I tried using the other L&Fs available in Netbeans (Metal and something else), but they're just too ugly to stand.
Basically, I would like some advice on how to customize the way buttons look in this application. I don't want to write a button drawing function from scratch or design my own images. I just want a way to change the settings so things don't look stupid. I read in various places that the Substance L&F is good, but I can't find where to download it anywhere. If someone could link me to a download page for Substance or recommend another popular, simple and not stupid-looking L&F, I would greatly appreciate it.
Yeah pretty much all the L&Fs you'll find in Netbeans are worse than the default. The program will use the default Look & Feel of the operating system - so if it's being run on Windows it will have the "Windows-esce" buttons and fonts and on Mac will have the Mac style.
It all depends on what you're looking for. If you're application is meant to be professional and you don't mind it having different styles depending on the OS of the user then I'd leave it as default. It lends familiarity to your program which can truly make the user feel much more comfortable.
If you're after an indetical look for all users then, as you know, you just need to include the L&F with your program. I couldn't find a download for Substance but there are a few L&F's here - both commercial and free.
http://www.java2s.com/Product/Java/Swing/Look-And-Feel-LaF.htm
I want to be able to record mouse movements, clicks and keyboard input from a user. It would be great if it was a cross platform solution.
I'd like to get back something like this (pseudo code):
mouse moved to 500, 500
mouse double clicked
mouse moved to 800, 300
mouse left clicked
keyboard typed "Hello World"
Does either C++ or Java have any classes that can do this? If I was using C++, I would probably working with the QT framework.
Edit:
I should have said this originally, but I want to record the movements and clicks outside of the applications gui, so on the desktop too.
GLUT does this, but it's tied to OpenGL which might be overkill for your project.
OpenGL is cross-platform.
I don't believe there's a cross-platform toolkit specifically for grabbing input from a window and nothing more, but most toolkits provide this capability. Two good options are:
Use SDL, as it's fairly lightweight and can handle simple input.
Implement the functionality natively per platform, as it should be trivial in X11, Windows, Mac OS X, etc.
On Windows, this is called a Journal Record Hook. You should write the hook part in C or C++, it might be technically possible to do in java, but it's not a good idea, you want your hook procedure to have as few dependencies as possible, and to be a quick as possible. System wide hooks, especially journal add a lot of overhead to keyboard and mouse input, you want to minized your impact as much as possible.
You Install Windows hooks by using SetWindowsHookEx passing WH_JOURNALRECORD to get a Journal Record Hook.
You could also (maybe) get this working by installing both WH_KEYBOARD_LL and WH_MOUSE_LL, but your two hook procedures would be called separately, and you would have to write your own code to put the events in order.
I doubt you will find a cross-platform solution.
It sounds like Qt might allow you to implement event filters that extend beyond the application to the window system. See also Qt - top level widget with keyboard and mouse event transparency?
If you want to trap events across the whole GUI system, not just one app, there's not much likelihood of a cross platform solution. However, the event hooking part could easily be separated from the recording part, so you could make most of the program cross-platform.
For Windows, you need this 17 year old (!) document. (Man, I'm getting old!)
We have a Java Applet built using AWT. This applet lets you select pictures from your hard drive and upload them to a server. The applet includes a scrollable list of pictures, which works fine in Windows, Linux and Mac OS X 10.5. We launch this applet via Java Web Start or within a web page.
Our applet does not behave properly in Mac OS X 10.4, regardless of the version of Java (1.4 or 1.5). You can find a screenshot of the incorrect behaviour, when scrolling, here:
http://www.lavablast.com/tmp/ui_error.png
Simply put, sometimes when scrolling the pictures end up overlapping the header or footer of the application. This behaviour does not occur on other platforms. On Mac OS X 10.4, it shows the pictures in the incorrect location when scrolling, which would not be so bad if it refreshed the screen after painting the image at that location. However, it does not appear that the application knows it painted it incorrectly and thus does not refresh.
If the window is minimized, resized or even moved, the application is refreshed and the incorrectly positioned elements vanish and the application resumes normally. I spent quite some time trying to force a refresh of the background image unsuccessfully. (the repaint the image directly, repaint all children of a few panels, etc. ) Thus, I am looking for any tips that would help me resolve this problem under Mac OS X 10.4 or, in the worst case, simply simulate a full applet refresh.
Until recently, everything was compatible with Java 1.1 but this has changed in a few locations which now require 1.4. I don't feel these changes created the issue, I am just providing this as extra information. If you are interested in implementation details of the scroll panel, I will investigate, but I am assuming this is a common platform bug for which workarounds must be known.
To replicate the problem, open the following Java Web Start application:
http://www.lavablast.com/tmp/opal-webstart.php.jnlp
Select a folder containing lots of images and play with the scrollbar. At some point (fairly quickly), you should get the refresh problem.
Edit: I followed the first suggestion here and replaced all my controls that feature background images with a Swing equivalent and the issue is still there. (Plus, there are numerous other fixes I would need to do to do a complete change). Any other ideas? A simple one line of code that forces a full refresh would be great :)
Edit2: The main thread creates the panels and launches X threads. Using an observer/notifier pattern, the threads complete and notify the main control, which adds a panel to the page. This is done via an EventQueue.invokeLater which, unless I am mistaken, should run on the right thread. The issue is at its most severe when scrolling even if no extra threads are running (as during the loading).
It does look like mixing lightweight (usually Swing) and heavyweight (AWT) components together. Moving to Swing you need to replace every last AWT component Swing equivalents (hint: avoid import java.awt.*).
Threading is often a potential problem for odd bugs. Swing components must always be used on the EDT (use java.awt.EventQueue.invokeLater). AWT is thread-safe is theory, but not in practice - also restrict usage to the EDT.
As you already require Java 1.4 you should consider some small changes to take into use SWING GUI instead, it solved our Applet refresh issues with AWT. (Mac, Linux etc)
If you have e.g. Panel, you need to replace it with JPanel etc.
You need this:
import javax.swing.*;