Corrupted (cached?) fonts in java swing - java

My machine seems to be experiencing some weird issues with java swing.
This sort of thing happens with other programs as well but the corruption goes away with scrolling or highlighting the text. What could be causing this and why doesn't java go the same? All the characters seem to be cached so that when a character gets corrupted, all of the characters of the same type have the same corruption (not true of anything but java swing).
I have been googling around for this sort of issue but most of them only suggest issues with graphics drivers and settings for windows... (I am running kubuntu)
Side note: Sorry if this doesn't belong here. Didn't really know where else to ask.

Among the many possible causes,
Verify that all correctly synchronized Java Swing programs using standard font families with the default Look & Feel exhibit this behavior; if not, it may very well be a driver problem.
Investigate whether the Ubuntu video driver permits alterations similar to the one required in this Windows case.
Try a different window manager.
Try a different Look & Feel.

Related

Remove Unexpected border of JTabbedPane

I am trying to add tabs in a JTabbedPane. It is displaying the below mentioned white borderline which I am not expecting here as Every color is already set to Black except the white color for the text colors. What I might be missing.
I am trying to change this class from jitsi project
Here is what I've tried so far.
OS: Ubuntu 19.10: Java Version: 1.8.0_242
Windows 10 Pro: Java Version: 1.8.0_241
I am using default look and feel for this Frame whereas, for my manually created design, it is Nimbus.
The answer for the question heavily depends on the Look and Feel you're using for your application. I can't tell which one you're using by just looking at the screenshot because you modified it a lot and you've left out part of the code in your question that installs it. In case you aren't installing any specific one - you're running the default Look and Feel, which might also be different depending on the OS/JDK versions, if I'm not wrong.
So as #sleepToken already said in the comment - do not post random parts of your code or all of the code, instead post an SSCCE. While sometimes you might think it is unnecessary and/or unrelated - in many cases it is not, and it does help whoever will read and try to answer your question to run the code & debug the issue if necessary.
That being said - I can give a general answer to your question: All component are painted by their respective UI implementation (TabbedPaneUI in this particular case) and in some cases parts of the painting code might not be configurable, for instance some colors or other options might be hard-coded. You can simply look into the source code of the particular UI implementation that your application uses, find the painting code that you want to configure and see if it is actually configurable in the first place.
In case your application uses MetalLookAndFeel - the implementation is MetalTabbedPaneUI. From what I can tell by looking at it's code - it uses colors from TabbedPane.highlight, TabbedPane.borderHightlightColor and TabbedPane.darkShadow UI defaults for the border. Adding custom color for TabbedPane.highlight might fix the issue for you since you didn't mention that you modified that one in your question.
In case it doesn't - I once again recommend posting an SSCCE along with your OS type/version in case you're using a native Look and Feel. Native Look and Feel differs between different JDK versions for different OS version and often uses a highly customized UI implementation that might not be as configurable.

What is the difference between JRE options java.awt.headless and java.awt.headlesslib?

I have used the former many times (-Djava.awt.headless=true) in order to prevent the infamous "no DISPLAY found" error for some applications which used some graphics methods in the JRE.
But since then I have also learned of the existence of the second one. In spite of hours of searching around, I cannot find a difference between both.
And to make matters worse, I am no GUI expert at all... So, is there an actual difference? What code would work with one and not the other, or would require both etc?
java.awt.headlesslib is part of a temporary workaround added in 2001 in response of bug JDK-4407772.
If you download the source code of openjdk6, openjdk7 or openjdk8 and grep all the source files looking for java.awt.headlesslib you will see no results.
So the effect of setting java.awt.headlesslib is null and the effect of setting java.awt.headless is to activate the headless mode.

Java IDE for working over Remote Desktop

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.

What's ideal debugging setup? window placement etc

I am interested in knowing Debugging setup that'll allow a programmer to be most productive. Assuming knowledge about debugging in general.
I am mainly interested in knowing how and where you place different windows like the variables window, code window, the stack. Also possibly the relative size of different windows.
I'd prefer if there are screenshots attached and a description of why the setup works for you or one that is efficient.
I mainly use Eclipse and Netbeans.
Most productive? That's going to vary greatly from person to person. You shouldn't focus on what works best for other people or details like precise window placement... figure out what works best for you with some trial and error.
For me, multiple monitors are important. I keep code and tools (Eclipse, SQL manager, etc) open on one, and use the other for the console and the running program (whatever it may be: website, windowed application, etc).
First you have to know how to use the debugger really well and then after that the placement of windows is just frivolous detail, for the most part. It will just fall into place without having to mimic other people's comfort level with the tools.
It sounds like you're looking for a static setup but likely you will show/hide windows depending on what you're debugging and size them to different situations. At least that's what I do. So I would post many screenshots and they'd all look different.
"I'd prefer if there are screenshots attached and a description of why the setup works for you. "
You're exactly right knowing it works for the other person.
In addition to what others have said, one thing that I do with respect to variable windows - Visual Studio gives you 4 different watch windows. I usually put them all into a single tabbed window, and each tab will represent a different programming context. For example, tab 1 will list variables that I usually need to look at when dealing with area A, tab 2 has variables for area B and so on.
Doing this, I find that the watch windows don't get over cluttered and I spend less time setting up variables

fonts on org.eclipse.swt.widgets.Composite are messed up on Linux

I extend org.eclipse.swt.widgets.Composite and create many widgets on it, (labels, table, text etc). The problem I am facing is that the labels' text is getting truncated on linux while it appears fine on windows. When I change the linux's font to gothic the truncation is little less but still there. Is there way to homogenize the windows and linux display. What could be the best font to use in linux in such a case.
More likely it is related to this eclipse bug which I just lobbied to have re-opened: https://bugs.eclipse.org/bugs/show_bug.cgi?id=151322
It sounds like you are using absolute positioning instead of dynamic layouts. (If this isn't the case, perhaps you could post code demonstrating the problem). Using a dynamic layout should ensure that controls are resized to accommodate their contents. (They're also great if you ever translate a product, because then you don't have to rejig every dialog for every language.)
To complete McDowel's answer, there is also a bug related to the way Linux check for wrapping label:
It is fixed since 3.4M7.
Even though it may not be related to your case, it would be useful to know which version of eclipse you are using and if you can reproduce your bug with the latest ones (like a 3.5M6)

Categories