Re: Managed window title is screwed up
On Wed, Aug 16, 2000 at 11:00:49AM -0700, Alexandre Julliard wrote: > This was already discussed a few months ago; the right fix is to make > the window rectangle (returned by GetWindowRect) distinct from the X > window rectangle. Then the differences between the two rectangles can > be handled entirely in the x11drv, and all the rest of the code can > work with the window rectangle without worrying whether the window is > managed or not. Ah yes, I remember now... Huw. -- Dr. Huw D M Davies | Clarendon Laboratory [EMAIL PROTECTED] | Parks Road Tel: +44 1865 272390| Oxford OX1 3PU Fax: +44 1865 272400| UK
Re: Managed window title is screwed up
Patrik Stridvall <[EMAIL PROTECTED]> writes: > The problem concerning what should we do with draws in the non > client area is still unsolved. At least unless you consider > sending them to /dev/null (clipping them) as a solution. I do, and I think it's the only sane solution. If you want to see what the application draws in the caption you should use non-managed mode. I really don't see any other reasonable possibility. -- Alexandre Julliard [EMAIL PROTECTED]
RE: Managed window title is screwed up
> Huw D M Davies writes: > > > Well what's happening is that in managed mode GetDCEx( DCX_WINDOW) > > gets a dc with its top starting at the bottom of the window > > decoration. The apps assumes that the top is the top of the caption > > and starts drawing on it, so everything appears a caption height too > > low. Maybe what we should do is to set dc->OrgY to > -(caption height). > > This was already discussed a few months ago; the right fix is to make > the window rectangle (returned by GetWindowRect) distinct from the X > window rectangle. Then the differences between the two rectangles can > be handled entirely in the x11drv, and all the rest of the code can > work with the window rectangle without worrying whether the window is > managed or not. Well. That solves only part of the problem. A very important part for some applications but it still doesn't solve all applications problems. The problem concerning what should we do with draws in the non client area is still unsolved. At least unless you consider sending them to /dev/null (clipping them) as a solution. When we have decided what to do the more difficult problems HOW and WHERE still remains.
Re: Managed window title is screwed up
Huw D M Davies <[EMAIL PROTECTED]> writes: > Well what's happening is that in managed mode GetDCEx( DCX_WINDOW) > gets a dc with its top starting at the bottom of the window > decoration. The apps assumes that the top is the top of the caption > and starts drawing on it, so everything appears a caption height too > low. Maybe what we should do is to set dc->OrgY to -(caption height). This was already discussed a few months ago; the right fix is to make the window rectangle (returned by GetWindowRect) distinct from the X window rectangle. Then the differences between the two rectangles can be handled entirely in the x11drv, and all the rest of the code can work with the window rectangle without worrying whether the window is managed or not. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Managed window title is screwed up
On Wed, Aug 16, 2000 at 04:42:04PM +0300, Veksler Michael wrote: > That was the general feeling. In that case there are several questions: > 1. What should be done when a client is writing to a non-client area? >It is wrong to put it in the client area (the way it is done now). >Your suggested hack works when the string is few pixels above the >client area, but is makes no sense when it is below. Well what's happening is that in managed mode GetDCEx( DCX_WINDOW) gets a dc with its top starting at the bottom of the window decoration. The apps assumes that the top is the top of the caption and starts drawing on it, so everything appears a caption height too low. Maybe what we should do is to set dc->OrgY to -(caption height). At least this should hide the draw attempts to the caption. If the app used SetWindowText in the first place we wouldn't have this problem ;) Huw. -- Dr. Huw D M Davies | Clarendon Laboratory [EMAIL PROTECTED] | Parks Road Tel: +44 1865 272390| Oxford OX1 3PU Fax: +44 1865 272400| UK
Re: Managed window title is screwed up
Hi Veksler, Right now there is no way to write over the decorations provided by the windows managers and since many flavors of window managers exist, I think that's something we shouldn't try to do. > That was the general feeling. In that case there are several questions: > 1. What should be done when a client is writing to a non-client area? >It is wrong to put it in the client area (the way it is done now). >Your suggested hack works when the string is few pixels above the >client area, but is makes no sense when it is below. In managed windows, there are still some parts of the non-client area to which we can write (the menu bar for example). Only the decoration provided by the window manager (caption, border) are not accessible. This can be a problem because a managed Wine window starts just below the window managers decorations. However, this keeps the code a lot more simple :) > 2. Whose responsibility it is to recognize this non-client area writing? >Is it x11drv, GDI32 or USER32 ? >I guess that x11drv since it is the part that knows what managed >and unmanaged is, right? Yes, that's the x11drv part, however this knowledge is also shared throughout the Window structure using the WIN_MANAGED flag. > 3. How to detect this kind of non-client area writing in a clean way? >Is there a call to do this? >I guess this one I'd have to dig out of the code and the X11 docs. At the current time, you can check at the Wine level if a windows has decoration with the flag WIN_MANAGED (wndPtr->flags & WIN_MANAGED). Jean-Claude Batista Macadamian Technologies.
RE: Managed window title is screwed up
> > So it's writing this to the non-client area directly.I can't see how > > managed mode will ever support this.You'd somehow have to hack > > GetDCEx to return a special dc if we want a DCX_WINDOW dc.This dc > > would have to trap attempts to draw stuff to the non-client area and > > somehow persuade the Window Manager to draw them... > > > > That was the general feeling. In that case there are several > questions: > 1. What should be done when a client is writing to a non-client area? >It is wrong to put it in the client area (the way it is done now). >Your suggested hack works when the string is few pixels above the >client area, but is makes no sense when it is below. [Assuming above means outside and below means in] What do you mean? Huw's suggestion makes perfect sense. It just a little hard to implement. See below. > 2. Whose responsibility it is to recognize this non-client > area writing? >Is it x11drv, GDI32 or USER32 ? >I guess that x11drv since it is the part that knows what managed >and unmanaged is, right? As far as the USER32 is concerned the non-client area is just another drawing area so from some point of view it should, as you say, be handled in the x11drv. However, perhaps (I'm not sure) USER32 should detect whether it draws in the client area or not and pass on this information the underlying driver somehow since there might be more drivers (MacOS X?) in the future that will have the same problem. Besides doing it only in the X11DRV forces doing some tricks it in the GDI part of it, which probably is not that good. > 3. How to detect this kind of non-client area writing in a clean way? >Is there a call to do this? >I guess this one I'd have to dig out of the code and the X11 docs. The problems in that the application is not really writting in the non-client area it is writting in the window area which consist of the client area and the non-client area. There is nothing preventing the application from writting in both the client and the non-client area with the same GDI32 API call. The more I think about it the more I'm inclined to believe that Huw's suggestion concerning a special DC for DCX_WINDOW is the only way to handle this in a reasonable way. Implementing this will not be easy however. OK it will not be that hard but it will take a lot of time, especially if we are to implement support for drawing in both client and non-client with one GDI32 call. However that can wait, most applications will probably work with a simple one or the other "multiplexing". Of course the problem of actually drawing in the X Window frame remains but that is a completely orthogonal problem, that I can't help you with.
Re: Managed window title is screwed up
On Wed, 16 Aug 2000, Huw D M Davies wrote: > On Wed, Aug 16, 2000 at 03:48:35PM +0300, Veksler Michael wrote: > > > > Trace of user32 relay: > > Call user32.171: DrawTextA(0b78,406e5754 "Cut to the >Clipboard",,406e58d8,) ret=00916e3b fs=008f > > Retuser32.171: DrawTextA() retval=000e ret=00916e3b fs=008f > > So it's writing this to the non-client area directly.I can't see how > managed mode will ever support this.You'd somehow have to hack > GetDCEx to return a special dc if we want a DCX_WINDOW dc.This dc > would have to trap attempts to draw stuff to the non-client area and > somehow persuade the Window Manager to draw them... > That was the general feeling. In that case there are several questions: 1. What should be done when a client is writing to a non-client area? It is wrong to put it in the client area (the way it is done now). Your suggested hack works when the string is few pixels above the client area, but is makes no sense when it is below. 2. Whose responsibility it is to recognize this non-client area writing? Is it x11drv, GDI32 or USER32 ? I guess that x11drv since it is the part that knows what managed and unmanaged is, right? 3. How to detect this kind of non-client area writing in a clean way? Is there a call to do this? I guess this one I'd have to dig out of the code and the X11 docs. Michael
Re: Managed window title is screwed up
On Wed, Aug 16, 2000 at 03:48:35PM +0300, Veksler Michael wrote: > Here is a trace of an attempt to put "Cut to the Clipboard" on the title. > I am not sure if it is from managed or unmanaged (they both seems to have > the same values). > > Trace of user32 relay: > Call user32.171: DrawTextA(0b78,406e5754 "Cut to the >Clipboard",,406e58d8,) ret=00916e3b fs=008f > Ret user32.171: DrawTextA() retval=000e ret=00916e3b fs=008f So it's writing this to the non-client area directly. I can't see how managed mode will ever support this. You'd somehow have to hack GetDCEx to return a special dc if we want a DCX_WINDOW dc. This dc would have to trap attempts to draw stuff to the non-client area and somehow persuade the Window Manager to draw them... Huw. -- Dr. Huw D M Davies | Clarendon Laboratory [EMAIL PROTECTED] | Parks Road Tel: +44 1865 272390| Oxford OX1 3PU Fax: +44 1865 272400| UK
