desktop mode again

[Robert Shearman]

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
this.

Rob