Re: Sawfish 2.0 compilation problems

[Grzegorz Nieweglowski <hoppke go2 pl>]

aaditya sood nawypisowywał(a):
>> same for me. As of now, I adopted the "solution" suggested on the
>> bugzilla page: make a key shortcut for 'Restart'... deceiving
>> though...
> 
> I got this little snippet from somewhere... After putting this in my
> .sawfishrc file that error disappeared.
> 
> ;; fix the "Error: menu already active" bug
> (define-special-variable menu-program-stays-running nil)

I stumbled upon the very same bug, so I changed to CVS Sawfish, hoping
for the best :). But the only difference is that it doesn't complain
about "menu already active" that often (but the frequency of this bug
remains the same)

More details I've noticed:

a. It isn't mouse-specific. I have the window list bound to the "Menu"
key (windowish keyboard layout), and it gets ignored just as often.
Shuffling mouse buttons around also doesn't fix the problem. It's an
overall binding problem.

Note: Other commands can be bound to those shortcuts and they will work
fine. So it seems to show up only in connection with the gtk menu
process.

b. Somehow, the "root menu" can always be displayed, no matter what
keystroke/mousestroke I bind it to. This bug seems to only affect
other menus, like the apps menu or window list. Also: displaying the
root menu seems to "fix" the problem for a while (other menus start to
work as expected, at least temporarily).

Commands run from sawfish-client are never affected by the bug. So
typing "(popup-apps-menu)" in sawfish-client breaks the "menu freeze"
100% of the time. Maybe it gets executed in a different "lisp
environment"?

c. It seems that the cause of this "menu freeze" is somehow window
related. Or connected to altering the window list? It seems to happen
just after new windows are opened (or existing windows closed), at least
on my system. Sometimes switching to a different desktop fixes the
situation.

d. The only "fix" that I know of is killing the menu process somehow,
like "killall sawfish-menu", preferably bound to a keystroke.

Or you can indeed set "menu-program-stays-running" to "nil", but this
can cause a noticable delay when bringing up menus on slower machines.
And these are plain ugly hacks, not real fixes :( 

e. The key to the problem would be finding out why the hell the
popup-root-menu command is *never* affected by this bug (at least in CVS
sawfish), while popup-apps-menu or popup-window-menu get blocked. And
why menus work perfectly when called from sawfish-ui, but break when
called via mouse/keyboard bindings. And why no other sawfish command
seems to suffer from this bug.

My config (just in case):
atk-1.2.4, glib-2.2.3, pango-1.2.5, gtk+-2.2.3, rep-gtk-0.18, sawfish-CVS.

There are some other minor bugs I've noticed, but this one is certainly
the biggest joy-killer :(

Any clues?

-- 
\hoppke
(Grzegorz Nieweglowski)
http://lubuska.zapto.org/~hoppke/