Cropped windows in some apps.

[JakeSFR]

Hi Joe

There's a problem with displaying some dialog windows in SoftMaker Office - they're cropped from right side. Here's the source & details: http://www.murga-linux.com/puppy/viewtopic.php?p=759195#759195

Also, seems to be related - VICE-2.3 (Commodore emulator, from Salix repo, Slacko-5.6.5.6 Beta, JWM-878) displays its window as a long, vertical, thin line. Any attempt to resize it results in crashing X and exiting to prompt.

Screenshot: http://oi58.tinypic.com/j7z57m.jpg

Both apps behave fine with JWM-574, btw.

Greetings!

[joewing]

I'm having trouble getting SoftMaker Office to run on my system (it seems the 64-bit version isn't really 64-bit). Anyway, would you be able to provide me with the output from xwininfo and xprop for the window in question? Worst case I'll just load a a VM I suppose.

I am able to reproduce the VICE issue, so hopefully I'll have it fixed soon.

[JakeSFR]

Here you go, hope it will help:

xwininfo: Window id: 0x1800017 "TextMaker Install"

  Absolute upper-left X:  132
  Absolute upper-left Y:  162
  Relative upper-left X:  2
  Relative upper-left Y:  22
  Width: 156
  Height: 156
  Depth: 24
  Visual: 0x21
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x20 (installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +132+162  -512+162  -512-282  +132-282
  -geometry 156x156+132+162

----------------------------

_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_MOVE, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_STICK, _NET_WM_ACTION_BELOW, _NET_WM_ACTION_ABOVE
_NET_FRAME_EXTENTS(CARDINAL) = 2, 2, 22, 2
_NET_WM_STATE(ATOM) = 
WM_STATE(WM_STATE):
        window state: Normal
        icon window: 0x0
_NET_WM_DESKTOP(CARDINAL) = 0
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW
_NET_WM_ICON_NAME(UTF8_STRING) = "TextMaker Install"
_NET_WM_NAME(UTF8_STRING) = "TextMaker Install"
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLIENT_MACHINE(STRING) = "puppypc30531"
WM_ICON_NAME(STRING) = "TextMaker Install"
WM_NAME(STRING) = "TextMaker Install"
WM_HINTS(WM_HINTS):
        bitmap id # to use for icon: 0x1800012
        bitmap id # of mask for icon: 0x1800013
        starting position for icon: 0, 0
        window id # of group leader: 0x1800001
WM_NORMAL_HINTS(WM_SIZE_HINTS):
        user specified location: 132, 162
        program specified location: 132, 162
        user specified size: 377 by 156
        program specified size: 377 by 156
        program specified minimum size: 377 by 156
        program specified maximum size: 377 by 156
        program specified resize increment: 0 by 0
        program specified minimum aspect ratio: 0/0
        program specified maximum aspect ratio: 0/0
        program specified base size: 377 by 156
        window gravity: Forget
WM_TRANSIENT_FOR(WINDOW): window id # 0x1800001

Thanks & Greetings!

[joewing]

I think commit f4add681e6b3066d1f88bd7eb2a74bd8c5895f84 might fix the issue with SoftMaker Office too. I changed the way JWM handles aspect ratios, and I think with the 0/0 aspect ratio (from the xprop output) would have caused problems before.

The update is in snapshot 891.

[JakeSFR]

Thanks for the quick fix! Yep, it did the job for VICE, but unfortunately no change for SoftMaker. Seems to be something else...

Greetings!

[joewing]

My best guess is that the application is reusing the window and not resizing it. The size hints imply that the application wants the window to be a different size, but the width/height members of that structure are obsolete, so JWM really shouldn't use those (or risk breaking other things). I modified JWM to use the min/max window size when initially placing a window, so that should cause JWM to resize the window (I would guess other window managers do this as well). Anyway, the update is in snapshot 892.

Thanks for helping me debug this!

[JakeSFR]

Sorry to say, but still no go. :( What intrigues me is that all of those affected windows are of the kind which has no taskbar hint. Also, their width is being reduced to fit their height, e.g. 248x248. Another observation - some dialogs (e.g. "Save As") do allow to be resized, but doing so (no matter horizontally or vertically) resizes the window in both directions, preserving W&H equal.

I agree it's better not to use an obsolete stuff, especially that SM is, so far, the one and only app that causes these troubles.

Greetings!

[joewing]

So my next thought is that perhaps the window is updating its size hints after being mapped. JWM wouldn't have handled that correctly before, but it should now as of snapshot 894. I updated https://github.com/joewing/wmtest to check for that situation.

Thanks!

[JakeSFR]

It's a tough nut - no change again... Shot in the dark: I might have wrong recollection, but IIRC, at some point, JWM has started to resize/stretch tray icons to be squares. If so, I wonder is it possible that those windows are being, preliminarily, interpreted by JWM as tray icons and therefore resized in that way..?

Thanks again & Greetings!

[joewing]

Very strange. I'll have to think about it. If nothing else, I'll try loading it in a VM this weekend.

JWM used to constrain dock icons to be squares, I changed it so it didn't, but that caused problems for some applications so I changed it back. It really shouldn't have any effect on applications that don't use the dock though. If that were happening, I would expect the windows to be the size of the tray.

Thanks!

[joewing]

I think this should be fixed in snapshot 895. JWM was setting the aspect ratio to 1/1 if it was specified as 0/0, which is what SoftMaker is doing.

Thanks!

[JakeSFR]

Yeah, I can confirm the fix is working. Thanks a lot - great job! :)

Greetings!