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

[Mike Hearn]

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.