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