New subject: desktop mode again

28 Jan 2004

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?

...
  I guess we need test cases for those then.
 The way I see it the only way around the problem of inter-process graphics operations is
for us to have our own DIB engine and move functions calling WIN_FindWndPtr into the
server. 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?

...
  @@ -128,7
+129,14 @@
  */
 BOOL WINAPI PaintDesktop(HDC hdc)
 {
-    HWND hwnd = GetDesktopWindow();
+    HWND hwnd;
+    SERVER_START_REQ( set_desktop_window )
+    {
+        req->handle       = 0;
+        wine_server_call( req );
+        hwnd = reply->cur_handle;
+    }
+    SERVER_END_REQ;

     /* check for an owning thread; otherwise don't paint anything (non-desktop mode)
*/
     if (GetWindowThreadProcessId( hwnd, NULL ))  

 Is there some reason for replacing GetDesktopWindow with this server call? 
Yes.  The problem is that the winedesktop app thinks the "root" X window 
is the desktop, while all other apps think the window winedesktop 
created is the desktop.  For convenience, winedesktop is just calling 
PaintDesktop when appropriate.  I did not want to just copy the body of 
that function into winedesktop because it depends on other variables in 
the file where it is located.  I guess the alternative would be to have 
the set wallpaper, set pattern, and paintdesktop functions simply send a 
message to the winedesktop process (if it's running), which would then 
contain the implementations.  If that sounds more reasonable I can 
certainly change it to that way.

...

+/***********************************************************************
+ *           BecomeDesktop
+ *
+ * Tell the server to make our window the desktop.  
+ */
+static BOOL BecomeDesktop()
+{
+    BOOL res = TRUE;
+    SERVER_START_REQ( set_desktop_window )  

 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). 
I guess I have no opinion about whether it would be worse to create a 
new export or just call the server.  I was not happy about doing either, 
but I am not aware of anything in the "real" API that would do this. 
This application is not really "normal" anyway.  I see it more as an 
extension of x11drv.

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

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

Alex

Re: desktop mode again