I'm pretty sure lots of other wine code uses 2 space indents, I know I started using them after working with wine.
No other comments on the ui changes in winecfg? ;-) I'll submit to wine-patches tonight after going through the code once more.
The x11 tab is global settings only at this point. I think we can remove a couple of options on this tab, UseRandR is the only one I can think of atm. If we do make x11 settings per-app/global, like the apps and libraries tab, it seems like we should somehow combine the tabs. Yet is is nice having distinct tabs. In any case, I don't use per-app x11 settings so unless someone decides to implement this I likely won't be back at it for a while.
Thanks, Chris
From: "Dimitrie O. Paun" dimi@intelliware.ca Date: 2004/02/04 Wed PM 02:14:59 EST To: Chris Morgan chmorgan@charter.net CC: wine-devel@winehq.com Subject: Re: [Winecfg] - redo applications tab, misc changes
On Tue, 3 Feb 2004, Chris Morgan wrote:
Comments, questions, suggestions welcome ;-)
The one complaint I have is that it changes the 4-space indentation to 2-space indentation, which makes the code so much harder to follow. I know, you're doing the work, so you get to chose :), but if it's not too much to ask, can we please stick to 4-space indentation?
-- Dimi.
On Wed, 04 Feb 2004 17:20:59 -0500, chmorgan wrote:
The x11 tab is global settings only at this point. I think we can remove a couple of options on this tab, UseRandR is the only one I can think of atm.
I'd not be happy with removing that - XrandR solves some problems and introduces others - namely that the desktop panel applets/icons etc rearrange themselves for the lower resolution then sometimes don't rearrange back. Using XVidmode has the advantage that the desktop size doesn't change, only the screen resolution (which is what we want) but has the disadvantage of enabling the hardware panning/sideslip stuff, which is what we don't want.
More thought needed? Alex, comments?
I'd not be happy with removing that - XrandR solves some problems and introduces others - namely that the desktop panel applets/icons etc rearrange themselves for the lower resolution then sometimes don't rearrange back.
But is what 'real' Windows does (as it sometimes messes also my Windows desktop when doing it :-) ).
Using XVidmode has the advantage that the desktop size doesn't change, only the screen resolution (which is what we want) but has the disadvantage of enabling the hardware panning/sideslip stuff, which is what we don't want.
I once investigated the way to 'lock' the address of the displayed frame-buffer in X11 by extending the XVidMode extension. And it's basically not doable easily as this scrolling is done in a very low level of the X11 code and would need a big amount of code to do properly.
This whole 'DXGrab' issue is a bit messy (and even with a full-screen winedesktop mode we won't fix all these issues easily as we will still have the XGrabPointer issue).
Lionel
Mike Hearn wrote:
I'd not be happy with removing that - XrandR solves some problems and introduces others - namely that the desktop panel applets/icons etc rearrange themselves for the lower resolution then sometimes don't rearrange back. Using XVidmode has the advantage that the desktop size doesn't change, only the screen resolution (which is what we want) but has the disadvantage of enabling the hardware panning/sideslip stuff, which is what we don't want.
I have good luck with XRandR, and I prefer it to XVidMode, but I know some like it the other way. I think a good compromise is to leave a global setting for RandR on/off and have app-specific desktop mode settings (for now), as many people like some apps full screen and others in desktops of various shapes and sizes.
From some chatting in IRC, a possible work-around for the panning in XVidMode is to just grab the pointer if you switch to a smaller resolution and an app creates a window intended to fill the smaller resolution up. It's definitely possible to create a test case that breaks with that scheme, although I am not sure how likely that would be in real apps. The other problem is that if you use XVidMode, an application that does GetWindowRect(GetDesktopWindow(), &r) will not get the answer it expects.
As for the quirks with XRandR, that sounds like a bug in the Window manager. I think maybe the reason I have good luck with it is my KDE is so old it just ignores the events. If people are seeing desktops respond to a shrinking but not to an expanding then I think that's a bug that should be reported to the desktop people. XRandR is definitely a lot closer to what the display settings functions do on Win32.
Alex
From some chatting in IRC, a possible work-around for the panning in XVidMode is to just grab the pointer if you switch to a smaller resolution and an app creates a window intended to fill the smaller resolution up.
Grabbing the mouse is not a trivial thing to do (as in X11, if you grab the mouse, only the connection who did the grab will ever get any input events for the mouse). So we need to be absolutely sure to do the XGrabPointer call from the right X connection.
Lionel
On Wednesday 04 February 2004 06:56 pm, Mike Hearn wrote:
On Wed, 04 Feb 2004 17:20:59 -0500, chmorgan wrote:
The x11 tab is global settings only at this point. I think we can remove a couple of options on this tab, UseRandR is the only one I can think of atm.
I'd not be happy with removing that - XrandR solves some problems and introduces others - namely that the desktop panel applets/icons etc rearrange themselves for the lower resolution then sometimes don't rearrange back.
This sounds like something that can/should be fixed with the window manager, if that is what you are referring to, and not directly a wine issue.
Using XVidmode has the advantage that the desktop size
doesn't change, only the screen resolution (which is what we want) but has the disadvantage of enabling the hardware panning/sideslip stuff, which is what we don't want.
More thought needed? Alex, comments?
We should be asking ourselves if we expect window managers to handle XrandR correctly in the future. It seems like a very worthwhile extension to X to support and I'd rather we have one less option when we can get rid of it and not have it greatly impact the wine user.
Chris
On February 4, 2004 05:20 pm, chmorgan@charter.net wrote:
I'm pretty sure lots of other wine code uses 2 space indents, I know I started using them after working with wine.
Yes, other code does so, but I think the preferred style is 4-space. Now, as I said, if you feel strongly about it, it will stay 2-space. But if you're flexible on this issue, 4-space indents would be nice.
No other comments on the ui changes in winecfg? ;-) I'll submit to wine-patches tonight after going through the code once more.
Hey, I was at work (so I couldn't test). But now I got a chance to look at it, so here are my comments: -- it looks good. This is good stuff, I think we're getting very close to the finish line. -- have the Applications be the first page is a bit confusing. This is advanced functionality, I'd start with something else, like the Drives tab. -- I could delete the "Global Settings" in the Application tab, which also hosed my registry -- Whenever I've tried to add a app, and change it's settings, it will disappear right away (whenever I tried to change any of it's settings). -- whenever I've tried changing something, I got errors like this: err:winecfg:setConfigValue Unable to set configuration key (null) in section AppDefaults\coolplayer.exe\Version to (null), res=1021 Maybe my installation is faulty?
-
Alex Pasadyn -
chmorgan＠charter.net -
Chris Morgan -
Dimitrie O. Paun -
Lionel Ulmer -
Mike Hearn