Re: Client messages _NET_WM_SHOW_WINDOW_MENU and _NET_WM_PERFO RM_BUTTON_ACTION



On Mittwoch, 2. Juli 2014 09:54:57 CEST, Martin Gräßlin wrote:

There is no use if that gets that complex, that nobody implements it ;-)

While that's certainly true, I fear the nature of the matter includes some complexity. There's no point in providing a 
protocol that requires huristics on either side to "work as expected" either :-(

One cannot do this with the idea of an "interim solution until gtk+ stops this nonsense" - as, even in that 
case, the spec would still remain.

If CSD is to be included into NETWM, it shall be done proper. This was and is my biggest complaint on the 
rather hackish gtk+ approach - now I cannot drop behind that, sorry ;-)


Notes on the last version:
--------------
* why does _NET_WM_TITLEBAR_ACTION require root_x/root_y?
 we cannot map it to anything special inside the titlebar anyway.
* "Button takes the special value of 0 which indicates a LEFT BUTTON double click on the title bar area.", 
but we can now probably use one of the position fields as flag (also to pass the modifiers, ie. alt, ctrl, meta)?
* The other field could be used to specify the deco element (button), eg. at least KWin maximize acts 
differently for different buttons - the CSD could defer handling the button to the WM to keep this consistent 
among all clients.


For _NET_WM_SHOW_WINDOW_MENU
* root_x/root_y should really specify explicitly invalid values that are not treated as position request
* I support Carstens point about sending a rect to align the menu to. This will be required if the menu 
cannot be spawned below the button - something the client cannot know. (The menu must not cover the button 
that triggered it)
I don't think we'll require an anchor for the rect, but can seek to spawn the dialog preferably inside the clients 
geometry (ie. if the target rect is on the top left of the client, the popup shall be bottom left aligned - it's never 
"next to" the titlebar, since the entire point of CSD is that there is no titlebar)
 Unfortunately this may require x/width to cover the first 16 and y/height the last 16 bits of data.l[1|2] | 
root_x, root_y, width, height > 0

data.l[1] = (root_x << 16) | (root_y & 0xffff)
data.l[2] = (width << 16) | (height & 0xffff)

root_x = (data.l[1] >> 16) & 0xffff;
root_y = data.l[1] & 0xffff;
width = (data.l[2] >> 16) & 0xffff;
height = data.l[2] & 0xffff;


Cheers,
Thomas


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