Alexandre Julliard wrote:
Module: wine Branch: refs/heads/master Commit: db6608ac9f9bbc2ddd7f8bf201d1387d079dfd5f URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=db6608ac9f9bbc2ddd7f8bf2...
Author: Alexandre Julliard julliard@winehq.org Date: Mon Mar 27 22:43:03 2006 +0200
x11drv: Moved desktop mode handling to the explorer process.
Per-application desktop mode settings are no longer supported. Apps can be launched in a specific desktop window by using:
explorer /desktop=name[,widthxheight] app.exe [args]
If the named desktop already exists the app is launched inside it. The default desktop is cleverly named "default".
So if I understand this correctly all programs will share the same desktop. Is it also true that I cannot specify in winecfg that one program can run full screen and another in a desktop window.
If this is the case we will have a fair amount of crying over this one.
At the very least we need to put a note in winecfg. (preferabley befor next release).
--
Tony Lambregts
Tony Lambregts wrote:
Alexandre Julliard wrote:
Module: wine Branch: refs/heads/master Commit: db6608ac9f9bbc2ddd7f8bf201d1387d079dfd5f URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=db6608ac9f9bbc2ddd7f8bf2...
Author: Alexandre Julliard julliard@winehq.org Date: Mon Mar 27 22:43:03 2006 +0200
x11drv: Moved desktop mode handling to the explorer process.
Per-application desktop mode settings are no longer supported. Apps can be launched in a specific desktop window by using:
explorer /desktop=name[,widthxheight] app.exe [args]
If the named desktop already exists the app is launched inside it. The default desktop is cleverly named "default".
So if I understand this correctly all programs will share the same desktop. Is it also true that I cannot specify in winecfg that one program can run full screen and another in a desktop window.
If this is the case we will have a fair amount of crying over this one.
At the very least we need to put a note in winecfg. (preferabley befor next release).
--
Tony Lambregts
Not in winecfg, but users can always modify their shortcuts to the application to run wine with the /desktop command like shown above. Doing it that way does conform to windows, so if users liked the old way, unfortunately, they are outta luck..
Tom
Monday, March 27, 2006, 3:17:12 PM, Tom Spear (Dustin Booker, Dustin Navea) wrote:
Tony Lambregts wrote:
Alexandre Julliard wrote:
Module: wine Branch: refs/heads/master Commit: db6608ac9f9bbc2ddd7f8bf201d1387d079dfd5f URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=db6608ac9f9bbc2ddd7f8bf2...
Author: Alexandre Julliard julliard@winehq.org Date: Mon Mar 27 22:43:03 2006 +0200
x11drv: Moved desktop mode handling to the explorer process.
Per-application desktop mode settings are no longer supported. Apps can be launched in a specific desktop window by using:
explorer /desktop=name[,widthxheight] app.exe [args]
If the named desktop already exists the app is launched inside it. The default desktop is cleverly named "default".
So if I understand this correctly all programs will share the same desktop. Is it also true that I cannot specify in winecfg that one program can run full screen and another in a desktop window.
If this is the case we will have a fair amount of crying over this one.
At the very least we need to put a note in winecfg. (preferabley befor next release).
--
Tony Lambregts
Not in winecfg, but users can always modify their shortcuts to the application to run wine with the /desktop command like shown above. Doing it that way does conform to windows, so if users liked the old way, unfortunately, they are outta luck..
Tom
Ok so now say with Steam and all of it's games - it will be almost 100% unusable! Because we still haven't fixes managed/unmamaged windows. And Steam itself would be on top of everything. So the way people were able to work-around this is by putting Steam into virtual desktop. Now that means their game will run in the same desktop as well.
We really really really have to fix managed/unmanaged mode then. I can't even imagine how many people will stay with current or older Wine because of this patch.
Also I remember some users were using other two parameters of the desktop (top left corner - changing manually in the registry). I didn't seen anything that indicates they are still supported with this patch.
Vitaliy
Vitaliy Margolen wine-devel@kievinfo.com writes:
Ok so now say with Steam and all of it's games - it will be almost 100% unusable! Because we still haven't fixes managed/unmamaged windows. And Steam itself would be on top of everything. So the way people were able to work-around this is by putting Steam into virtual desktop. Now that means their game will run in the same desktop as well.
We could add some sort of per-app setting again, though it wouldn't work quite the same, apps in different desktops are a lot more isolated now. But if the only use for it is to work around managed mode bugs then it's probably not worth it, better to spend time fixing the real problem.
Also I remember some users were using other two parameters of the desktop (top left corner - changing manually in the registry). I didn't seen anything that indicates they are still supported with this patch.
No, that's no longer supported. It shouldn't be too hard to add it back if you want it.
Am Dienstag, 28. März 2006 11:31 schrieb Alexandre Julliard:
Vitaliy Margolen wine-devel@kievinfo.com writes:
Ok so now say with Steam and all of it's games - it will be almost 100% unusable! Because we still haven't fixes managed/unmamaged windows. And Steam itself would be on top of everything. So the way people were able to work-around this is by putting Steam into virtual desktop. Now that means their game will run in the same desktop as well.
We could add some sort of per-app setting again, though it wouldn't work quite the same, apps in different desktops are a lot more isolated now. But if the only use for it is to work around managed mode bugs then it's probably not worth it, better to spend time fixing the real problem.
You announced working on the unmanaged window problem in September 2001 IIRC, but I guess you didn't so far? Wouldn't, for the time being, a Cedega-like approach be feasible? They seem to ignore 'chromeless' windows and handle them just like regular windows (with window decoration and all, for Steam for example) - this is obviously not correct, but it would at least work 'till someone comes up with a real fix...?
Willie Sippel wrote:
You announced working on the unmanaged window problem in September 2001 IIRC, but I guess you didn't so far? Wouldn't, for the time being, a Cedega-like approach be feasible? They seem to ignore 'chromeless' windows and handle them just like regular windows (with window decoration and all, for Steam for example) - this is obviously not correct, but it would at least work 'till someone comes up with a real fix...?
Wouldn't be much motivation for somebody to come up with a real fix if there was already a half-baked fix in Wine already, would there?
Mike
Mike McCormack wrote:
Willie Sippel wrote:
You announced working on the unmanaged window problem in September 2001 IIRC, but I guess you didn't so far? Wouldn't, for the time being, a Cedega-like approach be feasible? They seem to ignore 'chromeless' windows and handle them just like regular windows (with window decoration and all, for Steam for example) - this is obviously not correct, but it would at least work 'till someone comes up with a real fix...?
Wouldn't be much motivation for somebody to come up with a real fix if there was already a half-baked fix in Wine already, would there?
Mike
That could be said about a lot in Wine.
regards, Jakob
Hello,
You announced working on the unmanaged window problem in September 2001 IIRC, but I guess you didn't so far? Wouldn't, for the time being, a Cedega-like approach be feasible? They seem to ignore 'chromeless' windows and handle them just like regular windows (with window decoration and all, for Steam for example) - this is obviously not correct, but it would at least work 'till someone comes up with a real fix...?
Wouldn't be much motivation for somebody to come up with a real fix if there was already a half-baked fix in Wine already, would there?
I've sent 2 patches addressing this issue to wine-devel last year. The first patch(http://www.winehq.org/pipermail/wine-patches/2005-March/016558.html) made children of the desktop managed, the other patch made WM_SYSMENU(Sorry, can't find this one in the archives) windows managed. Both patches were neighter applied nor discussed further.
My observation was that all affected windows have a WM_SYSMENU | WM_POPUP style, but do not set WM_CAPTION | WM_EX_APPWINDOW or any other styles which would make them managed. Making WM_SYSMENU windows managed fixed a few apps, like Steam, Quicktime Half-life(parts not managed, can't navigate through the menus). I didn't notice any side effects(The windows had no decoration, which is completely correct), except that Steam and QuickTime seem to provide their own window movement code which conflicts with KDEs window movement handling. So if you move a Steam window to the corner of the screen, it won't move out of the screen, but Steam expects it to and mouse clicks are placed incorrectly. Quicktime can't be moved at all. I am not sure if this the direct fault of making those windows managed, or if there are some other bugs.
Am Mittwoch, 29. März 2006 12:19 schrieb Stefan Dösinger:
Hello,
You announced working on the unmanaged window problem in September 2001 IIRC, but I guess you didn't so far? Wouldn't, for the time being, a Cedega-like approach be feasible? They seem to ignore 'chromeless' windows and handle them just like regular windows (with window decoration and all, for Steam for example) - this is obviously not correct, but it would at least work 'till someone comes up with a real fix...?
Wouldn't be much motivation for somebody to come up with a real fix if there was already a half-baked fix in Wine already, would there?
I've sent 2 patches addressing this issue to wine-devel last year. The first patch(http://www.winehq.org/pipermail/wine-patches/2005-March/016558.html) made children of the desktop managed, the other patch made WM_SYSMENU(Sorry, can't find this one in the archives) windows managed. Both patches were neighter applied nor discussed further.
Did you check this[1] solution for borderless SDL applications? Looks somewhat hacky, but not too complicated. Maybe the basic idea is feasible for Wine as well? GTK (XMMS) seems to use the same approach ([2], Motif WM hints) to disable borders, and this concept works with pretty much every window manager...
[1]: http://www.libsdl.org/pipermail/sdl/2000-January/023704.html [2]: http://www.pygtk.org/pygtk2reference/class-gdkwindow.html#method-gdkwindow--...
Am Mittwoch, 29. März 2006 11:39 schrieb Mike McCormack:
Willie Sippel wrote:
You announced working on the unmanaged window problem in September 2001 IIRC, but I guess you didn't so far? Wouldn't, for the time being, a Cedega-like approach be feasible? They seem to ignore 'chromeless' windows and handle them just like regular windows (with window decoration and all, for Steam for example) - this is obviously not correct, but it would at least work 'till someone comes up with a real fix...?
Wouldn't be much motivation for somebody to come up with a real fix if there was already a half-baked fix in Wine already, would there?
Probably true. But Wine has several problems where a 'real' fix is so very complicated that we won't see something anytime soon, probably for years to come (like the DIB engine, planned for years, but nobody seems to even work on it). In the recent two years, Wine became unusable for many users - I even know some guys that switched back to Windows because of 'fixes' to Wine that render lots of application unusable, due to regressions expected when those fixes were commited. Those 'fixes' should never make it into CVS if there's not even a realistic timeframe for fixing the regressions.
The WM-rewrite/ broken windowed-OpenGL support is a perfect example, rendering many applications unusable - stuff that used to work in the past. There are probably 'easy' ways to hack around the problem (making the old window handling an option, or maybe create a hybrid that uses extra X11-windows for OpenGL viewports only), but the proposed 'correct' approaches will most likely take a few years and/ or kill the performance, if they are even feasible (GLX extension - completely worthless without ATI/ Nvidia support)...
Willie Sippel wrote:
Probably true. But Wine has several problems where a 'real' fix is so very complicated that we won't see something anytime soon, probably for years to come (like the DIB engine, planned for years, but nobody seems to even work on it). In the recent two years, Wine became unusable for many users - I even know some guys that switched back to Windows because of 'fixes' to Wine that render lots of application unusable, due to regressions expected when those fixes were commited. Those 'fixes' should never make it into CVS if there's not even a realistic timeframe for fixing the regressions.
How do you propose that we figure out if there's going to be regressions or not before the patches are committed?
Isn't it just better to start with a patch that is "right", but will still show regressions, then fix those regressions, as opposed to starting with a patch that is wrong, and then hacking on it forever trying to solve the unsolvable problems that causes?
The WM-rewrite/ broken windowed-OpenGL support is a perfect example, rendering
My counter example is richedit. As a half-baked wrapper around the edit control, it rotted in the CVS for at least 4 years until Krzysztof finally rewrote the whole thing. If the half-baked version never existed in the first place we would have had a working richedit control alot sooner.
It might be a little bit harder to get things done by avoiding hacks at the start, but it's *alot* harder to get rid of the hacks once they're there. People will complain and complain forever that the hacky version worked for them once for one application, even if the new version does alot better for all applications.
Mike
Am Mittwoch, 29. März 2006 13:15 schrieb Mike McCormack:
Willie Sippel wrote:
Probably true. But Wine has several problems where a 'real' fix is so very complicated that we won't see something anytime soon, probably for years to come (like the DIB engine, planned for years, but nobody seems to even work on it). In the recent two years, Wine became unusable for many users - I even know some guys that switched back to Windows because of 'fixes' to Wine that render lots of application unusable, due to regressions expected when those fixes were commited. Those 'fixes' should never make it into CVS if there's not even a realistic timeframe for fixing the regressions.
How do you propose that we figure out if there's going to be regressions or not before the patches are committed?
Well, granted, that won't usually work. However, with the WM rewrite, I think it was expected. And the unmanaged window problem with Steam is well known, as is the workaround. I still don't really know what's so hard about the unmanaged window thing, as there are unmanaged windows on Linux, too (eg, XMMS) - but I'm not really much of coder, so I most probably missed something...
Isn't it just better to start with a patch that is "right", but will still show regressions, then fix those regressions, as opposed to starting with a patch that is wrong, and then hacking on it forever trying to solve the unsolvable problems that causes?
You are right, of course. I'm all for doing stuff right, and I'm not a friend of quick-and-dirty hacks myself. I simply can't understand why most serious regressions introduced in the last two years are seemingly not worked on at all - they simply seem to get ignored. I'm sorry if my mail sounded like a rant, but I'm one of the guys obviously lucky enough to be affected by pretty much every single regression over the last two years in some way - and that gets really frustrating. Of all the applications I used with Wine when I switched to Linux a few years ago, only a single one still works, while every single bug this application shows was already in Wine in 2003.
The WM-rewrite/ broken windowed-OpenGL support is a perfect example, rendering
My counter example is richedit. As a half-baked wrapper around the edit control, it rotted in the CVS for at least 4 years until Krzysztof finally rewrote the whole thing. If the half-baked version never existed in the first place we would have had a working richedit control alot sooner.
It might be a little bit harder to get things done by avoiding hacks at the start, but it's *alot* harder to get rid of the hacks once they're there. People will complain and complain forever that the hacky version worked for them once for one application, even if the new version does alot better for all applications.
Correct. It seems to be a matter of motivation. I don't know... An idea would be to accept an evil hack to make unmanaged windows work, with a deadline. Like, the patch goes in for now, but will be removed in three months. So, if someone needs the affected applications working, either write and commit a real fix in the next three months, or the app stops working then.
One could argue that the hack could as well be ommited then 'till someone really fixes the issue, but in case of Steam, the hack is also needed to run and manage Valve games. If nobody can run those applications, nobody can work on bugs they expose as well.
On Wed, Mar 29, 2006 at 02:47:06PM +0200, Willie Sippel wrote: ...
Isn't it just better to start with a patch that is "right", but will still show regressions, then fix those regressions, as opposed to starting with a patch that is wrong, and then hacking on it forever trying to solve the unsolvable problems that causes?
You are right, of course. I'm all for doing stuff right, and I'm not a friend of quick-and-dirty hacks myself. I simply can't understand why most serious regressions introduced in the last two years are seemingly not worked on at all - they simply seem to get ignored. I'm sorry if my mail sounded like a
Simple.
No one is paying to get it fixed ;) (And it requires a lot of effort for Joe Random Coder.)
Thats just OpenSource for you.
Ciao, Marcus
Am Mittwoch, 29. März 2006 15:14 schrieb Marcus Meissner:
On Wed, Mar 29, 2006 at 02:47:06PM +0200, Willie Sippel wrote: ...
Isn't it just better to start with a patch that is "right", but will still show regressions, then fix those regressions, as opposed to starting with a patch that is wrong, and then hacking on it forever trying to solve the unsolvable problems that causes?
You are right, of course. I'm all for doing stuff right, and I'm not a friend of quick-and-dirty hacks myself. I simply can't understand why most serious regressions introduced in the last two years are seemingly not worked on at all - they simply seem to get ignored. I'm sorry if my mail sounded like a
Simple.
No one is paying to get it fixed ;) (And it requires a lot of effort for Joe Random Coder.)
Thats just OpenSource for you.
O RLY? ;-D
I know how that stuff works, I'm part of a few projects myself. Still, I'm the 'I broke it, I'll fix it' kinda guy, but I know it's wrong to expect everyone to be the same. Especially in the case of Wine, as I'm sure the fixes that introduced the regression did more good than harm, in general.
However, I ranted enough I think. Back to the real problem. AFAIU, there's only a single common/ feasible/ intelligent way to create borderless windows on X11 - managed windows with 'no decoration' Motif hints (the way GTK handles borderless windows). The example I found looks easy enough, only a few lines of code, but I was once again reminded that Wine really is way over my head - I have no idea how to hack that in to at least test it... :-(
Willie Sippel wrote:
However, I ranted enough I think. Back to the real problem. AFAIU, there's only a single common/ feasible/ intelligent way to create borderless windows on X11 - managed windows with 'no decoration' Motif hints (the way GTK handles borderless windows). The example I found looks easy enough, only a few lines of code, but I was once again reminded that Wine really is way over my head - I have no idea how to hack that in to at least test it... :-(
The code is already in dlls/x11drv/window.c and it works well. The trouble is that managed mode windows steal input focus when they are created. To give you an example, you click on a text box in IE to put your email address into a form and you're half-way through typing it in when a tooltip appears. This steals input focus away from the text box and you carry on typing without noticing until you look back at the screen and notice only half of your email address is present. The same problems occur for menus and "toast" notifications.
Let's examine the properties of unmanaged windows (there may be others that I'm unaware of): They: 1. Have no window decorations 2. Are always on top 3. Appear on all virtual desktops.
Properties (1) and (2) have equal properties in the Win32 world. However, currently only (1) is implemented. AFAIK, the reason (2) isn't implemented is because it isn't set at window creation time, only after window creation (and we cannot switch from managed to unmanaged after creation).
Therefore, the solution is to allow managed windows to be converted to unmanaged windows after creation and then we can implement (2) and have an almost exact match of the desired properties of the window with the actual properties that the window manager gives us. Then we can remove the other hacks based on the window style that make Steam end up with an unmanaged window.
Am Mittwoch, 29. März 2006 16:26 schrieb Robert Shearman:
Willie Sippel wrote:
However, I ranted enough I think. Back to the real problem. AFAIU, there's only a single common/ feasible/ intelligent way to create borderless windows on X11 - managed windows with 'no decoration' Motif hints (the way GTK handles borderless windows). The example I found looks easy enough, only a few lines of code, but I was once again reminded that Wine really is way over my head - I have no idea how to hack that in to at least test it... :-(
The code is already in dlls/x11drv/window.c and it works well. The trouble is that managed mode windows steal input focus when they are created. To give you an example, you click on a text box in IE to put your email address into a form and you're half-way through typing it in when a tooltip appears. This steals input focus away from the text box and you carry on typing without noticing until you look back at the screen and notice only half of your email address is present. The same problems occur for menus and "toast" notifications.
OK, maybe I got something completely wrong. I'll give you an example to show the problem I mean:
Traktor DJ Player, by Native Instruments
On Windows: The main application window has no borders, appears in the taskbar, can be minimized and moved like any regular window.
On Wine (Kwin handles Wine windows): The main application has a KDE window decoration that hides the top part of the interface. Everything else works as espected, but there should be no Kwin decoration, especially as it hides parts of the interface, making the application unusable.
On Wine (Wine handles windows): The application window looks as expected, no borders, can be moved around and stuff. But it's always on top, always on all desktops and does not appear in the taskbar. Which is completely wrong. Also, if minimized, you'll get a stupid icon somewhere on the desktop, on all desktops, always on top, hiding the K-Menu...
The perfect solution would be to let Kwin (or whatever window manager) handle the borderless windows, but don't draw any window decorations if the applications doesn't want to. That's what I expected to achieve with Motif hints (but I'm obviously too stupid, all I get are nice crashes)...
Willie Sippel wrote:
OK, maybe I got something completely wrong. I'll give you an example to show the problem I mean:
Traktor DJ Player, by Native Instruments
On Windows: The main application window has no borders, appears in the taskbar, can be minimized and moved like any regular window.
On Wine (Kwin handles Wine windows): The main application has a KDE window decoration that hides the top part of the interface. Everything else works as espected, but there should be no Kwin decoration, especially as it hides parts of the interface, making the application unusable.
On Wine (Wine handles windows): The application window looks as expected, no borders, can be moved around and stuff. But it's always on top, always on all desktops and does not appear in the taskbar. Which is completely wrong. Also, if minimized, you'll get a stupid icon somewhere on the desktop, on all desktops, always on top, hiding the K-Menu...
The perfect solution would be to let Kwin (or whatever window manager) handle the borderless windows, but don't draw any window decorations if the applications doesn't want to. That's what I expected to achieve with Motif hints (but I'm obviously too stupid, all I get are nice crashes)...
It sounds like the borders being present is a separate problem. Without knowing what windows styles the application is using (it could be using a weird combination that doesn't set the correct hints), it sounds like the application is handling the WM_NCCALCSIZE message and overriding the non-client top border to 0 and drawing its own part of that interface. The trouble is that detecting this is rather hard. A solution is possible where after it is detected that the non-client size has been altered and the MWM flags adjusted appropriately, but this would be based on heuristics like the existing managed/unmanaged problem and sometimes the heuristics get it wrong.
This is just another case where if we do the right case for one problem then another problem crops up and it appears as though we are introducing regressions. In reality, fixing the managed/unmanaged window problem would be a huge step forward for everyone even if further work is necessary to make windows appear as expected.
From: "Mike McCormack" mike@codeweavers.com
Wouldn't be much motivation for somebody to come up with a real fix if there was already a half-baked fix in Wine already, would there?
But neither does the keep-it-borken approach work, does it? :) Problem is that the breakage is not large enough to motivate people. I think we have to come to terms with the fact that Wine is big, and doing things right is not always an option.
I seems to me that we'd be better off to have a working but not-so-perfect solution, rather than wait for years to have the perfect one.
Of course, I agree that you can not merge any solution in, that road leads to madness. But we have to balance that with the fact that we have to be useful by offering the functionality that people need or want.
Otherwise wine will become irrelevant before it becomes useful. And that would be a shame.
Dimi Paun wrote:
Problem is that the breakage is not large enough to motivate people.
Yep. Just large enough for people to complain about, and demand that somebody else take care of the problem, Now! ;)
Mike
From: "Mike McCormack" mike@codeweavers.com
Yep. Just large enough for people to complain about, and demand that somebody else take care of the problem, Now! ;)
One of those things :) Now, don't misunderstand me, I'm glad Alexandre got around to move the desktop to the explorer process. My comments where of a more general nature, not about this particular patch.
Overall, we're much better off with the desktop in explorer and fewer features, than the situation we were in before, which blocked all sorts of cool integration tasks.
Sometimes you need a step back to be able to sustain future development. This is one of those situations.
On 3/27/06, Tony Lambregts tony.lambregts@gmail.com wrote:
Alexandre Julliard wrote:
Module: wine Branch: refs/heads/master Commit: db6608ac9f9bbc2ddd7f8bf201d1387d079dfd5f URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=db6608ac9f9bbc2ddd7f8bf2...
Author: Alexandre Julliard julliard@winehq.org Date: Mon Mar 27 22:43:03 2006 +0200
x11drv: Moved desktop mode handling to the explorer process.
Per-application desktop mode settings are no longer supported. Apps can be launched in a specific desktop window by using:
explorer /desktop=name[,widthxheight] app.exe [args]
Is the explorer.exe program supposed to be in the path somewhere? The only place it is installed is in /usr/local/lib/wine/explorer.exe.so. That is outside my wine drive letters. I have to copy it in to drive C to be able to run and use the /desktop option.
Jesse
Hello,
Per-application desktop mode settings are no longer supported. Apps can be launched in a specific desktop window by using:
explorer /desktop=name[,widthxheight] app.exe [args]
I have serious problems with games with that patch. All DirectDraw games I've tested(with the mainline ddraw code any my patches) because they fail to set the display mode. I have a MergedFB setup with a resolution of 1400x2074, and I disallow mode changes in my X config. With the old code, x11drv nicely reported the standard displaymodes 640x480,800x600,... to DDraw / opengl / d3d, and could resize the window to that resolutions. Now it only supports 1400x2074
I really think a Desktop setting should be possible in winecfg. It allows me to configure some apps to use a virtual desktop and run them from the terminal with wine foo.exe, without a long "wine explorer /desktop=blabla..." line. Running games in a virtual Desktop is essential for d3d development.
I don't expect that the code will affect apps like Steam, even if Steam and half-life are run in the same desktop window, because the problem only occurs if Steam is run in managed mode because the window manager can't cope with unmanaged windows. In a virtual Desktop, I expect it to work nice.
But the ability to have more apps in one Desktop is nice :)
Stefan
Hi,
I have serious problems with games with that patch. All DirectDraw games I've tested(with the mainline ddraw code any my patches) because they fail to set the display mode. I have a MergedFB setup with a resolution of 1400x2074, and I disallow mode changes in my X config. With the old code, x11drv nicely reported the standard displaymodes 640x480,800x600,... to DDraw / opengl / d3d, and could resize the window to that resolutions. Now it only supports 1400x2074
Never mind that rant, I must have done something wrong when updating / recompiling, now it works with my code and the old ddraw code :)
I really think a Desktop setting should be possible in winecfg. It allows me to configure some apps to use a virtual desktop and run them from the terminal with wine foo.exe, without a long "wine explorer /desktop=blabla..." line. Running games in a virtual Desktop is essential for d3d development.
That works too as I like it :) I'll do more tests tomorrow if I have time.
Stefan
"Jesse Allen" the3dfxdude@gmail.com writes:
Is the explorer.exe program supposed to be in the path somewhere? The only place it is installed is in /usr/local/lib/wine/explorer.exe.so. That is outside my wine drive letters. I have to copy it in to drive C to be able to run and use the /desktop option.
No it's not in the path, but running it with 'wine explorer' should work no matter where it's installed.
-
Alexandre Julliard -
Dimi Paun -
Jakob Eriksson -
Jesse Allen -
Marcus Meissner -
Mike McCormack -
Robert Shearman -
Stefan Dösinger -
Tom Spear (Dustin Booker, Dustin Navea) -
Tony Lambregts -
Vitaliy Margolen -
Willie Sippel