I am getting a strange discrepancy between the preview and actual running of my jar file with a combo box, and it seems to be a default in both of my laptops which are entirely different design. I included a simple example image (below). The combobox does have 36 entries and should only allow one selection - which is why I prefer to use this element type. My issue is a strange look of the combo box thumb (image on right) in comparison with the typical and expected look shown in the image on the right from viewing the Preview Design in NetBeans. See image
Scouring the internet I cannot find much that shows this discrepancy. Thank you.
This looks like a matter of "Look and Feel":
https://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/plaf.html
The Preview Design is using a different default L&F than the environment where you're running the application.
Related
I am trying to find a java look&feel that can be used in NetBeans (I'm currently usign version 14) to have a "what you see is what you get" result
As I said here: netbeans design missing bold, I was using the Metal l&f, both in NetBeans (by launching it with the "--laf javax.swing.plaf.metal.MetalLookAndFeel" parameter) and in the code
But lately it doesn't work as it used to: in NetBeans the varoius graphical objects (labels etc...) have a "normal" font, but when i run the project, they have a bold font, which makes them larger and ruins their positioning. Thus I can't create a good graphical interface anymore, because I have lost the "what you see is what you get" effect
I have also tried different l&f, for example Nimbus. With it, I can solve my problem: NetBeans correctly shows the graphical objects as expected. But imho Nimbus has a big lack: non-editable obects (for example text fields) are showed identical as editable ones! (the Metal l&f instead makes a good work at this)
I'm searching for a l&f that can correctly be displayed by NetBeans, and that can differentiate between editable and non-editable objects. Can you point me out any?
Try com.sun.java.swing.plaf.windows.WindowsLookAndFeel.
You need not to put startup options in NetBeans, check look and feels Tools / Options / Apperance menu.
Another workaround would be making all non-editable widgets to be disabled - setEnabled(false).
I'm working on a Java project (for those curious, it's a Rcon and Query client for Minecraft servers) and I'm trying to create a GUI. I'm using Eclipse Windowbuilder, and I'm trying to make the program window dynamic (in other words, when the window is resized, everything else moves and scales to fit), but none of the layouts seem to do that (which defeats the purpose of the layout, doesn't it). It's worth mentioning that I'm putting four groups on the screen, which will contain other things and should take up all available space. I would put the code here, but there's nothing besides the default application framework generated by Eclipse. So, what layout do I use for dynamic resizing and such? Or am I missing something stupid?
(P.S. I've tried GridLayout, FormLayout, and many others. They didn't work.)
The following is for Eclipse Windowbuilder users.
For this to work (assuming GridLayout is used) you must set several properties for every single thing in the GridLayout:
grabExcessHorizontalSpace should be true (check the box)
grabExcessVerticalSpace should also be true (again, check the box)
horizontalAlignment should be set to FILL (selected from drop-down)
verticalAlignment should also be set to FILL (also selected from drop-down)
Thanks to greg-449 for giving me this link, which solved the problem.
What I am trying to accomplish is to select an area on the screen with the mouse (outside of the may frame) and get the resulting region coordinates using Sikuli.
The code that should do this looks is below:
Screen screen = Screen.getPrimaryScreen();
Region region = screen.selectRegion("Select the area.");
What happens is that the cursor turns into a selector cross (the ones you usually see when you expect this function), but I can't select the area and actually the only way I can get back from the application is by killing it. Not too many examples I have found so I am asking for help here.
How can I make this work?
Also one other question:
I have downloaded the following script version:
Sikuli-IDE-1.0.0-Win64.zip
This means if I want to create a crossplatform solution I have to include like 6 jars? I have found a more universal Java API it seems (that is what it is called actually):
https://code.google.com/p/sikuli-api/
With all required supported OS but I can't find a single example on what I am trying to do that is similar to the little code snippet I pasted here. The sikuli script I am using now and this Sikuli API (apparently not the same) seems to be just different enough to amke this difficult.
Any suggestions? Thanks a lot in advance.
As it turns out, this only happens if I put this functionality on a Swing button's actionhandler. I have reported the bug to Sikuli and it will be probably fixed in the next release.
The Window component that I use has Resizable flag set to false but the resize cursor on the edges still appear. Is there any way to change the cursor to normal ?
I am using Sencha GXT 3, with appearance pattern.
EDIT:
Both answers (SSR and Jonathan) are correct but a bit overkill. And what happens to other Windows which are resizable ?
I notified Sencha about the issue and they labeled it as a bug. Upgrading to GXT 3.0.3+ will solve the issue.
It might be not be possible without hacking into gxt code. The resize cursor code seems to be hardcoded into css styles in gwt code which is obfuscated. You can see in the below image a obfuscated style with cursor : e-resize;
Open up gxt jar. Copy the relevant Window code into your code base in same package structure as gxt and then make the changes in gwt template style related to Window. Ensure this class is in higher classpath hierarchy than gxt code when gwt compiler picks it up.
Log a bug with GXT team to get a official patch.
The Resizable class has ResizableAppearance. If we look in ResizableBaseAppearance, we can take a look at how the GXT team has implemented this stuff.
I'm guessing that what is going on is that when a Window is initially created, Window.setResizable(true) is called which injects the styles and sets up the handlers for resizing.
You could roll your own ResizeableAppearance and set up your deferred-binding rules to use yours instead of the default ResizableBaseAppearance (make sure those rules come after your inherit of GXT in your *.gwt.xml).
This will replace the appearance of the Resizer in ALL Windows. So, the trick would be to figure out how to determine if resizing is turned off or not.
Hope this helps.
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)