Package: gksu Version: 1.2.2-1 gksu executes an X server grab - even though it is MANAGED by a window manager. a window manager is another client. if you grab the xserver you lock the window manager and every other x client OUT. the wm cannot display the window - ti cannto move it, resize or do anything (or even give it focus) as gksu grabs x. it effectively locks up the entire display until u go to a console and kill gksu. the reason i am reporting this is it is just incorrect behavior entirely. from a design ploint of view you cannot lock out the wm and expect your window to display/work. if you want to grab the xserver bypass the wm and use an override-redirect window for your main window. then this problem wont occur (as you bypassed the wm entirely). as long as you create a normal managed window you cannot grab the xserver and just sit and wait - no matter how paranoid about security you are as it simply doesn't work within x's design (if it has worked in the past its a race condition that you are LUCKY it works for some people). (btw this will be the cause of those other kde lockup and gnome-session startup block bug reports) anyway - just fyi i'll explain a bit how x works and wm's etc. an app requests to show its window - this requests gets redirected to another x client (the wm) which then actually shows the window (adding borders, moving, resizing etc.). if you grab the xserver display - you lock out ALL clients except this one - INCLUDING the wm - that means if u try show, hide, move, resize etc. your window the wm CANNOT do it. x wil still redirect all the show, resize, move et.c requests -b ut they will just get queued for the wm to deal with then the grab is over. the thing is its all client-server and asynchronous, so the wm may still be DOING things after u have asked to be shown or resized. it may do it in multiple steps by changing desktop,s hiding other windows and more. the wm is the one that chooses what to do and how to do it - your requests are merely hints to it. so back to the grab problem. you grab the x display but the wm may still be in the middle of drawing window borders, or re-arranging windows to make room for yours etc. when you do this. it may be that your window is not visible or accessible yet and thus seemingly everything locks up. :) :) i suggest the DEFAULT setup for gksu is to NOT grab the xserver, and IF it is turned on, do NOT use a managed window - bypass the wm and create an unmanaged override redirect window. otherwise i can GUARANTEE gksu will have bugs on multiple system in multiple wm's all the time and there is nothing the wm can do about it. :) imho this is a grave functionality bug as it is a major design flaw that can seemingly lock up an entire machine (unless u ssh in or go to a console and investigate and are smart enough to know to killall gksu as that is the problem) :) (NB - i am referring to grabbing the xserver, not grabbing the keyboard and mouse which imho is just fine and reasonable security measures) :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
