I think, I am making progress. But I also think I have reached the end of
what I can do without breaking things. See the end of this message for a
patch that works but that is unlikely to be correct.

First, let's review what I have done, as that should shed some light on how
things are supposed to work.

I traced the code that gnome-panel executes. I looked at the source code
from http://anonscm.debian.org/pkg-mate/libwnck.git as downloaded by
"apt-get source libwnck3".

As far as I can tell, the code really only performs a single relevant X11
call (the rest is just boiler plate code):

   - item_activated_callback() at window-action-menu.c:167 calls
   - wnck_window_unminimize() at window.c:1506 calls
   - wnck_window_activate_transient() at window.c:2039 calls
   - wnck_window_activate() at window.c:1930 calls
   - _wnk_activate() at xutils.c:1058 calls
   XSendEvent(display, root,
   False, SubstructureRedirectMask|SubstructureNotifyMask,
     {
       type: ClientMessage,
       serial: 0,
       send_event: True,
       display: display,
       window: xwindow,
       message_type: atom_get("_NET_ACTIVE_WINDOW"),
       format: 32,
       data: { client_type(): 2, timestamp, 0, 0, 0 },
     });

Looking the specs at
https://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#idm140130317679168
that appears reasonable; and it is different from xdotool, which merely
maps the window without going through EXMH. That explains the difference in
behavior that I noticed yesterday.

Looking at the awesome source code, it handles an _NET_ACTIVE_WINDOW event
at ewmh.c:455. I traced that code as well, and it is emitting a signal
"request::activate" at ewmh.c:468. That signal is caught in ewmh.activate()
at ewmh.lua:107.

I added an extra line at the beginning of this function, unconditionally
setting

  c.minimized = false

That change does in fact fix the bug and I can unminimize windows. Very
cool! I fixed something :-) Unfortunately, it also unminimizes windows when
they shouldn't be (e.g. when reloading the window manager). So, clearly,
the patch needs to be a little more complicated than what I can do. But
hopefully, I have traced and documented things sufficiently that somebody
else can chime in now. I am afraid, a correct fix needs a better
understanding of awesome's internals.


Markus

On Sat, Apr 23, 2016 at 1:05 PM, Markus Gutschke <mar...@gutschke.com>
wrote:

> I am running "awesome git" now (after some struggles to fix my rc.lua;
> mostly my fault, and not 100% done quite yet). The behavior is unchanged. I
> also patched out 02be8943 just to see if it makes a difference, but it
> doesn't appear to.
>
> I don't know if you have access to a system running Xenial (or at least to
> a chroot environment). If you do, you could take a look at the source code
> for libwnck3-3.14.1, which you can get with "apt-get source libwnck". I
> believe, that's the code that runs when I try to (un)minimize a window from
> the gnome-panel (that only took forever to track down; GNOME has a funny
> way how it splits components into libraries that I wasn't previously aware
> of).
>
> Alternatively, I think you should be able to get the sources from "git
> clone git://anonscm.debian.org/pkg-mate/libwnck.git"
>
> I am starting to push the limits of my understanding how X11 works. So, I
> have a hard time reading that code. But I suspect it'll explain what GNOME
> is trying to do and if only I could wrap my head around it, I could
> probably see why this doesn't work with awesome. Maybe, you'll have better
> luck reading that code; but I'll keep trying.
>
> I think, you need to look at wnck_window_unminimize() and then follow the
> code.
>
>
> Markus
>
>
> On Sat, Apr 23, 2016 at 12:24 AM, Elv1313 . <elv1...@gmail.com> wrote:
>
>> Hello again,
>>
>> It indeed seems like a bug. Can you try to install either Awesome git
>> version or revert to something before commit 02be8943 (like 3.5.6 from
>> Ubuntu 15.10 package archive) and see what happen?
>>
>> Thanks for looking into this.
>>
>> On 23 April 2016 at 03:00, Markus Gutschke <mar...@gutschke.com> wrote:
>> > I am using GNOME in "fall back" mode. It gives me a gnome-panel and I
>> can
>> > add a task list to this panel.
>> >
>> > In the task list, it shows me an entry for all windows; both on-screen
>> and
>> > minimized. If I right-click on this entry, I get a pop-up menu that
>> allows
>> > me to select "unminimize". But if I select that entry, nothing happens.
>> >
>> > I tried installing both Cinnamon and MATE to see if maybe it had
>> something
>> > to do with the version of GNOME or of the GNOME tools that these
>> > environments pull in. But no matter which version of GNOME that I use,
>> the
>> > same thing happens:
>> >
>> > I can un-minimize just fine, if and only if I use the window manager
>> that
>> > comes with GNOME (i.e. metacity, marco, or compiz). But if I switch to
>> > "awesome" nothing happens.
>> >
>> > To make matters even more confusing, if I use "xdotool windowmap", then
>> I
>> > can restore the iconified window just fine. Of course, that's a horrible
>> > user experience, as you explained in your e-mail as well. I really need
>> some
>> > way to trigger this action from the user interface.
>> >
>> > I wonder what that task-list in the GNOME panel does that is suddenly
>> > incompatible with awesome but that works with other window managers?
>> >
>> > I tried looking at events with "xev". When I minimize the window, it
>> always
>> > receives these events:
>> >
>> >> PropertyNotify event, serial 20, synthetic NO, window 0x200088a,
>> >>     atom 0x137 (WM_STATE), time 27896361, state PropertyNewValue
>> >> UnmapNotify event, serial 20, synthetic NO, window 0x200088a,
>> >>     event 0x200088a, window 0x200088a, from_configure NO
>> >> PropertyNotify event, serial 20, synthetic NO, window 0x200088a,
>> >>     atom 0x109 (_NET_WM_STATE), time 27896361, state PropertyNewValue
>> >
>> >
>> > This happens independent of whether I press Mod-n, whether I minimize
>> from
>> > the gnome-panel, or whether I use "xdotool".
>> >
>> > But when I try to restore the window, the events differ. If I use
>> "xdotool"
>> > (or run with a window manager other than awesome), then these are the
>> > relevant events that I see:
>> >
>> >> PropertyNotify event, serial 21, synthetic NO, window 0x200088a,
>> >>     atom 0x137 (WM_STATE), time 28174332, state PropertyNewValue
>> >> MapNotify event, serial 21, synthetic NO, window 0x200088a,
>> >>     event 0x200088a, window 0x200088a, override NO
>> >> PropertyNotify event, serial 21, synthetic NO, window 0x200088a,
>> >>     atom 0x109 (_NET_WM_STATE), time 28174332, state PropertyNewValue
>> >> VisibilityNotify event, serial 21, synthetic NO, window 0x200088a,
>> >>     state VisibilityUnobscured
>> >
>> >
>> > In the same situation, running awesome and clicking on the task list, I
>> only
>> > ever see:
>> >
>> >> PropertyNotify event, serial 21, synthetic NO, window 0x200088a,
>> >>     atom 0x109 (_NET_WM_STATE), time 28217623, state PropertyNewValue
>> >
>> >
>> > Notice the absence of the change to WM_STATE.
>> >
>> >
>> >
>> > Markus
>>
>
>

Reply via email to