Skip Menu |

This queue is for tickets about the Prima CPAN distribution.

Report information
The Basics
Id: 90269
Status: resolved
Priority: 0/
Queue: Prima
People
Owner: Nobody in particular
Requestors: user42 [...] zip.com.au
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)
Attachments
foo.pl
patch

History Show all quoted text
  Mon Nov 11 16:45:55 2013 user42 [...] zip.com.au - Ticket created
Subject: maximize by NET-WM message
Date: Tue, 12 Nov 2013 08:45:19 +1100
To: bug-Prima [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
I've had a bit of trouble with the prima window maximize() under recent debian i386 fvwm 2.6.5. After maximizing a restore does not return to the previous size, whereas I hoped it would. Simple program below. Pressing maximize button maximizes as expected, but then pressing restore does not return to the previous size. Nosing around with xmon it seems maximize is Unmap ClientMessage set _NET_WM_STATE property Map I wonder if for netwm it would be ClientMessage alone and trust the wm to update the state and maintain the "normal" size, with no unmapping or property storing. I saw a comment in apc_win.c /* net hints changes by themselves do not result in maximization - need explicit map/unmap. */ If that meant storing to _NET_WM_STATE does nothing then yes that's so. As I understand it after mapping a client should send wm messages for any changes (any client can ask to change any toplevel). Initial _NET_WM_STATE can be set for desired initial state. Incidentally the code syncing with the wm seems hairy. I'm not sure there's a protocol for that. You'd be tempted to send ClientMessage and not worry that the actual change will take place a little later. Could applications tolerate the maximize state not changing immediately but only a little later?

Message body is not shown because sender requested not to inline it.

  Mon Nov 11 17:30:06 2013 dmitry [...] karasik.eu.org - Correspondence added
Subject: Re: [rt.cpan.org #90269] maximize by NET-WM message
Date: Mon, 11 Nov 2013 23:29:46 +0100
To: Kevin Ryde via RT <bug-Prima [...] rt.cpan.org>
From: Dmitry Karasik <dmitry [...] karasik.eu.org>
Show quoted text
> I've had a bit of trouble with the prima window maximize() under recent > debian i386 fvwm 2.6.5. After maximizing a restore does not return to > the previous size, whereas I hoped it would.
Hi Kevin, Thanks for the report, I'll take a look as soon as I can, this or next week. Show quoted text
> Nosing around with xmon it seems maximize is > > Unmap > ClientMessage > set _NET_WM_STATE property > Map > > I wonder if for netwm it would be ClientMessage alone and trust the wm > to update the state and maintain the "normal" size, with no unmapping or > property storing. > > I saw a comment in apc_win.c > > /* net hints changes by themselves do not result in maximization - > need explicit map/unmap. */ > > If that meant storing to _NET_WM_STATE does nothing then yes that's so. > As I understand it after mapping a client should send wm messages for > any changes (any client can ask to change any toplevel). Initial > _NET_WM_STATE can be set for desired initial state.
There's a simple explanation to this, this code was adapted from gtk2, and worked fairly well since. Show quoted text
> Incidentally the code syncing with the wm seems hairy. I'm not sure > there's a protocol for that.
I don't think there's any, but it's generally fairly legit to send a resize (map etc) request and wait for ConfigureNotify (MapNotify etc) event. Show quoted text
> You'd be tempted to send ClientMessage and > not worry that the actual change will take place a little later. Could > applications tolerate the maximize state not changing immediately but > only a little later?
Not really, that would break lots of logic. Prima tries to wait for ConfigureNotify so that size and state changes happens inside maximize(). Of course its best effort can fail, so size change event can indeed arrive later; but not the state event. It looks to me that the culprit code is this: if ( XX-> flags. zoomed && state != wsMaximized) { set_net_hints( X_WINDOW, -1, -1, 0, -1); apc_window_set_rect( self, XX-> zoomRect. left, XX-> zoomRect. bottom, XX-> zoomRect. right, XX-> zoomRect. top); if ( XX-> flags. zoomed) sync = ConfigureNotify; XX-> flags. zoomed = 0; } and most probably XX->zoomRect has wrong values for one or another reason ... if you feel like it you can try to print out its values, and also run the program with --debug=E and/or --icccm, possibly it sheds some light to why it happens. -- Sincerely, Dmitry Karasik
  Mon Nov 11 17:30:07 2013 The RT System itself - Status changed from 'new' to 'open'
  Mon Nov 11 19:08:20 2013 user42 [...] zip.com.au - Correspondence added
Subject: Re: [rt.cpan.org #90269] maximize by NET-WM message
Date: Tue, 12 Nov 2013 11:07:19 +1100
To: bug-Prima [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
"Dmitry Karasik via RT" <bug-Prima@rt.cpan.org> writes: Show quoted text
> > and most probably XX->zoomRect has wrong values for one or another reason ... > if you feel like it you can try to print out its values,
Oh, I tried some prints a while ago but couldn't tell how it went wrong. Yes I think the zoomRect became big, but dunno why. I think I wondered whether for netwm the "normal" size in the toolkit should be unused anyway, if it's all left to the wm. It used to happen only in my big slow program which made it hard to see. It might be easier now in the small program. Incidentally unmap+map is potentially undesirable for "interactive placement" mode where the wm has the user interactively position a newly mapped window. Perhaps no netwm window manager does that now. It was a common option in some of the early wms.
  Tue Nov 12 03:18:43 2013 dmitry [...] karasik.eu.org - Correspondence added
Subject: Re: [rt.cpan.org #90269] maximize by NET-WM message
Date: Tue, 12 Nov 2013 09:18:28 +0100
To: Kevin Ryde via RT <bug-Prima [...] rt.cpan.org>
From: Dmitry Karasik <dmitry [...] karasik.eu.org>
Show quoted text
> Incidentally unmap+map is potentially undesirable for "interactive > placement" mode where the wm has the user interactively position a newly > mapped window. Perhaps no netwm window manager does that now. It was a > common option in some of the early wms.
AFAIR not newly mapped window, but rather a newly created window. I vaguely remember I tested this under twm which does exactly that, waits the user to position a new window, that it doesn't intercept map/unmap requests. But again, twm is a non-netwm manager. But generally speaking, yes, we're totally at a mercy of a wm, whether netwm-complicant or not; it can easily deny (or worse, replace) each configure/map/zorder request and Prima will not be able to detect whether the request was denied or it waited not long enough. So there's quite a lot of ad-hoc code that incidentally works with most popular wms. -- Sincerely, Dmitry Karasik
  Tue Nov 12 03:28:27 2013 dmitry [...] karasik.eu.org - Correspondence added
Subject: Re: [rt.cpan.org #90269] maximize by NET-WM message
Date: Tue, 12 Nov 2013 09:28:10 +0100
To: Dmitry Karasik via RT <bug-Prima [...] rt.cpan.org>
From: Dmitry Karasik <dmitry [...] karasik.eu.org>
Just have tried the example with fvwm 2.5.30 in my ubuntu. Works fine , both maximize and restore work as expected. -- Sincerely, Dmitry Karasik
  Tue Nov 12 03:43:19 2013 dmitry [...] karasik.eu.org - Correspondence added
Subject: Re: [rt.cpan.org #90269] maximize by NET-WM message
Date: Tue, 12 Nov 2013 09:43:06 +0100
To: Dmitry Karasik via RT <bug-Prima [...] rt.cpan.org>
From: Dmitry Karasik <dmitry [...] karasik.eu.org>
Also, just tried fvwm 2.6.5. Fine in all aspects .. also tried it on two-monitor setup, in various combinations, creating window on different screen and dragging it between them, all works o.k. here. I have no idea why the problem might happen .. :( -- Sincerely, Dmitry Karasik
  Thu Nov 14 14:40:43 2013 user42 [...] zip.com.au - Correspondence added
Subject: Re: [rt.cpan.org #90269] maximize by NET-WM message
Date: Fri, 15 Nov 2013 06:39:53 +1100
To: bug-Prima [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
"Dmitry Karasik via RT" <bug-Prima@rt.cpan.org> writes: Show quoted text
> > Also, just tried fvwm 2.6.5. Fine in all aspects ..
Ah dear, a thousand pardons, the blame is all with fvwm. It maximizes by the _NET_WM_STATE flags and messages, but deletes the flags from the _NET_WM_STATE property. So everyone else sees the window grow but the flags are unset. If prima is fast enough then it sees the _NET_WM_STATE property flags which it (prima) itself stored, causing prima to work correctly. If it's slowed then fvwm has deleted the _NET_WM_STATE maximize flags and prima falls back to its default but fvwm has already grown the window. :-( Incidentally, fvwm _NET_WM_STATE flags are not completely broken, only mostly. Its FULLSCREEN flag seems about right and I'd been using it in other things. That tricked me into thinking it had all the net-wm bits it advertises in _NET_SUPPORTED :-( -- No, eees hamster.
  Thu Nov 14 14:52:17 2013 user42 [...] zip.com.au - Correspondence added
Subject: Re: [rt.cpan.org #90269] maximize by NET-WM message
Date: Fri, 15 Nov 2013 06:51:13 +1100
To: bug-Prima [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
"Dmitry Karasik via RT" <bug-Prima@rt.cpan.org> writes: Show quoted text
> > AFAIR not newly mapped window, but rather a newly created window. I vaguely > remember I tested this under twm which does exactly that, waits the user to > position a new window, that it doesn't intercept map/unmap requests. But again, > twm is a non-netwm manager.
Hmm. fvwm has this mode if you add to .fvwmrc Style * ManualPlacement When first opening a prima window it goes interactive as expected, but then on maximizing it goes interactive a second time. But thereafter it's automatic for any maximize and restore. The second interactive seems a bit stupid since it has the maximize flags and so will be the full screen, not where you place it. Why it does it only the two times I don't know. It must as you say remember the windows even when unmap in principle means "withdraw" from window management. But fvwm has rather fallen in my appreciation just at this moment ... :-)
  Thu Nov 14 17:04:02 2013 dmitry [...] karasik.eu.org - Correspondence added
Subject: Re: [rt.cpan.org #90269] maximize by NET-WM message
Date: Thu, 14 Nov 2013 23:03:46 +0100
To: Kevin Ryde via RT <bug-Prima [...] rt.cpan.org>
From: Dmitry Karasik <dmitry [...] karasik.eu.org>
Show quoted text
> Hmm. fvwm has this mode if you add to .fvwmrc > > Style * ManualPlacement > > When first opening a prima window it goes interactive as expected, but > then on maximizing it goes interactive a second time. But thereafter > it's automatic for any maximize and restore. The second interactive > seems a bit stupid since it has the maximize flags and so will be the > full screen, not where you place it. Why it does it only the two times > I don't know. It must as you say remember the windows even when unmap > in principle means "withdraw" from window management. But fvwm has > rather fallen in my appreciation just at this moment ... :-)
That's doesn't look right, no. But it would be interesting to see if it does the same on a native gtk application (because maximization code was lifter off gtk).. -- Sincerely, Dmitry Karasik
  Thu Nov 14 18:51:43 2013 user42 [...] zip.com.au - Correspondence added
Subject: Re: [rt.cpan.org #90269] maximize by NET-WM message
Date: Fri, 15 Nov 2013 10:50:50 +1100
To: bug-Prima [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
"Dmitry Karasik via RT" <bug-Prima@rt.cpan.org> writes: Show quoted text
> > But it would be interesting to see if it does > the same on a native gtk application (because maximization code was lifter off gtk)..
With a test program, it doesn't. Interactive placement for first open, then maximize is not interactive. Did gtk once unmap/set/map? I see for example even back to gtk 2.0.0 gdk/x11/gdkwindow-x11.c gdk_wmspec_change_state() is XSendEvent() of ClientMessage to ask the wm for change. Some xmond suggests this is still so in, umm, recent 2.24.21.
  Thu Nov 14 19:33:33 2013 dmitry [...] karasik.eu.org - Correspondence added
Subject: Re: [rt.cpan.org #90269] maximize by NET-WM message
Date: Fri, 15 Nov 2013 01:33:21 +0100
To: Kevin Ryde via RT <bug-Prima [...] rt.cpan.org>
From: Dmitry Karasik <dmitry [...] karasik.eu.org>
On Thu, Nov 14, 2013 at 06:51:44PM -0500, Kevin Ryde via RT wrote: Show quoted text
> Queue: Prima > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=90269 > > > "Dmitry Karasik via RT" <bug-Prima@rt.cpan.org> writes:
> > > > But it would be interesting to see if it does > > the same on a native gtk application (because maximization code was lifter off gtk)..
> > With a test program, it doesn't. Interactive placement for first open, > then maximize is not interactive. > > Did gtk once unmap/set/map? I see for example even back to gtk 2.0.0 > gdk/x11/gdkwindow-x11.c gdk_wmspec_change_state() is XSendEvent() of > ClientMessage to ask the wm for change. Some xmond suggests this is > still so in, umm, recent 2.24.21.
Hmm gdk did _not_ do map/unmap? This gets strange. I don't remember it was my idea... Anyway the code is definitely there for a purpose, and I can't remember what specific setup it was for. I see it is from 2003, and back then I was using KDE, which might do strange things. Also, generally, I agree that map/unmap is a weird technique for maximization, and deserves even if not removal, but at least testing again on modern WMs. Especially that gtk doesn't do it. Could I then ask you then if you can try to remove this map/unmap path and see if it gets any better on your fvwm setup? /dk -- Sincerely, Dmitry Karasik
  Wed Nov 20 18:36:09 2013 user42 [...] zip.com.au - Correspondence added
Subject: Re: [rt.cpan.org #90269] maximize by NET-WM message
Date: Thu, 21 Nov 2013 10:34:49 +1100
To: bug-Prima [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
"Dmitry Karasik via RT" <bug-Prima@rt.cpan.org> writes: Show quoted text
> > Could I then ask you then if you can try to remove this map/unmap path and see if it gets any better > on your fvwm setup?
Use the change message instead? fvwm is equally bad on that for the maximize I think, but it would help the manual placement bit. What do you think of sending a change message and wait for the _NET_WM_STATE property to change to the desired setting (with a timeout). In general that might be more reliable than listening for ConfigureNotify. You could even think about not doing the fallback maximize if the state doesn't become what's desired. If the wm says _NET_SUPPORTED then take it at its word and if the change message doesn't actually do anything then too bad. I reached all this because I had in my program a keybinding (and a menu entry) to control the maximize from the program. I toggle there rather than set to a particular state, if maybe there was something in prima to send a toggle message when under net-wm.
  Thu Nov 21 04:08:36 2013 dmitry [...] karasik.eu.org - Correspondence added
Subject: Re: [rt.cpan.org #90269] maximize by NET-WM message
Date: Thu, 21 Nov 2013 10:08:18 +0100
To: Kevin Ryde via RT <bug-Prima [...] rt.cpan.org>
From: Dmitry Karasik <dmitry [...] karasik.eu.org>
Hi Kevin, Show quoted text
> > Could I then ask you then if you can try to remove this map/unmap path and see if it gets any better > > on your fvwm setup?
> Use the change message instead? fvwm is equally bad on that for the > maximize I think, but it would help the manual placement bit.
No, not even change message, just how it works without map/unmap. I suspect that my comment "net hints changes by themselves do not result in maximization need explicit map/unmap" might just not be valid anymore in 2013. Show quoted text
> What do you think of sending a change message and wait for the > _NET_WM_STATE property to change to the desired setting (with a > timeout). In general that might be more reliable than listening for > ConfigureNotify. > > You could even think about not doing the fallback maximize if the state > doesn't become what's desired. If the wm says _NET_SUPPORTED then take > it at its word and if the change message doesn't actually do anything > then too bad.
I believe prima does it exactly as you're describing it. It waits for ConfigureNotify and then checks for _NET_WM_STATE. It needs ConfigureNotify _also_ because it wants to fire cmSize synchronously, if possible. Show quoted text
> I reached all this because I had in my program a keybinding (and a menu > entry) to control the maximize from the program. I toggle there rather > than set to a particular state, if maybe there was something in prima to > send a toggle message when under net-wm.
I'm not sure if I understand difference between "toggle" and "set to a particular state", what do you mean by that? Only send NET_WM_STATE change without map/unmap? -- Sincerely, Dmitry Karasik
  Thu Nov 21 18:22:14 2013 user42 [...] zip.com.au - Correspondence added
Subject: Re: [rt.cpan.org #90269] maximize by NET-WM message
Date: Fri, 22 Nov 2013 10:21:55 +1100
To: bug-Prima [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
"Dmitry Karasik via RT" <bug-Prima@rt.cpan.org> writes: Show quoted text
> > No, not even change message, just how it works without map/unmap. I suspect that > my comment "net hints changes by themselves do not result in maximization > need explicit map/unmap" might just not be valid anymore in 2013.
I think from my reading of net-wm spec that a client shouldn't change _NET_WM_STATE after the window is managed, that the property belongs to the wm then. Which would explain your comment in the code, if that was what you found didn't work. Show quoted text
> It waits for ConfigureNotify > and then checks for _NET_WM_STATE. It needs ConfigureNotify _also_ because it wants to > fire cmSize synchronously, if possible.
Oh, I was thinking about waiting for _NET_WM_STATE. Could wait for both _NET_WM_STATE and ConfigureNotify. It's probably unspecified which comes first, though they'd be very close together. Show quoted text
> I'm not sure if I understand difference between "toggle" and "set to a particular state", > what do you mean by that? Only send NET_WM_STATE change without map/unmap?
A ClientMessage can ask for "ADD", "REMOVE" or "TOGGLE" of a state (or two states).
  Fri Nov 22 03:48:15 2013 dmitry [...] karasik.eu.org - Correspondence added
Subject: Re: [rt.cpan.org #90269] maximize by NET-WM message
Date: Fri, 22 Nov 2013 09:47:56 +0100
To: Kevin Ryde via RT <bug-Prima [...] rt.cpan.org>
From: Dmitry Karasik <dmitry [...] karasik.eu.org>
Show quoted text
> > No, not even change message, just how it works without map/unmap. I suspect that > > my comment "net hints changes by themselves do not result in maximization > > need explicit map/unmap" might just not be valid anymore in 2013.
> > I think from my reading of net-wm spec that a client shouldn't change > _NET_WM_STATE after the window is managed, that the property belongs to > the wm then. Which would explain your comment in the code, if that was > what you found didn't work.
That very well might be true, thank you. And explain some mystic behaviors I observed. Because I remember that I wrote direct hacking of _NET_WM_STATE when there were no wm spec yet (or I did bad job finding it), and the code that changes properties using XSentEvent came later; but direct hacking wasn't removed. I think I'll try to remove it then and ask you to test of that works on fvwm. Show quoted text
> > I'm not sure if I understand difference between "toggle" and "set to a particular state", > > what do you mean by that? Only send NET_WM_STATE change without map/unmap?
> A ClientMessage can ask for "ADD", "REMOVE" or "TOGGLE" of a state > (or two states).
Ah no, there's no such thing, prima uses only ADD and REMOVE -- Sincerely, Dmitry Karasik
  Fri Nov 22 03:53:19 2013 KARASIK [...] cpan.org - Correspondence added
Hi Kevin Here it is, can you please try it in your setups, and I'll try it under wms I can find. It works so far on metacity. /dk
Subject: patch
Download patch
application/octet-stream 2.4k

Message body not shown because it is not plain text.

  Sat Nov 23 20:02:29 2013 user42 [...] zip.com.au - Correspondence added
Subject: Re: [rt.cpan.org #90269] maximize by NET-WM message
Date: Sun, 24 Nov 2013 11:58:24 +1100
To: bug-Prima [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
"KARASIK via RT" <bug-Prima@rt.cpan.org> writes: Show quoted text
> > Here it is, can you please try it in your setups, and I'll try it > under wms I can find. It works so far on metacity.
Looks good. Works for fvwm, or rather it works but fvwm's non-compliance makes it do the fallback the same. Last time I tried metacity it wouldn't run without gnome, I'll have to see what I broke. I had a list of net/non-net wms somewhere ... -- "It's a long way to the shop if you want a sausage roll."
  Mon Jan 20 04:35:15 2014 KARASIK [...] cpan.org - Correspondence added
Here's at last I tested and committed the bigger patch that simplifies the logic, removes the hack with cmMinimize and hopefully works as intended. I'd very much like to ask you to test it in your setup as well. Thanks, Dmitry
  Tue Apr 01 13:58:55 2014 KARASIK [...] cpan.org - Status changed from 'open' to 'resolved'