Re: [winecfg 1.1] Implement saveConfigValue(), style changes, code cleanup, UI alignment

2003-08-31 Thread Dustin Navea
--- 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

2003-08-30 Thread Dustin Navea
--- 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

2003-08-29 Thread Steven Edwards
--- 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

2003-08-29 Thread Mike Hearn
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

2003-08-28 Thread Dimitrie O. Paun
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.