Alex Pasadyn ajp@mail.utexas.edu writes:
This patch just puts in a simple check that traps this condition so Wine doesn't crash. I don't know enough about what that code is supposed to be doing to fix it properly. (This is certainly better enough on my system though as it longer crashes!) If someone wants to describe what "should" happen there I can look into really fixing it.
The real problem is that we create one X desktop window in each process, while there is only one desktop window in the Windows sense. So anything that depends on the X desktop window to be shared is broken. The right fix is to manage the X desktop in a separate process.
Alexandre Julliard wrote:
Alex Pasadyn ajp@mail.utexas.edu writes:
This patch just puts in a simple check that traps this condition so Wine doesn't crash. I don't know enough about what that code is supposed to be doing to fix it properly. (This is certainly better enough on my system though as it longer crashes!) If someone wants to describe what "should" happen there I can look into really fixing it.
The real problem is that we create one X desktop window in each process, while there is only one desktop window in the Windows sense. So anything that depends on the X desktop window to be shared is broken. The right fix is to manage the X desktop in a separate process.
wouldn't something like Xnest help here ? A+
Eric Pouech pouech-eric@wanadoo.fr writes:
wouldn't something like Xnest help here ?
Yes, it would be one way to implement it (and arguably it's the right way in an X environment, there's no reason for Wine to duplicate that functionality). I'm not sure how well Xnest supports X extensions and hardware acceleration, though that could probably be fixed. The other problem is that it will cause us to create X windows on different displays within the same hierarchy, and this doesn't work correctly at this point. But it's something that will have to be fixed anyway.
On Mon, 2003-09-29 at 21:18, Alexandre Julliard wrote:
Eric Pouech pouech-eric@wanadoo.fr writes:
wouldn't something like Xnest help here ?
Yes, it would be one way to implement it (and arguably it's the right way in an X environment, there's no reason for Wine to duplicate that functionality).
Do we really want a dependency on Xnest, which is usually not installed by default on most distributions (and is quite large i think)?
I'm not sure how well Xnest supports X extensions and hardware acceleration, though that could probably be fixed.
IIRC it does not support Xrender at all.
The other way would be to extend managed mode so we don't need to use Desktop mode for InstallShield (which is the primary offender). I find simply setting the default mode to managed makes most of them work but of course that probably breaks some other apps. What is the reason for unmanaged to be the default (in is_window_managed)?
thanks -mike
Mike Hearn mike@theoretic.com writes:
Do we really want a dependency on Xnest, which is usually not installed by default on most distributions (and is quite large i think)?
I don't think that's a problem. If you want desktop mode you can install Xnest.
IIRC it does not support Xrender at all.
Yes that would need to be fixed.
The other way would be to extend managed mode so we don't need to use Desktop mode for InstallShield (which is the primary offender). I find simply setting the default mode to managed makes most of them work but of course that probably breaks some other apps. What is the reason for unmanaged to be the default (in is_window_managed)?
The default is managed mode, and has been for a long time now.
On Tue, 2003-09-30 at 18:13, Alexandre Julliard wrote:
The default is managed mode, and has been for a long time now.
I'm confused then -
[mike@littlegreen x11drv]$ cvs diff window.c Index: window.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/window.c,v retrieving revision 1.57 diff -u -r1.57 window.c --- window.c 5 Sep 2003 23:08:26 -0000 1.57 +++ window.c 30 Sep 2003 19:57:35 -0000 @@ -90,7 +90,7 @@ if ((win->dwStyle & WS_CAPTION) == WS_CAPTION) return TRUE; if (win->dwStyle & WS_THICKFRAME) return TRUE; /* default: not managed */ - return FALSE; + return TRUE; }
is_window_managed returns false if none of the conditions match. Is it the case that one of the conditions will always cause it to return true?
Mike Hearn mike@theoretic.com writes:
is_window_managed returns false if none of the conditions match. Is it the case that one of the conditions will always cause it to return true?
For windows that need to be managed yes. Even in managed mode there are some windows that are never managed, like menus, tooltips, etc. That's what is_window_managed is for.
On Tue, 2003-09-30 at 21:13, Alexandre Julliard wrote:
For windows that need to be managed yes. Even in managed mode there are some windows that are never managed, like menus, tooltips, etc. That's what is_window_managed is for.
I suppose the problem then is that we can't figure out how a fullscreen install window is different to a menu or tooltip window. Perhaps in future they too could be managed but with the appropriate hints to switch off window decorations, appearing in the window list etc.
Mike Hearn mike@theoretic.com writes:
I suppose the problem then is that we can't figure out how a fullscreen install window is different to a menu or tooltip window. Perhaps in future they too could be managed but with the appropriate hints to switch off window decorations, appearing in the window list etc.
Well yes that's the plan, the problem is that it requires being able to switch a window to managed on the fly, and that's a bit tricky to do right. I'm planning to work on that once I'm done with the $%#@$ dll separation and glibc stuff.
IIRC it does not support Xrender at all.
Yes that would need to be fixed.
Well, the biggest problem would be how to have direct rendering for GL in a Xnest environment. I have absolutely no idea if this is possible without hacks.
And then you would also need to add RandR support to Xnest to have the recent Desktop resize option working.
Lionel
On Tue, 2003-09-30 at 18:13, Alexandre Julliard wrote:
I don't think that's a problem. If you want desktop mode you can install Xnest.
Another alternative would be to merge in Keith Packards pseudo-root extension:
http://keithp.com/~keithp/talks/proot.tar.gz
Unfortunately it's not currently in XFree but apparently would be easy to merge in. At some point if a Wine hacker feels like branching out ... :)
On 30 Sep 2003, Mike Hearn wrote:
future they too could be managed but with the appropriate hints to switch off window decorations, appearing in the window list etc.
It certainly be nice to defer the window management to ... the window manager :) Maybe we can start with a list of hints that we need in order to do that. Once we have the list, we can approach the freedesktop.org people for integration in the standard. Would that also solve our InstallShield problems? In fact, what kind of problems do we have with InstallShield?
Another alternative would be to merge in Keith Packards pseudo-root extension:
Any idea why he did not get it integrated?
On Tue, 2003-09-30 at 21:57, Dimitrie O. Paun wrote:
In fact, what kind of problems do we have with InstallShield?
It attempts to do window management across two different desktop windows causing an X11 ConfigureWindow error. We can't run it outside of desktop mode because the big blue window becomes unmanaged and you can't switch to the main installer window.
Another alternative would be to merge in Keith Packards pseudo-root extension:
Any idea why he did not get it integrated?
So much to do, so little time to do it.....
Mike Hearn wrote:
On Tue, 2003-09-30 at 21:57, Dimitrie O. Paun wrote:
In fact, what kind of problems do we have with InstallShield?
It attempts to do window management across two different desktop windows causing an X11 ConfigureWindow error. We can't run it outside of desktop mode because the big blue window becomes unmanaged and you can't switch to the main installer window.
So what about the patch I submitted that started this discussion? It certainly prevents the ConfigureWindow call from crashing Wine (at least for the cases I tried). I realize it's not addressing the root problem, but I think it's at least a better situation than crashing.
Longer term, I think the ideal solution is to get all the priority and input focus issues worked out so all the windows could just get managed by the window manager. (That's what it's there for!) I would like to help with this, but I need to better understand what the issues are. There are certainly native X applications that create oddly shaped windows without WM decorations that don't confuse the window manager at all. Are Wine apps needing to do something that's not supported or is it just a matter of fixing Wine?
Then, at that point, what would be really slick is if the Wine desktop could be a separate process that you run when you want to confine a specific app (and all its subprocesses) to a smaller space (e.g. winedesktop -size 800x600 -- myapp.exe).
-ajp
"Dimitrie" == Dimitrie O Paun dimi@intelliware.ca writes:
Dimitrie> On 30 Sep 2003, Mike Hearn wrote: >> future they too could be managed but with the appropriate hints to >> switch off window decorations, appearing in the window list etc.
Dimitrie> It certainly be nice to defer the window management to ... the Dimitrie> window manager :) Maybe we can start with a list of hints that Dimitrie> we need in order to do that. Once we have the list, we can Dimitrie> approach the freedesktop.org people for integration in the Dimitrie> standard. Would that also solve our InstallShield problems? In Dimitrie> fact, what kind of problems do we have with InstallShield?
>> Another alternative would be to merge in Keith Packards pseudo-root >> extension:
Dimitrie> Any idea why he did not get it integrated?
There have been problems in the Xfree86 board, and to my knowledge Keith is no longer member of that board. It probably was not his decision to leave the board...
-
Alex Pasadyn -
Alexandre Julliard -
Dimitrie O. Paun -
Eric Pouech -
Lionel Ulmer -
Mike Hearn -
Uwe Bonnes