On Tue, 01 Jul 2014 11:17:28 +0200 Martin Gräßlin <mgraess...@kde.org> said:
> On Tuesday 01 July 2014 18:04:10 you wrote: > > On Tue, 01 Jul 2014 10:40:04 +0200 Martin Gräßlin <mgraess...@kde.org> said: > > > thanks for the feedback. Addressed both and new patches attached. > > > > i think that's missing lots of data, and background. > > > > looking at this, my guess is that this is for client-side decorations. but > > then you are missing lots of data. > > > > 1. for wm window menu, not just x,y but also the rectangle withint he client > > window that triggered the action should be supplied. this allows the menu > > to be aligned right below the button that triggered it. nice and cleanly. > > without this info the menu has no choice but to appear where the mouse is > > which may be anywhere inside the button/widget that was clicked > > I think this is already covered: "the Client should set it to useful values > the window manager can use to position the menu". This could be extended to > say that it should also be used for the case that a button was clicked. If > the client sets it to the proper position I don't think that we actually need > the complete rect. Do you think that would be sufficient? examples: imagine the button is 300px wide. the menu is only 100px wide... the wm might want to make the menu 300px wide to nicely match the button it appeared from. given just am x/y point... where is that point? what if the menu is 500 px tall? most menus will then want to flip direction - pup UP the screen not down. there is only one point.. is this the top-left of the button? the middle? top-right? bottom-left? bottom-right? how could the wm usefully display the menu so it positions correctly and pops up in the right direction? (animations included)? like your "start" button will pop the menu in a different dir if its along the bottom, top, left or right part of the screen. to determining the x,y popup point the app would need menu dimensions to know if it would fit or not... if it doesnt have this in advance, the best you can do is provide the entire region that is involved in popping the menu up and leave it to the wm menu code to do the sensible thing. oh while i'm at it. a message back to app indicating the rect of the menu so the app could draw an arrow pointing the right direction etc. would be good. > > > > 2. button action gives no hint as to what the action might be. example - we > > double-clikc the titlebar. in some wm's this shades/unshades the window. in > > others it maximizes/unmaximizes. the info here provides no information that > > would indicate to the wm that we double-clicked the titlebar as titlebar may > > be along the left side of the window or along the bottom. no idea. > > Right, I didn't think of double click. Hmm I'm wondering how we could > indicate a double click given that we already use all five data elements. The > only idea I have is using a bit mask to indicate that a double click was > used. But I don't like that ;-) Any better ideas? not just double click... but WHERE semantically? double-click on titlebar? on close button? on maximize button? on a dog? :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org https://mail.gnome.org/mailman/listinfo/wm-spec-list
