Re: Still need a hint for undecorated windows

[Carsten Haitzler (The Rasterman) <raster rasterman com>]

On Fri, 01 Jul 2005 13:33:20 +0100 Mike Hearn <mh codeweavers com> 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)    raster rasterman com
裸好多                              raster deephackmode org
Tokyo, Japan (東京 日本)