On Fri, 01 Jul 2005 13:33:20 +0100 Mike Hearn <[EMAIL PROTECTED]> babbled:
> On Fri, 2005-07-01 at 10:15 +0900, Carsten Haitzler wrote: > > list them! :) > > Yep, we have a wiki page for it: > > http://wiki.winehq.com/WindowManagerExtensions aah werd to that! i see one of them we have been discussing (borderless) - i think we kind of resolved that... as for the other one: " Possible interactions with focus stealing prevention ???" I assume that means you would like a managed window to be able to have the focus and it never be taken away until the app says its ok? > There isn't much there right now, we're still trying to convince AJ (the > window management guru) that at some point it might be worth adding > things to window managers instead of constantly working around their > quirks like we do now, but he isn't sure :) i think that's the best way to go. detect if the wm handles what u want without bugs and use the clean way, otherwise hack - or just dont bother with the hack and lets all discuss it to make sure it happens. > > while we're at it... personally i'd like a request from wine - set the name > > and class to something about the app - maybe the exe? so its not always > > "wine" "Wine" :) > > That shouldn't be too hard. definitely not :) > > also the whole decoration and window positioning doesn't quite work > > right. > > Tell us about it :) Mapping Win32 WM to X is a huge pain, especially as > some WMs ignore or buggily implement various hints. The basic issue is > that Win32 gives you much less control than X does and so some WMs > interfere with what the apps expect. Right now we deal with that by > using lots of OR windows and we have some evil heuristics to guess what > the window type should be in advance. Needless to say this code is very > fragile and gets it wrong frequently. yeah - also win32 and x fundamentally have different window management models. win32 apps manage themselevs basically - the app itself defines the outer frame boundaries, frame width, title, buttons, handles the input events and moves/resizes its own window etc. very different to x. > > in wine - well i recently noticed that WoW likes to remember its location > > but always gets it off by a window border frame width + height (x and y > > accordingly). not sure if this is just the way the app works - no source, > > but wine should adjust for the frame size when sending configurenotify > > events back to the app (can't remember the win32 event message it was) but > > it should use the _NET_FRAME_EXTENTS, or older > > _E_FRAME_SIZE (same format) that e16 set long ago, and/or use the netwm > > frame size request protocol to try guess how fat your frame will be before > > you map :) > > Yeah we don't use _NET_FRAME_EXTENTS or anything like that right now. definitely should. i wish java used it too - they do equivalently nasty hack s- but the results of their hacks going wrong is much more severe than any i have seen from wine - like apps simply not redrawing or making their windows 4 times their intended size etc. :( > > anyway - noticed this on WoW, and as its just about the only windows app i > > have run recently through wine... i can't say if its Wow being just stupid - > > or too smart for its own good, or a "hole" in the Wine logic :) > > Probably a combination of all three, that's the way it usually goes ;) i can imagine. it's a hard thing to make work right. :( i don't envy you. i definitely think it'd be better if we worked together though instead of lets say you hacking around wm's then wm's having to then hack around you... :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) _______________________________________________ wm-spec-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/wm-spec-list
