Re: [DECISION] Two pending patches



Hi.

On Tue, 03 Mar 2009 18:44:19 +0200, Timo Korvola wrote:
> Christopher Roy Bratusek <zanghar freenet de> writes:
> > http://sawfish.wikia.com/wiki/Clean-up_for_Zimmerman's_iconify_patch
> >
> > As far as I understood Teika, that patch is not complete now.
> 
> Well, r4373 was a mistake and should be reverted.  Beyond that it is
> not quite easy to see what would be the right thing here.
> 
> I took a brief look at how iconify-window-hook and
> window-state-change-hook are currently being used in Sawfish (no idea
> if any separately distributed code uses them).  I am beginning to
> think that neither hook should be called when a window starts as
> iconic.  I think Teika is on the right track in modifying add_window
> to check for the IconicState hint but perhaps one should not use
> iconify-window there because it calls the hooks.  In any case it feels
> wrong to call those hooks before add-window-hook.

Let me clarify facts, after a cycle of comments. 

1. The aim of Zimmerman's patch (rev 4373) is to iconify newly mapped
window, following StateHint *before* window matching. My patch
preserves it. Future enhancement in matcher will benefit from it, but
it does not provide any immediate cure.

2. Zimmerman's one introduced a bad piece of code, by using
XIconifyWindow. My patch fixes it.

3. My patch does not change hook call issue, compared to the original
code before Zimmerman's patch.

4. Strictly speaking, my patch brings in a new subtlety in hook
behavior; it is now called before the window set up is complete.
 I guess it's ok, because right after iconify-window in my patch,
matcher is called via before-add-window-hook, and iconification by
matcher is ok.
 My patch seems to work without problem. I say it from what I see on
the screen, but investigation in the internal is not done. It's beyond
my skill.

So, if the prob 4 is ok, my patch is a slight improvement to the
original. Thus, I propose that we adopt my patch after testing, and
solve the hook issue later.


Finally let us pick up the hook problem. As long as only my patch is
concerned, it's easy to supress invocation of iconify-window-hook and
window-state-change-hook, with an introduction of familiar defvar -
let pair.

But this is not the whole story. Right after iconify-window in my
patch, before-add-window-hook and add-window-hook are
called. Functions there, at least matcher, probably call cousins of
window-state-change-hook. The real fix should cover this problem.

How about recording this issue and postpone it for now? It's a real
challenge.

Thank you for reading. Last but not least, thank you, Timo, again for
your analysis.

Bye,
Teika (Teika kazura)



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]