You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the latest Beta, Windows defaults to Nimbus Look and Feel (CrossPlatformLookAndFeel) whereas I would like to specifically set it to the Windows theme (SystemLookAndFeel)or something else of my choosing.
Very strange -- I don't think I'm doing anything with the look and feel... I'll see what might be going on, but maybe it's from some testing code from @Vzor-?? I do know we were testing an issue with setting the L&F at one point.
Dug a bit deeper, the issue is with the systemutil. The tray initializes and waits on a setEnabled in MenuItem. It then sits on this invokeLater in _SystemTray, at this point it is still a windows look and feel, but as soon as it enters the systemUtil, it runs some custom L&F logic and sets the look and feel to CUSTOM_LOOK_AND_FEEL, which is nimbus, even if I try to set it in test tray.
Not exactly. It's an internal library change (from "Nimbus" -> null) that isn't on github yet. I'm in the process of adding it to github, but its taking a while. As soon as it's added, I'll reference the commit so you can see it.
@tresf the commit that fixed this is : dorkbox/Utilities@d8f0c4d I am still trying to figure out how to make the tray look nice WITHOUT the nimbus L&F (and also, with it...). Once that is resolved, I'll close this issue.
I am still trying to figure out how to make the tray look nice WITHOUT the nimbus L&F (and also, with it...). Once that is resolved, I'll close this issue.
I don't understand this statement. Swing looks fine and it should be on the developer to change L&F. What's wrong with Swing?
Which looked nice on Nimbus (even though I didn't realize it was Nimbus),
Couldn't this be the problem? Swing defaults should be very close to the OS (if not, it's an Oracle bug that we should report or workaround), I would discourage changing anything that's not necessary.
The SystemTray.AUTO_SIZE=false; parameter will keep all artwork at it's provided size. There are 2 more API's added, SystemTray.getTrayImageSize() and SystemTray.getMenuImageSize().
For getting the tray/menu image sizes...
MacOS is done (Apple hardcoded the values)
Linux menu sizes are done, WIP for the tray size (themes and DE's can change it).
Windows Tray size is almost done (it's also hardcoded, just regression testing all versions), and menu sizes are all over the place.
For swing, the logic you figured out (from #45 (comment)) works most of the time, but not for Windows 8.1+ at different DPIs, and to get the actual icon size (as far as I can tell) for the context menu requires jumping into native code. There is already a BSD licensed JNA windows tray implementation, so it's going very, very quickly to add that functionality.
I've decided to do this because now that the size is no longer hardcoded (it is now getting the largest image size possible before changing the menu size), means that at different DPIs there are pretty different menu heights, which really sticks out from the other menus.
There have been several other issues fixed (one was a race condition for Swing menus), and the other is the checkmark menu entries getting offset in Ubuntu (#42). I'll mark that issue fixed once the code has been pushed and it's verified.
So you're coding for an edge-case (HiDPI) on and edge-case (Windows 8.1) to avoid what Java has already done? Isn't this overkill?
I don't want to any edge-case stuff, because that would be close to impossible (and overkill) because different themes and settings can change the menu size.
This (and some-what related issues) are fixed here:
Windows XP: 2eea54b (for this issue)
Windows (General): 2ca5cdf
The system, if AUTO_SIZE=true (the default), will automatically resize all icons to what is reported via native methods, the idea being that a single 64x64 image can be provided, then be downsized as applicable. Regardless of AUTO_SIZE, one can always get the correct tray/menu image size via SystemTray.getTrayImageSize() and SystemTray.getMenuImageSize(), after SystemTray.get() has been called, but before any images have been assigned to the tray/menu. Of important note, not all versions of Windows have the same image size (it depends on the current theme applied), as is the same for Linux. MacOSX will always have the same image size (based on DPI settings).
Additionally, HiDPI settings are also accounted for, so whatever the reported image size, is the correct image size for the DPI applied. There are "per-monitor" settings for Windows 8.1+, and it is not particularly easy to determine multiple screens and which screen the system tray is on. The overall DPI will be used based on windows handler in which the Java app is launched. I've found that this usually is correct since I'm querying windows directly for what image size to use.
I will post post test/beta jars for validation before the 3.2 release, as image sizes greatly rely on the underlying hardware/software configuration, and should should be fully resolved before release.
@tresf I've pushed the beta "all in one jar" for testing, if you'd like to verify this issue is resolved for you. Once I hear from you, I'll close this issue and release 3.2
Activity
dorkbox commentedon Feb 7, 2017
Very strange -- I don't think I'm doing anything with the look and feel... I'll see what might be going on, but maybe it's from some testing code from @Vzor-?? I do know we were testing an issue with setting the L&F at one point.
tresf commentedon Feb 7, 2017
I'm using RC9 from your downloads area and @Vzor- has zero commits on your
masterbranch, so none I'm aware of.tresf commentedon Feb 7, 2017
Is there a chance you're accidentally initializing a Swing component before
init()is called (such as in a static method?)Vzor- commentedon Feb 8, 2017
Ill whip up a test case tonight to verify it is not in our code.
Vzor- commentedon Feb 8, 2017
I pushed the test, this issue seems to be in dorkbox. Vzor-@37712f5 I'll help more after some sleep 😴
Vzor- commentedon Feb 8, 2017
The issue occurs here https://github.com/Vzor-/SystemTray/blob/master/src/dorkbox/systemTray/SystemTray.java#L789
It resolves as a dorkbox.systemTray.swingUI._SwingTray but that is about the extent of what I can see with the debugger.
Vzor- commentedon Feb 8, 2017
Dug a bit deeper, the issue is with the systemutil. The tray initializes and waits on a setEnabled in MenuItem. It then sits on this invokeLater in _SystemTray, at this point it is still a windows look and feel, but as soon as it enters the systemUtil, it runs some custom L&F logic and sets the look and feel to CUSTOM_LOOK_AND_FEEL, which is nimbus, even if I try to set it in test tray.
Vzor- commentedon Feb 8, 2017
The menu looks strange under any l&f that isn't Nimbus
may be a tough one to fix
dorkbox commentedon Feb 8, 2017
I fixed the issue with the SystemUtil, so it's not set to a default value - I'll see what can be done about making the menu look nice
tresf commentedon Feb 8, 2017
@dorkbox can you reference the commit so we can learn from the change and also close the bug report?
dorkbox commentedon Feb 8, 2017
Not exactly. It's an internal library change (from "Nimbus" -> null) that isn't on github yet. I'm in the process of adding it to github, but its taking a while. As soon as it's added, I'll reference the commit so you can see it.
dorkbox commentedon Feb 10, 2017
@tresf the commit that fixed this is : dorkbox/Utilities@d8f0c4d I am still trying to figure out how to make the tray look nice WITHOUT the nimbus L&F (and also, with it...). Once that is resolved, I'll close this issue.
tresf commentedon Feb 10, 2017
I don't understand this statement. Swing looks fine and it should be on the developer to change L&F. What's wrong with Swing?
dorkbox commentedon Feb 10, 2017
I'm customizing the menu and menu items slightly (just the margins) which looked nice on Nimbus (even though I didn't realize it was Nimbus), and it looked wonky without it. IE: https://github.com/dorkbox/SystemTray/blob/master/src/dorkbox/systemTray/swingUI/AdjustedJMenuItem.java
tresf commentedon Feb 10, 2017
Couldn't this be the problem? Swing defaults should be very close to the OS (if not, it's an Oracle bug that we should report or workaround), I would discourage changing anything that's not necessary.
80 remaining items
dorkbox commentedon Jul 6, 2017
It is possible to get it close, but it's not exact, and the HiDPI stuff really buggers up the spacing/size.
tresf commentedon Jul 6, 2017
I'm still confused. It's dead-on by default. What is there to code? Is it the icons that muck it all up? I don't understand.
dorkbox commentedon Jul 6, 2017
The icons muck it all up.
tresf commentedon Jul 6, 2017
Will the library just leave the artwork at its default size? I think this is livable for now.
dorkbox commentedon Jul 6, 2017
The
SystemTray.AUTO_SIZE=false;parameter will keep all artwork at it's provided size. There are 2 more API's added,SystemTray.getTrayImageSize()andSystemTray.getMenuImageSize().For getting the tray/menu image sizes...
For swing, the logic you figured out (from #45 (comment)) works most of the time, but not for Windows 8.1+ at different DPIs, and to get the actual icon size (as far as I can tell) for the context menu requires jumping into native code. There is already a BSD licensed JNA windows tray implementation, so it's going very, very quickly to add that functionality.
I've decided to do this because now that the size is no longer hardcoded (it is now getting the largest image size possible before changing the menu size), means that at different DPIs there are pretty different menu heights, which really sticks out from the other menus.
There have been several other issues fixed (one was a race condition for Swing menus), and the other is the checkmark menu entries getting offset in Ubuntu (#42). I'll mark that issue fixed once the code has been pushed and it's verified.
tresf commentedon Jul 7, 2017
So you're coding for an edge-case (HiDPI) on and edge-case (Windows 8.1) to avoid what Java has already done? Isn't this overkill?
dorkbox commentedon Jul 7, 2017
I don't want to any edge-case stuff, because that would be close to impossible (and overkill) because different themes and settings can change the menu size.
dorkbox commentedon Jul 12, 2017
No edge cases necessary, I found the correct API to get the tray/menu correct image size.
dorkbox commentedon Jul 22, 2017
This (and some-what related issues) are fixed here:
Windows XP: 2eea54b (for this issue)
Windows (General): 2ca5cdf
The system, if
AUTO_SIZE=true(the default), will automatically resize all icons to what is reported via native methods, the idea being that a single 64x64 image can be provided, then be downsized as applicable. Regardless ofAUTO_SIZE, one can always get the correct tray/menu image size viaSystemTray.getTrayImageSize()andSystemTray.getMenuImageSize(), afterSystemTray.get()has been called, but before any images have been assigned to the tray/menu. Of important note, not all versions of Windows have the same image size (it depends on the current theme applied), as is the same for Linux. MacOSX will always have the same image size (based on DPI settings).Additionally, HiDPI settings are also accounted for, so whatever the reported image size, is the correct image size for the DPI applied. There are "per-monitor" settings for Windows 8.1+, and it is not particularly easy to determine multiple screens and which screen the system tray is on. The overall DPI will be used based on windows handler in which the Java app is launched. I've found that this usually is correct since I'm querying windows directly for what image size to use.
I will post post test/beta jars for validation before the 3.2 release, as image sizes greatly rely on the underlying hardware/software configuration, and should should be fully resolved before release.
dorkbox commentedon Jul 23, 2017
@tresf I've pushed the beta "all in one jar" for testing, if you'd like to verify this issue is resolved for you. Once I hear from you, I'll close this issue and release 3.2
tresf commentedon Jul 23, 2017
@dorkbox we'd be happy to test, but we can't go live without tooltips (#50), so we'd have to split our code for Windows and Mac.
dorkbox commentedon Jul 23, 2017
Hm. Alright, I'll add tooltips. :)
dorkbox commentedon Aug 24, 2017
Release 3.2 is out, with added tooltips.