Re: [winecfg 1.1] Implement saveConfigValue(), style changes, code cleanup, UI alignment
On August 28, 2003 06:50 am, Mike Hearn wrote:
- Introduce some kind of global flag, maybe a config.h switch, maybe an
exported variable (which is best?) that controls whether the configuration is read from the registry or config file. As patches are submitted to make Wine read the registry as well as the config file, the controls in winecfg would be re-enabled so people can test it. Once all the settings have been dual-purposed in this way, we can write a bit of migration code so people upgrading have their configurations copied into the registry, then throw the switch.
I really don't understand why we need the dual-purpose stuff. All we need to do is: -- make sure we have a GUI element for all settings in ~/.wine/config (how far are we from having this?) -- have loadConfig() initialize all these elements properly -- have saveConfig() do the saving, being a mirror image of loadConfig() (can't we unify them somehow so we have only one place to modify to add new values? [1]) -- when all this is done, just remove the code from server/registry.c:1475:init_registry()
Am I missing something?
[1] Maybe it's better to have a more descriptive structure detailing stuff for each value, and having generic loadConfig/saveConfig() methods that know how to walk said structure and do the right thing. This way we can easily do add all sorts of attributes to the configuration values and do all sort of nice things, like save only stuff that has been modified, automatically tie in the variable to the control, etc.
On Thu, 2003-08-28 at 14:06, Dimitrie O. Paun wrote:
I really don't understand why we need the dual-purpose stuff. All we need to do is: -- make sure we have a GUI element for all settings in ~/.wine/config (how far are we from having this?)
Quite far. A quick glance at my local winecfg and my local config file (which probably doesn't have every setting possible in it) shows we're missing:
* A sane way to deal with appdefaults * Some general settings like ShowDirSymlinks * DllOverrides (we have basic UI but it doesn't let you add new dlls, nor does it list any system dlls). * Not all the X11DRV options are in the UI * Fonts * Parallel/serial ports/printing stuff * Debugging (should this even be in the ui?) * Registry control * Console control * Clipboard settings * Multimedia - WinMM, DirectSound * Network (only one setting here though).
Coding for Win32 takes ages (too bad we can't use something sane like gtk and be done with it *sigh), so I might not be able to get them all functional in the time I have.
Another problem we might have is that this is going to be a pretty cluttered and confusing UI if we cram everything possible into it. Do we really have to scrap the config file completely?
-- when all this is done, just remove the code from server/registry.c:1475:init_registry()
Ah, thanks. I was looking for that piece of code. I'm still not fully sure how Wine overlays the config file onto the registry - if I run regedit the Wine\Wine key seems to be empty?
Am I missing something?
Not really, I'm still getting up to speed with what needs to be done. Also, remember that I don't work as quickly as somebody experienced with win32 (and i have another project i'm working on too).
[1] Maybe it's better to have a more descriptive structure detailing stuff for each value, and having generic loadConfig/saveConfig() methods that know how to walk said structure and do the right thing. This way we can easily do add all sorts of attributes to the configuration values and do all sort of nice things, like save only stuff that has been modified, automatically tie in the variable to the control, etc.
Yes, maybe, but some stuff requires custom parsing (like the x11drv thing) - given that it's usually perhaps 3 or 4 lines, I'm not sure doing something fancy here is a good use of time. Constructing the UI and all the logic to manipulate it takes far longer, and can't be automated.
On 28 Aug 2003, Mike Hearn wrote:
- A sane way to deal with appdefaults
- Some general settings like ShowDirSymlinks
- DllOverrides (we have basic UI but it doesn't let you add new dlls,
nor does it list any system dlls).
- Not all the X11DRV options are in the UI
- Fonts
- Parallel/serial ports/printing stuff
- Debugging (should this even be in the ui?)
- Registry control
- Console control
- Clipboard settings
- Multimedia - WinMM, DirectSound
- Network (only one setting here though).
Man, oh man, quite a bit of stuff. maybe we can get rid of some of them. :) Or maybe we don't need UI stuff for all of them. Even on Windows users have to use regedit from time to time, let's not try to be more catholic than the Pope. Alexandre, what's your minimal set of things for winecfg before we can do the switch?
Coding for Win32 takes ages (too bad we can't use something sane like gtk and be done with it *sigh), so I might not be able to get them all functional in the time I have.
That's fine -- other have expressed intrest, all that we need is to get the patches in in a timely manner so other can pick up where you'll stop. The slow pace for winecfg stems from the fact that people have been keeping patches private, thus effectively blocking others from doing any work.
Another problem we might have is that this is going to be a pretty cluttered and confusing UI if we cram everything possible into it. Do we really have to scrap the config file completely?
Yes, we have. It gets overritten at the end of each session, possibly dropping changes users have made to it. I don't really see any reason to have some values in the regular registry, some in some strange config file that can't be editted through regedit, even though it seems that all these values are in fact regular registry entries. It's just inconsistent.
-- when all this is done, just remove the code from server/registry.c:1475:init_registry()Ah, thanks. I was looking for that piece of code. I'm still not fully sure how Wine overlays the config file onto the registry - if I run regedit the Wine\Wine key seems to be empty?
I'm not sure exactly what's going on there -- I would have expected regedit to see those values. They are marked as VOLATILE which may mean they are not saved, maybe regedit doesn't list such values?
[1] Maybe it's better to have a more descriptive structure detailing stuff for each value, and having generic loadConfig/saveConfig() methods that know how to walk said structure and do the right thing. This way we can easily do add all sorts of attributes to the configuration values and do all sort of nice things, like save only stuff that has been modified, automatically tie in the variable to the control, etc.
Yes, maybe, but some stuff requires custom parsing (like the x11drv thing) - given that it's usually perhaps 3 or 4 lines, I'm not sure doing something fancy here is a good use of time. Constructing the UI and all the logic to manipulate it takes far longer, and can't be automated.
Yeah, we can refactor this later on, you are right, let's just focus on getting the thing running first.
"Dimitrie O. Paun" dimi@intelliware.ca writes:
Man, oh man, quite a bit of stuff. maybe we can get rid of some of them. :) Or maybe we don't need UI stuff for all of them. Even on Windows users have to use regedit from time to time, let's not try to be more catholic than the Pope. Alexandre, what's your minimal set of things for winecfg before we can do the switch?
Well, we need everything that normal users will want to use. But I don't think the priority should be on switching to winecfg as soon as possible; on the contrary we should take the time to review the config, and use that opportunity to clean things up before we make the switch. So for instance if some parameters are too obscure to justify implementing them in winecfg, we should ask whether we really need them in the config at all, or whether we could handle them somehow automatically.
Also we need to fix the code that uses config parameters to try to take into account dynamic changes as much as possible, so that you can make a change from winecfg and see it take effect at once, without having to restart your Wine session.
On Thu, 28 Aug 2003, Alexandre Julliard wrote:
Well, we need everything that normal users will want to use. But I don't think the priority should be on switching to winecfg as soon as possible; on the contrary we should take the time to review the config, and use that opportunity to clean things up before we make the switch. So for instance if some parameters are too obscure to justify implementing them in winecfg, we should ask whether we really need them in the config at all, or whether we could handle them somehow automatically.
Also we need to fix the code that uses config parameters to try to take into account dynamic changes as much as possible, so that you can make a change from winecfg and see it take effect at once, without having to restart your Wine session.
All of which are good things to do, but I'm afraid we're bundeling things together unnecessarily. And this is no good -- we already have velocity problems :)
Removing obsolete parameters is helpful with winecfg, because it can save a lot of work in building the GUI. But to separete the tasks a bit more, I'd say we need a list of the parameters that we want to be able to control through winecfg. The rest will become part of a janitorial cleanup task.
Dealing with dynamic changes in the configuration is orthogonal to the winecfg work. For some performance critical areas is not necessarily feasible, but I suspect most of them can be made dynamic. I can keep this as a separate janitorial task -- I can maintain a list of options with their current status, and whether or not we need to change it from static -> dynamic, etc.
Keeping these 3 task separate does not mean they will be lost and forgoten -- I volunteer to keep track of them independently. In fact, we'll get more work done this way, because different people enjoy working on different bits. Defining exactly what we want winecfg to do will help Mike get the job done faster. Defining explicitly and granularly the paramter cleanup tasks will allow others (not interested in winecfg work) pick up pieces and run with them.
This is good -- a big problem with contributing to Wine is simply that people don't know what needs to be done. Defining such tasks is a good step forward. I am sure there are a lot of people interested in a 0.9 release that are willing to help to reach that goal faster, if only they could pick up small, well-defined tasks.
"Dimitrie O. Paun" dimi@intelliware.ca writes:
Keeping these 3 task separate does not mean they will be lost and forgoten -- I volunteer to keep track of them independently. In fact, we'll get more work done this way, because different people enjoy working on different bits. Defining exactly what we want winecfg to do will help Mike get the job done faster. Defining explicitly and granularly the paramter cleanup tasks will allow others (not interested in winecfg work) pick up pieces and run with them.
Sure, they are separate tasks, it's more an issue of in which order we do things. If we are going to change things in the config tree, then it's a lot easier to do before winecfg is used, otherwise we need to add a lot of backwards compatibility code in there; so I think throwing the switch for winecfg should be one of the last things we do, once the rest is at least well under way. That doesn't prevent working on winecfg, we can do at least 95% of it without having to make it edit the primary config tree.
Also once the config is in the registry it becomes inconvenient to modify by hand, so it implies we first need write support in regedit, and a working default configuration so that regedit/winecfg can actually start without requiring config changes.
On Thu, 28 Aug 2003, Alexandre Julliard wrote:
Sure, they are separate tasks, it's more an issue of in which order we do things. If we are going to change things in the config tree, then it's a lot easier to do before winecfg is used, otherwise we need to add a lot of backwards compatibility code in there; so I think
What kind of backwards compatibility code are you afraid we're going to need?
Also once the config is in the registry it becomes inconvenient to modify by hand, so it implies we first need write support in regedit, and a working default configuration so that regedit/winecfg can actually start without requiring config changes.
Definetly -- these are two things we need (good you mentioned them!) before we can go to winecfg.
"Dimitrie O. Paun" dimi@intelliware.ca writes:
What kind of backwards compatibility code are you afraid we're going to need?
Well, if when cleaning things up we find out that some key should be moved/renamed/using a different syntax, then we need to have winecfg deal with both formats and be able to convert back and forth; while right now we can just say "edit your config and change this". Basically, it's easier to break things before people get used to having a nice interface that does everything for them ;-)
On Thu, 28 Aug 2003, Alexandre Julliard wrote: [...]
Also once the config is in the registry it becomes inconvenient to modify by hand
[...]
That's one thing that bothers me with moving the configuration data to the registry: in the registry you cannot put comments that document what an option does. More precisely, comments are not preserved when wineserver saves the registry so adding comments is an exercise in futility.
The Unix way is to have text configuration files that are self-documented. Not all projects are born equal on this point of course, but look at squid.conf, smb.conf our even our own Wine configuration file for instance.
The Windows way is to have obscure binary parameters in the registry and force you to buy a dozen book to know what 1% of them are for. I.e. most of the options are completely undocumented.
I'm afraid moving the Wine configuration will move us towards the Windows model which is IMO not a model to follow.
Is there a way to use the registry (as seems to be required for many features) and still document our settings correctly? Maybe add a 'Doc' value for each regular value:
[SomeKey] OptionFoo=1 OptionFooDoc="OptionFoo does this, that, etc."
Better ideas?
--- Francois Gouget fgouget@free.fr wrote:
Is there a way to use the registry (as seems to be required for many features) and still document our settings correctly? Maybe add a 'Doc' value for each regular value:
[SomeKey] OptionFoo=1 OptionFooDoc="OptionFoo does this, that, etc."
Better ideas?
Kinda off topic.
It sounds like a good idea and it might work for WINE but the Windows registry is a bloated mess. I have seen Windows registrys get to 40mb+. Adding more keys for documentation like this is just going to make the memory requirements higher and performance worse.
If you wanted to go to a binary format, the ReactOS developers have offered to relicense the code we have as LGPL so you might be able to do this without much of a performance hit. Anyway I havent used WINE on *nix in a while so i dont know if this really is a issue but its something to think about. I am not sure about the compression and performance numbers so it might not be a issue for WINE at this point.
Thanks Steven
__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
On Thu, 28 Aug 2003, Steven Edwards wrote: [...]
It sounds like a good idea and it might work for WINE but the Windows registry is a bloated mess. I have seen Windows registrys get to 40mb+. Adding more keys for documentation like this is just going to make the memory requirements higher and performance worse.
True, registry size is an issue. On the other hand we would only add doc for the Wine configuration settings which should not be that numerous. So the size and performance impact should not be too bad (unless we get sloppy and add myriads of Wine settings).
If you wanted to go to a binary format, the ReactOS developers have offered to relicense the code we have as LGPL so you might be able to do this without much of a performance hit. Anyway I havent used WINE on *nix in a while so i dont know if this really is a issue but its something to think about. I am not sure about the compression and performance numbers so it might not be a issue for WINE at this point.
I think Wine will want to go towards a binary 'database-like' registry format eventually. One goal is to not have to load the whole registry on startup. This is especially useful when the registry is large like after installing MS Office or when using the Windows registry. The performance of loading the registry used to be abysmal but it was improved greatly a couple of years ago and since then it's not a big issue anymore.
On Fri, 29 Aug 2003 01:49:51 +0200, Sir Francois Gouget scribed thus:
The Unix way is to have text configuration files that are self-documented. Not all projects are born equal on this point of course, but look at squid.conf, smb.conf our even our own Wine configuration file for instance.
We can always put info on what the settings do in the users guide. However, I think a lot of the more obscure options could simply be killed off. For instance, what is DirectSoundHEL, and why do I need to set it manually? Can that not be auto-detected, with sufficient cleverness? I'm a developer, and I still don't understand what it does, or why it needs to be set, Win32 is just too huge to understand all of it.
Very few prefs for Wine are actually genuine user preferences. They are mostly settings that you need to tweak either for your environment, or to make apps run correctly. Both of those settings should ultimately go.
thanks -mike
--- Francois Gouget fgouget@free.fr wrote:
On Thu, 28 Aug 2003, Alexandre Julliard wrote: [...]
Also once the config is in the registry it becomes inconvenient to modify by hand
[...]
That's one thing that bothers me with moving the configuration data to the registry: in the registry you cannot put comments that document what an option does. More precisely, comments are not preserved when wineserver saves the registry so adding comments is an exercise in futility.
The Unix way is to have text configuration files that are self-documented. Not all projects are born equal on this point of course, but look at squid.conf, smb.conf our even our own Wine configuration file for instance.
The Windows way is to have obscure binary parameters in the registry and force you to buy a dozen book to know what 1% of them are for. I.e. most of the options are completely undocumented.
I'm afraid moving the Wine configuration will move us towards the Windows model which is IMO not a model to follow.
Is there a way to use the registry (as seems to be required for many features) and still document our settings correctly? Maybe add a 'Doc' value for each regular value:
[SomeKey] OptionFoo=1 OptionFooDoc="OptionFoo does this, that, etc."
Better ideas?
Not sure how possible this is or if it has already been thought of just let me know, but what about loading the config into memory and having wine make it look like the registry while loaded (ie for windows regedit). wine can do the processing of both the registry and the config, and then when it is time to save the changes done in regedit, wine sorts it out between what needs to be written to the actual registry and what needs to be written to the config file. That way we have the registry, but we can keep the traditional unix (and all variants) plaintext config file, with documentation for the more advanced users, but if an end user wants to edit the config thru the registry, he can..
Of course winelib regedit should be modified to load the config file and make it look like standard registry keys as well, if it doesnt already, for the people willing to forego installing/copying a ms program (ie windows regedit) on their linux partitions.. lol
Comments/Flames/Suggestions?
===== -- Dustin Navea
Minor Contributor, http://www.winehq.com Bugzilla Janitor, http://bugs.winehq.com Network Admin, irc://irc.blynk.net (down)
__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
On Fri, 29 Aug 2003, Dustin Navea wrote: [...]
Not sure how possible this is or if it has already been thought of just let me know, but what about loading the config into memory and having wine make it look like the registry while loaded (ie for windows regedit).
I believe Wine already does somethin like this, but maybe not.
[...]
wine can do the processing of both the registry and the config, and then when it is time to save the changes done in regedit, wine sorts it out between what needs to be written to the actual registry and what needs to be written to the config file.
But in any case, this is where you hit problems. When loading the registry or the configuration, Wine simply ignores the comments. And when saving the changes Wine rewrites the registry file from scratch. If we do the same for the configuration file it means we loose all the comments, making it pointless to put them in in the first place...
Of course we could have a special case for the configuration file so that we keep the comments in memory, maybe also keep the file layout and then merge the changes when we save. But that means using a different codebase for the settings and for the registry which I believe is the opposite of what we want to do by moving the settings to the registry.
--- Francois Gouget fgouget@free.fr wrote:
On Fri, 29 Aug 2003, Dustin Navea wrote: [...]
Not sure how possible this is or if it has already been thought of just
let
me know, but what about loading the config into memory and having wine
make
it look like the registry while loaded (ie for windows regedit).
I believe Wine already does somethin like this, but maybe not.
[...]
wine can do the processing of both the registry and the config, and then when it is
time
to save the changes done in regedit, wine sorts it out between what needs
to
be written to the actual registry and what needs to be written to the
config
file.
But in any case, this is where you hit problems. When loading the registry or the configuration, Wine simply ignores the comments. And when saving the changes Wine rewrites the registry file from scratch. If we do the same for the configuration file it means we loose all the comments, making it pointless to put them in in the first place...
hmm, I thought that that was why we have the saveonlyupdatedkeys option was to have it only write the keys whose values had changed.. I guess I was mistaken then. How come we rewrite the entire registry, and not just the new/changed data? It seems to me like that would be a CPU cycle killer when it comes to writing that sort of stuff, if the registry is any more than like (i guess?) 10 megs
Of course we could have a special case for the configuration file so that we keep the comments in memory, maybe also keep the file layout and then merge the changes when we save. But that means using a different codebase for the settings and for the registry which I believe is the opposite of what we want to do by moving the settings to the registry.
What if it were to read the comments into a/some comments variable/s and then treat the config file as part of the registry? Or would that still be too much of a different codebase?
===== -- Dustin Navea
Minor Contributor, http://www.winehq.com Bugzilla Janitor, http://bugs.winehq.com Network Admin, irc://irc.blynk.net (down)
__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
On Thu, 2003-08-28 at 19:02, Alexandre Julliard wrote:
Well, we need everything that normal users will want to use. But I don't think the priority should be on switching to winecfg as soon as possible; on the contrary we should take the time to review the config, and use that opportunity to clean things up before we make the switch. So for instance if some parameters are too obscure to justify implementing them in winecfg, we should ask whether we really need them in the config at all, or whether we could handle them somehow automatically.
That sounds almost GNOME like Alexandre :) There are indeed a lot of massively obscure settings, "Perfect Graphics" would be one I'd vote for dropping. I've read the code, and I still can't figure out *exactly* what difference it'd make, especially to end user apps. There's no real way to explain "uses optimized raster ops" to an end user in a meaningful way.
Of course ideally Wine would not need any configuration at all. That might be a good long term goal.
Also we need to fix the code that uses config parameters to try to take into account dynamic changes as much as possible, so that you can make a change from winecfg and see it take effect at once, without having to restart your Wine session.
If we want to do that, it's worth deciding now, as it affects how winecfg operates. At the moment changes to the GUI are moved to and fro the structure in bulk, then the struct is saved to the registry, again in bulk. That lets us do "OK/Cancel". If we want instant apply, that complicates things.
Mike Hearn mike@theoretic.com writes:
If we want to do that, it's worth deciding now, as it affects how winecfg operates. At the moment changes to the GUI are moved to and fro the structure in bulk, then the struct is saved to the registry, again in bulk. That lets us do "OK/Cancel". If we want instant apply, that complicates things.
It should definitely be possible to apply a subset of changes; we don't want to rewrite the full config everytime a change is made. If I toggle the "managed" flag for instance I expect that specific key to be written to the registry, nothing else. Yes, it will complicate the implementation a bit...
On Thu, 2003-08-28 at 21:02, Alexandre Julliard wrote:
It should definitely be possible to apply a subset of changes; we don't want to rewrite the full config everytime a change is made. If I toggle the "managed" flag for instance I expect that specific key to be written to the registry, nothing else. Yes, it will complicate the implementation a bit...
OK. That's not how my current codebase works, but apply the patches anyway and I'll steer it onto a different course.
Probably the best way to do it is to have a queue of transaction structures, and each time you want to change a registry key (or rather section/value pair) a new ConfigureTransaction is added to the tail of the queue. The queue can either be processed instantly, or block until OK/Cancel.
Alternatively, you can also place marks in the queue, so you can do gnome2 style "Revert" buttons, ie all changes take effect immediately (or rather are written to the registry immediately), but you can basically undo any changes you made while the dialog is still open.
That'd probably work quite well, though if we have an UI complex enough to need revert buttons we've probably gone wrong somewhere.
Sound good?
On 28 Aug 2003, Mike Hearn wrote:
Probably the best way to do it is to have a queue of transaction structures, and each time you want to change a registry key (or rather section/value pair) a new ConfigureTransaction is added to the tail of the queue. The queue can either be processed instantly, or block until OK/Cancel.
That, or having a dirty flag would work as well. I think we should have a structure describing each value:
struct config_param { const char *name; void *value; /* or we can have a union here */ int dirty; const char *flyby_help; HWND control; /* etc, etc. */ }
On "Apply", we can simply walk the list and commit all things that are dirty. In general, I think it will be helpful going forward to be able to have such a thing in place so we can easily associtate metadata with each value.
-
Alexandre Julliard -
Dimitrie O. Paun -
Dimitrie O. Paun -
Dustin Navea -
Francois Gouget -
Mike Hearn -
Steven Edwards