XGServerWindow.m small fixes #25
Conversation
WRaster context depth 24. (styleoffsets::::::): do not guess offsets for miniwindow and appicon they are equal to 0.0.
| @@ -2283,7 +2283,8 @@ - (void) styleoffsets: (float *) l : (float *) r : (float *) t : (float *) b | |||
|
|
|||
| if ((style & NSIconWindowMask) || (style & NSMiniWindowMask)) | |||
| { | |||
| style = NSBorderlessWindowMask; | |||
| *l = *r = *t = *b = 0.0; | |||
There was a problem hiding this comment.
Why do you think this required? Shouldn't we first check what is already stored in the known offsets?
There may be window managers that put a border even on these windows.
There was a problem hiding this comment.
There are 2 things here:
- It's a special windows: miniwindow and appicon. If window manager defines offsets for such type of windows user should better disable appearance of them via defaults.
- Simple application has 2 windows which produce "styleoffsets ... guessing offsets" messages: appicon and window with ID == 0. I see exacly 2 messages at application start. It means that code at line range 2295-2306 doesn't work either. Finally in WindowMaker we will end up with offsets 1.0 and that's wrong for miniwindow and appicon. For other WMs it will be 4.0. Is it what we need for our appicon and miniwindows?
In general I think that code below NSLog line is wrong and useless. Why offset for EWMH-compliant WM is 4.0? Why titlebar and resizebar sizes fixed and defined to that values?
| @@ -2841,7 +2842,7 @@ - (int) _createAppIconPixmaps | |||
| height = [rep pixelsHigh]; | |||
| colors = [rep samplesPerPixel]; | |||
|
|
|||
| if (rcontext->depth != 32) | |||
| if (rcontext->depth != 32 && rcontext->depth != 24) | |||
There was a problem hiding this comment.
I did put this new test here on purpose as your code did not work for Riccardo. Please have him test this change first. We do not need a regression shortly before a release.
There was a problem hiding this comment.
I tested this specific change on both the problematic T23 16bit as well as the Letux400 (16 bit too) with no adverse effects.
However, I noticed one big thing: possibly due to this skipping, on the Letux app mini windows are not displayed anymore. Like battery monitor is unable to display the battery, only the icon is displayed. I fear this is because all the code is skipped because now it works only in certain conditions, while before it worked.
There was a problem hiding this comment.
Just to clarify, the change that Sergii made tries to allow for more systems to use this new code. It was my change to check for the depth that shut of Letux. I did this because you got a segmentation fault with the new code. If you don't get a segmentation fault now things are improved and Sergii's change to allow for depth 24 may be correct. But it is more likely that one of the other checks I added still blocks the call. You should check for that first.
(_handleTakeFocus:forContext:): if application (window) receives WM_TAKE_FOCUS in hidden state it means WindowMaker wants us to be unhidden. Description: There are 2 protocols defined in XGServerWindow.h: WMFHideApplication and WMFHideOtherApplications. These protocols exist to help GNUstep application and WindowMaker notify each other about "Hide" and "Hide Others" actions. There are no protocols for "unhide" action. Test case steps: 1. Open application with window opened. 2. Hide application with "Hide" menu item. 3. Open WindowMaker's "Windows" menu (middle-click on desktop). 4. Select hidden application window. Application unhides, activates, restored window is focused (receives) input and "Hide" menu item unselected.
I've checked, 24-bit depth works good for images with alpha channel (32-bit depth).
Second fix reduce number of cases when "styleoffsets ... guessing offsets" messages appears.