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.