I' m trying to switch windows input language by ALT+SHIFT from Russian to English but it doesn't in java applications. In windows it works fine but when I switch by ALT+TAB to one of java applications it doesn't work. To fix it I have to restart application, for example Itellij IDEA. But after some time it appears again. Can Anybody describe how to fix it?
AFAIK, the default language is decided at start-up, as you experienced. This allows to override the default language using some command line arguments.
I'm afraid, this is how it is. You will have to restart the application to get the changed default language from the OS.
Have a look at your java app keyboard preferences if it has its own shortcut-function bound to the ALT+SHIFT.
It may be so for IntelliJ IDEA.
Related
I am writing a Java application, in which I need to be able to change input languages (say, from English to Japanese) on user request. Normally, a user would just go into the Windows/Linux system settings and change it there. However, for this particular application, the user will not have access to these menus.
I've done quite a bit of research on SO and elsewhere. The solutions I've found indicate using the InputContext.selectInputMethod([locale]) method. This works on Windows (using the IMEs in the Windows registry), but I can't seem to get it to work on Linux (it always returns false, even when selecting a locale for which I have the appropriate language packs installed).
Ideally, I'd like to have a completely platform independent implementation, but I at least need it to work on Linux. So what am I missing? Do I need to install input methods as an extension? Are there built in IMEs I can use? It seems like this wouldn't be too difficult to implement, but I've found surprisingly little concrete information.
Thanks in advance for the feedback!
I have recently found out that anything Swing(NetBeans, IDEA) is excruciatingly slow to paint the UI over Remote Desktop(RDP).
Can you guys give me any suggestion for something that will work properly over RDP?
Actually, contrary to everything I've seen - mostly the "Dsun.java2d.noddraw=true", which is mentioned in a number of places, it is actually setting it to false that fixed the drawing issues(for me at least). Go figure.
RDP is optimized for native Windows apps and, regrettably, newer versions of RCP (like Vista/Win7's default RDP) is even more hostile to non-native apps than older (XP/Server 2003) versions. Here's a good link:
http://devnet.jetbrains.net/thread/280673
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4204845
One workaround is to get a screaming fast CPU/graphics board, tons and tons of memory and a super high-speed network connection :)
Another is to:
Select "32-bit true color" in your Terminal Services settings
Select "Modem"
Reduce screen resolution (heck, use 1024x768 if possible)
Here are some additional tips:
http://www.codinghorror.com/blog/2006/04/remote-desktop-tips-and-tricks.html
Try setting "Dsun.java2d.noddraw=true"
http://ubuntuforums.org/archive/index.php/t-1129187.html
http://www.mindfiresolutions.com/Solving-DIRECT-DRAW-ddraw-problems-in-Java-Swing-730.php
I am launching a java swing application from Linux, and display it as a Windows frame thanks to MobaXterm.
If you haven't done it already, please have a look at the following documentation :
https://docs.oracle.com/javase/8/docs/technotes/guides/2d/flags.html
Using -Dsun.java2d.noddraw=true did not fixed my issue, but setting xrender to true did.
So here's the code I used on Linux :
export _JAVA_OPTIONS='-Dsun.java2d.xrender=true'
java -jar my_java_application.jar
Maybe it's not only Swing that paints slow over Remote Desktop. However, Eclipse is based on SWT, based on native widgets, so it is not Swing.
You should give JavaWIDE a try. It is an IDE designed for access to a JDK without it installed on a system, with a built-in storage system so you just need access to the internet. It's not exactly a program for accessing everything on the computer but it will do a good job with your programming. It may take a while however, as the compiling is done on a separate server.
I am working on an Eclipse RCP application with localization. A user should be able to change the language used in the application on the fly. A restart of the application should not take place during this language switch. It should also be possible to switch between languages written from left to right and languages written from right to left.
Is there a (good) way to solve this problem?
According to this thread:
Most of the eclipse libraries load up their language info on widget creation. If you change your locale afterwards you need to restart eclipse to have it take effect.
You could write that kind of dynamic behaviour into your own SWT program, however (when the locale switches, you'd need to call setText(*) on everything :-)
So this is not currently managed dynamically unless you program it yourself...
Other rcp/plugins application like Birt specify the same instructions (i.e. "Restart Eclipse" at the end...)
That said, a slightly different problem was set in this thread:
switch the language setting, restart, and then run in that language
I got it to work by reading bug 222023 and mimicking org.eclipse.ui.internal.ide.actions.OpenWorkspaceAction
I tried it manually:
added "-configuration #user.home/.myapp/configuration" to the launcher.ini
added "osgi.nl" to the users config.ini residing there and it worked.
Since I can access the config-Location via Platform.getConfigurationLocation() I guess that could be the way.
Note: adding "osgi.nl" to the webstart jnlp works too.
You would need to call setText on each widget, with the respective text. Since there is no text variable mapping on the widgets, you would have to do that completely manually as well.
I have a Java program using AWT which I would like to run on a headless system. The display for the program does nothing other than display stats. When the program finishes, it exits. There is no user interaction on the display. The program creates an output file which I use in my build system.
Is there a way to get the Java program to run without an X11 display configured? Can I force Java to run the program without trying to display anything? I do not have access to the source code (it is just .jar file), so I can't make modifications to the source.
Any thoughts on how I could get this to work?
The underlying question here is how to run Java applications without an X server; providing a "fake" X server is only one option. In Java 1.4 and up, you can do the following:
java -Djava.awt.headless=true
This allows applications which use AWT to run on headless systems even without an X server.
Xvfb can do what you ask for. I've not used it myself, but here is a link to wikipedia: http://en.wikipedia.org/wiki/Xvfb
You can use a vncserver.
vncserver :1001
export DISPLAY=localhost:1001
java..
The added advantages is that you can actually view the gui
using vncserver 'just in case'
Could also run Xvnc in a low resolution and color depth.
As mentioned by Charles Duffy the traditional method is to tell Java to go headless.
Note that you can always mount the jar in Eclipse and use jad+jadclipse to see what it actually does, and perhaps even override a class if you need to by putting another class-file in "front" of it in the classpath.
A facility that might be relevant if the program uses Java2D is that newer Java versions use optimizations in the X11 server to render faster. This alone might be a reason to devote an X11 server attached to a high performance graphics card to your graphics processing.
I've used with great success in the past the PJA libraries, they don't seem to be maintained anymore, but then again, just just want to run...
I was able to get headless mode in OpenJFX with the command line arguments
-Dglass.platform=Monocle -Dmonocle.platform=Headless -Dprism.order=sw
The swing-UI of Java-programs doesn't work perfectly together with the awesome-wm. awesome is a window-manager for UNIX, that automatically resizes program-windows, and the Swing-UI doesn't recognize these resizes correctly. I don't care if awesome or Java is guilty, what I wanna know if I can change my Java-programs in a way, that they will work with awesome. So that users of my programs get the correct experience, even when they use exotic window-managers.
Easiest workaround - get wmname from suckless and use it to set the name of the window manager to LG3D:
wmname LG3D
98% of the time this will fix the issue.
From the man page of awesome:
BUGS
Of course there´s no bug in awesome. But there may be unexpected behaviours.
Java applications which use the XToolkit/XAWT backend may draw grey windows only. The XToolkit/XAWT backend breaks ICCCM-compliance
in recent JDK 1.5 and early JDK 1.6 versions, because it assumes a reparenting window manager. As a workaround you can use JDK 1.4
(which doesn´t contain the XToolkit/XAWT backend) or you can set the following environment variable (to use the older Motif backend
instead): AWT_TOOLKIT=MToolkit
You might find that this is a similar problem to that experienced with using Compiz and Java (on Ubuntu at least), but I am guessing.
The fix for this (taken from here) is to add the following environment variable to your program:
AWT_TOOLKIT="MToolkit"