Re: [winecfg 1.1] Implement saveConfigValue(), style changes, codecleanup, UI alignment
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 [EMAIL PROTECTED]http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...
Re: [winecfg 1.1] Implement saveConfigValue(), style changes, codecleanup, UI alignment
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. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ We are Pentium of Borg. You will be approximated. Division is futile.
Re: [winecfg 1.1] Implement saveConfigValue(), style changes, codecleanup, UI alignment
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.
Re: [winecfg 1.1] Implement saveConfigValue(), style changes, codecleanup, UI alignment
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. -- Dimi.
Re: [winecfg 1.1] Implement saveConfigValue(), style changes, codecleanup, UI alignment
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. -- Dimi.
Re: [winecfg 1.1] Implement saveConfigValue(), style changes, codecleanup, UI alignment
Dimitrie O. Paun [EMAIL PROTECTED] 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. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [winecfg 1.1] Implement saveConfigValue(), style changes, codecleanup, UI alignment
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. -- Dimi.
Re: [winecfg 1.1] Implement saveConfigValue(), style changes, codecleanup, UI alignment
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.
Re: [winecfg 1.1] Implement saveConfigValue(), style changes, codecleanup, UI alignment
Dimitrie O. Paun [EMAIL PROTECTED] 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 ;-) -- Alexandre Julliard [EMAIL PROTECTED]
Re: [winecfg 1.1] Implement saveConfigValue(), style changes, codecleanup, UI alignment
Mike Hearn [EMAIL PROTECTED] 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... -- Alexandre Julliard [EMAIL PROTECTED]
Re: [winecfg 1.1] Implement saveConfigValue(), style changes, codecleanup, UI alignment
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?
Re: [winecfg 1.1] Implement saveConfigValue(), style changes, codecleanup, UI alignment
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.
--
Dimi.
