Hello, I have started to work on winecfg a little in attempt to get used to some workings of WINE. This is the first real open source project I have actually tried to submit a patch to. I have started to work on a few functions that were not implemented yet and before I forget to try to submit a patch again I thought I would do it now.
The only part I have included in this patch is the ability to remove an application from the "Application" tab. The way I assumed that this was to do is remove the appropriate key from the registry and update the listview. I realize this is a pitiful patch since it really doesn't add much but I thought I would see if I am doing it correctly and to see if does what it should. Any help is appreciated(I hope this patch is inline, my first try at it.
Kirk
Yo,
The patch looks good except for this bit.
On Wed, 14 Jan 2004 18:20:44 -0500, Kirk Ruff wrote:
- sprintf(key, WINE_KEY_ROOT "\AppDefaults\%s\0", currentApp);
Why do you explicitly null terminate this string? It shouldn't be needed, right?
- return_if_fail(
- RegDeleteKey(HKEY_LOCAL_MACHINE, key) == ERROR_SUCCESS
You can't use RegDeleteKey to recursively delete subkeys, it's not that intuitive. You need to use SHDeleteKey. See MSDN:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pla...
It's in shlwapi so you may need to do add that to the link line in the Makefile.
Ideally of course this stuff would go via the transaction system (so in the hypothetical future users can undo it, and we can delay it until the user hits apply in explicit-apply mode).
Once you fixed that, please do submit this to wine-patches! :)
thanks -mike (who wrote most of winecfg last September so feel free to ask him questions :-)
(sent this to the wrong email address, sorry) On Thu, 2004-01-15 at 07:08, Mike Hearn wrote:
Why do you explicitly null terminate this string? It shouldn't be needed, right?
Not sure what the deal was but I was getting segfaults unless I null terminated it myself. Now, it doesn't, so must have been something stupid that I had done.
Ideally of course this stuff would go via the transaction system (so in the hypothetical future users can undo it, and we can delay it until the user hits apply in explicit-apply mode).
I forgot about that and I had wondered what those functions were, well now I know. I will try to make it work with that later today if I have some free time.
Also, one thing that I have a question about; If I remove an application from the 'Applications' tab, shouldn't it not show up in the 'Libraries' tab? This is something I tried to look into but I didn't get too far.
I switched to SHDeleteKey, and once I figure out the transaction system I will get that going.
Thanks for your time to review it, I hope to add some more functionality soon. This patch seems to be mostly a copy-paste from another function.
On Thu, 15 Jan 2004 12:43:33 -0500, Kirk Ruff wrote:
I forgot about that and I had wondered what those functions were, well now I know. I will try to make it work with that later today if I have some free time.
Yeah. In order to implement unlimited undo you need to operate in terms of transactions.
Also, one thing that I have a question about; If I remove an application from the 'Applications' tab, shouldn't it not show up in the 'Libraries' tab? This is something I tried to look into but I didn't get too far.
Blah, appdefaults are kind of a mess. I had it working but you had to set the app on one tab then alter settings on another which wasn't great UI. Someone else submitted a patch which started moving appdefaults into each relevant tab separately. I guess we haven't removed the old one first. I'm still not convinced about the ui for this yet....
thanks -mike
Hi...
I understand that you changed something about the app-specific tab-sheet?
We (me and cmorgan) were thinking about dropping that tabsheet :-)...
So I am not sure to what extend your changed are useful in the long term...
On Thu, 15 Jan 2004, Robert van Herk wrote:
We (me and cmorgan) were thinking about dropping that tabsheet :-)...
That's a good idea, the current UI for app-specific settings is terrible.
On Thu, 2004-01-15 at 15:23, Dimitrie O. Paun wrote:
On Thu, 15 Jan 2004, Robert van Herk wrote:
We (me and cmorgan) were thinking about dropping that tabsheet :-)...
That's a good idea, the current UI for app-specific settings is terrible.
I agree it is horrible, but I wanted to try to implement something. I also agree that that tab should be dropped and all handeled within 1 tab. At least I didn't put a lot of effort in to this. If you guys have any up coming patches, any idea how long before you will be ready to send them in?
Kirk Ruff wrote:
On Thu, 2004-01-15 at 15:23, Dimitrie O. Paun wrote:
On Thu, 15 Jan 2004, Robert van Herk wrote:
We (me and cmorgan) were thinking about dropping that tabsheet :-)...
That's a good idea, the current UI for app-specific settings is terrible.
I agree it is horrible, but I wanted to try to implement something. I also agree that that tab should be dropped and all handeled within 1 tab. At least I didn't put a lot of effort in to this. If you guys have any up coming patches, any idea how long before you will be ready to send them in?
I already sent in a patch for dll specific overrides... It isn't totally finished though, since i forgot a few settings ;-). But anywayz, the current library tab sheets allows you to override dlls per application.
As for as I know, cmorgan is doing the same to the x11drv tab sheet.
After these two are added, I guess the appsdefault tabsheet could be dropped...
I am not planning to start working on it again soon, since I have some high-prio stuff to do first. I'll probably start with it again in 'bout a month...
If you feel like implementing features, pls talk to cmorgan in the #winehq channel on freenode. He is there quite often and afaik currently working on winecfg.
Grtz,
Robert
I was planning to do the same to the x11 tabsheet but wasn't sure if people actually needed to be able to specify these options per-app. Unless there is a good reason, like there can be with dlls, global settings seem the best for that tab. If people think this is necessary I'll take a look at it ;-)
Chris
On Friday 16 January 2004 12:17 pm, Robert van Herk wrote:
Kirk Ruff wrote:
On Thu, 2004-01-15 at 15:23, Dimitrie O. Paun wrote:
On Thu, 15 Jan 2004, Robert van Herk wrote:
We (me and cmorgan) were thinking about dropping that tabsheet :-)...
That's a good idea, the current UI for app-specific settings is terrible.
I agree it is horrible, but I wanted to try to implement something. I also agree that that tab should be dropped and all handeled within 1 tab. At least I didn't put a lot of effort in to this. If you guys have any up coming patches, any idea how long before you will be ready to send them in?
I already sent in a patch for dll specific overrides... It isn't totally finished though, since i forgot a few settings ;-). But anywayz, the current library tab sheets allows you to override dlls per application.
As for as I know, cmorgan is doing the same to the x11drv tab sheet.
After these two are added, I guess the appsdefault tabsheet could be dropped...
I am not planning to start working on it again soon, since I have some high-prio stuff to do first. I'll probably start with it again in 'bout a month...
If you feel like implementing features, pls talk to cmorgan in the #winehq channel on freenode. He is there quite often and afaik currently working on winecfg.
Grtz,
Robert
On January 16, 2004 12:55 pm, Chris Morgan wrote:
I was planning to do the same to the x11 tabsheet but wasn't sure if people actually needed to be able to specify these options per-app. Unless there is a good reason, like there can be with dlls, global settings seem the best for that tab. If people think this is necessary I'll take a look at it ;-)
Here is the exaustive list of per-app settings that we currently have in winecfg:
[Version] Windows DOS
[DllOverrides] <dllname1> <dllname2> ...
[DSound] EmulDriver
As you can see, there are only 4, we shouldn't complicate the UI too much for them...
On Fri, 16 Jan 2004 22:03:31 -0500, Dimitrie O. Paun wrote:
Here is the exaustive list of per-app settings that we currently have in winecfg:
Don't forget the X11DRV settings, in particular:
Desktop UseXVidMode/UseXRandR XRender vs core fonts
are app-specific for sure, probably others. Of those you definately want to be able to configure Desktop mode separately, at least until Alex's desktop patch goes in.
thanks -mike
Shouldn't we be adding things that:
- Won't be obsolete in the future - A majority of users actually need to use
I'm wondering if enough users want to configure those options to make it worthwhile to implement. We should prioritize the functionality we need before we can say "use winecfg" to configure wine. The rest of the features can require the user to use regedit or edit the config file by hand.
I agree that [Version] should be an app specific setting, it is a frequently used option. Maybe we can roll version settings and the Dll settings tab together into an "Application" tab?
Chris
On Saturday 17 January 2004 08:09 am, Mike Hearn wrote:
On Fri, 16 Jan 2004 22:03:31 -0500, Dimitrie O. Paun wrote:
Here is the exaustive list of per-app settings that we currently have in winecfg:
Don't forget the X11DRV settings, in particular:
Desktop UseXVidMode/UseXRandR XRender vs core fonts
are app-specific for sure, probably others. Of those you definately want to be able to configure Desktop mode separately, at least until Alex's desktop patch goes in.
thanks -mike
On January 17, 2004 10:55 am, Chris Morgan wrote:
Shouldn't we be adding things that:
- Won't be obsolete in the future
- A majority of users actually need to use
I think you are correct. The settings that Mike mentioned were listed already under the regedit-only already. I think they should remain there.
I agree that [Version] should be an app specific setting, it is a frequently used option. Maybe we can roll version settings and the Dll settings tab together into an "Application" tab?
I think this is a good idea. In general speaking, this per-app settings is a hack required by poor implementation. Windows doesn't need it, so we should be fine without it. Therefore: -- we should try to minimize it's use -- eliminate it in the future -- not encourage people to use it, unless required Thus cluttering the interface with it would be a bad plan IMO. Having it in a separate tab can keep us honest to not overuse it, and to more easily get rid of it in the future.
On Saturday 17 January 2004 12:41 pm, Dimitrie O. Paun wrote:
I agree that [Version] should be an app specific setting, it is a frequently used option. Maybe we can roll version settings and the Dll settings tab together into an "Application" tab?
I think this is a good idea. In general speaking, this per-app settings is a hack required by poor implementation. Windows doesn't need it, so we should be fine without it. Therefore: -- we should try to minimize it's use -- eliminate it in the future -- not encourage people to use it, unless required Thus cluttering the interface with it would be a bad plan IMO. Having it in a separate tab can keep us honest to not overuse it, and to more easily get rid of it in the future.
Windows actually does have a few settings like this (Well, XP does) You can specify an EXE will run in the following compatabillty modes: Windows 95 Windows 98 / Windows Me Windows NT 4.0 (Service Pack 5) Windows 2000
as well as specify the app should run in 256 colors, disable visual themes, run in 640x480 resolution
There has been many cases where I've found applications that refused to run on XP and being able to specify the Win95 or NT4 compatibility mode worked great
On January 17, 2004 08:09 am, Mike Hearn wrote:
Don't forget the X11DRV settings, in particular:
Desktop UseXVidMode/UseXRandR XRender vs core fonts
Well, first off, I didn't know these (except for Desktop) were app-specific. I've marked them so now. However, they are not winecfg options, there are listed as regedit-only options in my list, so I don't think we should worry about them for now.
Attached please find my latest version of the options.html list. This list needs to be kept up to date. Truth be told, it's hard to do so when it sits on my machine. It needs to be integrated into WineHQ. Maybe under Status? (I'll send a patch soon).
But the main idea is that we've already discussed these things, and the conclusions of those discussions were distilled into this document. Let's work off of it, and try to keep it current.
-
Chris Morgan -
Dimitrie O. Paun -
Dimitrie O. Paun -
Kevin Koltzau -
Kirk Ruff -
Mike Hearn -
Robert van Herk