Re: [winecfg 1.1] Implement saveConfigValue(), style changes, code cleanup, UI alignment
--- Francois Gouget [EMAIL PROTECTED] 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
Re: [winecfg 1.1] Implement saveConfigValue(), style changes, code cleanup, UI alignment
--- Francois Gouget [EMAIL PROTECTED] 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
Re: [winecfg 1.1] Implement saveConfigValue(), style changes, code cleanup, UI alignment
--- Francois Gouget [EMAIL PROTECTED] 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
Re: [winecfg 1.1] Implement saveConfigValue(), style changes, code cleanup, UI alignment
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
Re: [winecfg 1.1] Implement saveConfigValue(), style changes, code cleanup, UI alignment
On August 28, 2003 06:50 am, Mike Hearn wrote: 2) 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. -- Dimi.