desktop mode again
R.J.Shearman at warwick.ac.uk
Fri Jan 30 11:02:29 CST 2004
Alex Pasadyn wrote:
> Robert Shearman wrote:
> > I suggest you put the system metrics stuff in a separate patch.
> It is a lot more tested and more likely to get in than the other
> code, which is quite a big change.
> I can do that, if it would get applied. :) I sent an earlier version
> of the sysmetrics patch by itself a long time ago, and it was not
> applied because it could give incorrect results in desktop mode. This
> version is cleaner that that one, and I think that by itself it would at
> least give correct results for an application running in the one desktop
> that changed its size. So, Alexandre? Is that worth sending?
How about a quick hack doing the same as we do now if the user wants desktop
mode, but use the new code otherwise? Then if a version of this patch gets
applied you can remove that hack.
> X doesn't allow inter-process operations right?
> Actually, I think X doesn't care. It has no problem with me having one
> process create the desktop window and another process creating a
> "normal" window inside it. Or did you mean something else?
> > This is bad. There shouldn't be a direct server call in a
> > normal wine program. We should try and find the right Windows API
> > to do this, or create our own export from user32. Only user32,
> > gdi32, ntdll and x11drv should need to use server calls (and
> > kernel32 out of convenience).
It has just occurred to me that CreateDesktop and SwitchDesktop are the
functions to use, but that means writing a lot of extra code.
> > Why do you need two windows procedures? If you're sure you do
> need both of them, a comment in the code explaining why would be
> good. It's not at all obvious to the casual observer (i.e. me) otherwise.
> That I can add. The basic thing is that the "main" window created by
> winedesktop is just a normal ordinary window, and it can be minimized,
> etc. The child window came in because an app should be able to ask for
> the size of the desktop window and always get the right answer. I
> thought it was better to create a child window than to have to put code
> in the server to intercept calls to get the size of the desktop and
> fudge the results if it was minimized.
Ok, that sounds sensible.
> > It appears you don't launch winedesktop anywhere and you don't
> > remove any options from the config file. It will be a bit
> > confusing for people who do use the wine desktop when it doesn't
> > do anything after applying your patch (until they launch
> > winedesktop). Do you plan to launch winedesktop at startup
> > (possibly just after wineserver is launched) if the desktop
> > setting is enabled?
> This was described when I originally posted a version of this a long
> time ago. The general idea is that if no other Wine apps are running,
> you can start winedesktop.
I still think it would be a good idea to launch it for them automatically.
> While it's running, all Wine apps that get
> started get trapped inside the desktop. I would like to find a way to
> have multiple desktops or desktop coexisting with non-desktop, but that
> would be a ton of additional bookkeeping in the server.
We can adapt the multi-monitor APIs to do this. However, Windows doesn't
support multiple independent desktops, but there are probably was around
More information about the wine-devel