Hi folks,
I've finally managed to do the table I've promised for so long. My appologies for the delay.
This has been mind numbing work, and as such I haven't payed that much attention to the values I've filled in those columns. Please send me your comments so I can post a final version of this to the WineHQ site soon.
Note: best viewed in a web browser, but an editor that can display about 150 columns would do just fine as well.
Cool!
Just a few things - there are some settings marked as being for winecfg that I don't think we really should have there. In particular:
* UseDGA * GraphicsDriver * ShellLinker * DesktopDoubleBuffered (not sure about this one) * Fonts/fontdirs - after Huw merges his crossover patches these should become automatic on fontconfig systems (ie soon to be most systems), perhaps regedit? * Spooler - isn't CUPS meant to take care of that? * Ports - hex values in the config gui?!?
The rest looks A-OK to me :)
On Tue, 2003-09-16 at 22:10, Dimitrie O. Paun wrote:
Hi folks,
I've finally managed to do the table I've promised for so long. My appologies for the delay.
This has been mind numbing work, and as such I haven't payed that much attention to the values I've filled in those columns. Please send me your comments so I can post a final version of this to the WineHQ site soon.
Note: best viewed in a web browser, but an editor that can display about 150 columns would do just fine as well.
On Wed, Sep 17, 2003 at 12:40:20PM +0100, Mike Hearn wrote:
Cool!
Just a few things - there are some settings marked as being for winecfg that I don't think we really should have there. In particular:
- Fonts/fontdirs - after Huw merges his crossover patches these should
become automatic on fontconfig systems (ie soon to be most systems), perhaps regedit?
This sounds reasonable to me.
- Spooler - isn't CUPS meant to take care of that?
It does if the system has cups. It's still needed for non-cups printers though.
Huw.
On September 17, 2003 08:25 am, Huw D M Davies wrote:
- Spooler - isn't CUPS meant to take care of that?
It does if the system has cups. It's still needed for non-cups printers though.
Right, but can we leave the non-cups to regedit? How common are cups systems, and most importantly, what is the trend? Did most distros switched to it? If by the time we release 0.9 most users are on cups, we may not need GUI in winecfg for it...
On Wed, Sep 17, 2003 at 08:34:59AM -0400, Dimitrie O. Paun wrote:
On September 17, 2003 08:25 am, Huw D M Davies wrote:
- Spooler - isn't CUPS meant to take care of that?
It does if the system has cups. It's still needed for non-cups printers though.
Right, but can we leave the non-cups to regedit? How common are cups systems, and most importantly, what is the trend? Did most distros switched to it? If by the time we release 0.9 most users are on cups, we may not need GUI in winecfg for it...
The trend is towards cups, but my guess is that there'll be a sizeable minority still using lpr/lprng/etc for years to come. Actually that's ok then isn't it? 0.9 won't be released for at least another decade :) Seriously, I think we can probably let the non-cups people struggle with regedit, it may give them the incentive they need to switch to cups. If they shout loud enough we can always add it to winecfg later.
Huw.
On September 17, 2003 07:40 am, Mike Hearn wrote:
Cool!
Just a few things - there are some settings marked as being for winecfg that I don't think we really should have there. In particular:
- UseDGA
I thought this is interesting for games. But have you figured when we use this thing (if at all?). Lionel, what is this useful for?
- GraphicsDriver
Fell through the cracks...
- ShellLinker
Copy & Paste error
- DesktopDoubleBuffered (not sure about this one)
This is useful for games, so I've figured it's interesting for end users.
- Fonts/fontdirs - after Huw merges his crossover patches these should
become automatic on fontconfig systems (ie soon to be most systems), perhaps regedit?
Would that include stuff in [afmdirs] as well? That's that use for BTW?
- Spooler - isn't CUPS meant to take care of that?
Right, but would that include "FILE:" too? In windows you have GUI for setting the filename IIRC...
- Ports - hex values in the config gui?!?
Right, I don't know what I was thinking :)
The rest looks A-OK to me :)
Cool, but did I miss any? To come up with the list, I've started with the documentation/samples/config file. Are there options that should be listed not present in that file?
I've attached a new version. Now, I'd like to know: -- Do everybody agree with the "Needed" column? Most importantly, do you see items marked as "cfg" that shouldn't, or items that are not marked as "cfg" and they should? Please take a few min to review the list, so we can have a better idea of what needs to be done in winecfg. -- Did I miss any? To come up with the list, I've started with the documentation/samples/config file. Are there options that should be listed not present in that file? -- What about the Dynamic column? Did I miss any or did I include too many? -- Same questions for the PerApp column.
Guys, we need everyone's help with this one. As the next step I'd like to make sure that: (1) the list is complete (2) we all agree on the Needed/Dynamic/PerApp columns.
This is very important for a number of reasons, including: -- puts a bound on what we need to do -- provides a clear and concise list of what needs to happen -- helps Mike with the important winecfg work
Once we do that, we can start arguing about the default values, these may prove a bit trickier with the autodetection stuff, etc.
Everyone's comments are appreciated.
Dimitrie O. Paun wrote:
Name Needed Dynamic PerApp Default value [Drive X] Path cfg yes no Type cfg yes no Label cfg yes no Serial cfg yes no Filesystem cfg yes no Device cfg yes no
I don't quite agree on the "yes" flag for dynamicity. (Unless I don't understand the same thing as you do regarding dynamicity). Changing the registry shouldn't trigger anything here. We should however be able to add/remove drive at runtime, but there are regular APIs for that (except perhaps for the permanent bits).
[WinMM] Drivers regedt no no <auto> WaveMapper regedt no no msacm.drv MidiMapper regedt no no midimap.drv
will need in the future a more robust configuration scheme, especially if we want to get rid of the hacks to pair MM devices and dsound devices. By <auto> to you mean a default value has to be computed by wincfg, or shall wine be able to run even if no value has been set yet ? (first option is quite doable for MM, second is a bit more unclear). I'd add a few others options: "MidiMapper settings" regedt no no none
Don't forget also a couple of configuration bits still remaining in system.ini (in particular, mci and msacm drivers definition). Those also exist in registry (under windows) but haven't been ported to wine (yet)
A+
On Wed, 17 Sep 2003, Eric Pouech wrote:
Dimitrie O. Paun wrote:
Name Needed Dynamic PerApp Default value [Drive X] Path cfg yes no Type cfg yes no Label cfg yes no Serial cfg yes no Filesystem cfg yes no Device cfg yes no
I don't quite agree on the "yes" flag for dynamicity. (Unless I don't understand the same thing as you do regarding dynamicity). Changing the registry shouldn't trigger anything here. We should however be able to add/remove drive at runtime, but there are regular APIs for that (except perhaps for the permanent bits).
Yes, I realized it was a bit unclear, I meant we should be able to change the drive definitions. I'll update the table accordingly.
[WinMM] Drivers regedt no no <auto> WaveMapper regedt no no msacm.drv MidiMapper regedt no no midimap.drv
will need in the future a more robust configuration scheme, especially if we want to get rid of the hacks to pair MM devices and dsound devices. By <auto> to you mean a default value has to be computed by wincfg, or shall wine be able to run even if no value has been set yet ? (first option is quite doable for MM, second is a bit more unclear).
I was hoping we can detect that at runtime. Even if we don't, Wine should run (without sound) without a setting here.
I'd add a few others options: "MidiMapper settings" regedt no no none
Don't forget also a couple of configuration bits still remaining in system.ini (in particular, mci and msacm drivers definition). Those also exist in registry (under windows) but haven't been ported to wine (yet)
Can you please give me a explicit list of such settings? "MidiMapper settings" doesn't fit well in the current format. Besides, it will be generally useful to have a comprehensive list of all possible settings.
[WinMM] Drivers regedt no no <auto> WaveMapper regedt no no msacm.drv MidiMapper regedt no no midimap.drv
will need in the future a more robust configuration scheme, especially if we want to get rid of the hacks to pair MM devices and dsound devices. By <auto> to you mean a default value has to be computed by wincfg, or shall wine be able to run even if no value has been set yet ? (first option is quite doable for MM, second is a bit more unclear).
I was hoping we can detect that at runtime. Even if we don't, Wine should run (without sound) without a setting here.
the point is that it's not easy to tell between : - two physical sound cards (one ALSA, one OSS) - one physical sound card but with ALSA and OSS emulation on top of ALSA moreover, we'll have to store winmm card information to dsound driver somewhere in order to link them (and stop using the current hack) that's why some driver configuration will be necessary in the registry
I'd add a few others options: "MidiMapper settings" regedt no no none
Don't forget also a couple of configuration bits still remaining in system.ini (in particular, mci and msacm drivers definition). Those also exist in registry (under windows) but haven't been ported to wine (yet)
Can you please give me a explicit list of such settings? "MidiMapper settings" doesn't fit well in the current format. Besides, it will be generally useful to have a comprehensive list of all possible settings.
see comment at the top of dlls/winmm/midimap/midimap.c
for the other settings , you have : - the list of audio & video codecs (in driver32 section from system.ini) - the list of known mci drivers. Firstly, looked for in the options section of the wine config file. If nothing is defined, it's looked for in the mci section in the system.ini file
A+
On September 18, 2003 01:26 pm, Eric Pouech wrote:
the point is that it's not easy to tell between :
- two physical sound cards (one ALSA, one OSS)
- one physical sound card but with ALSA and OSS emulation on top of ALSA
moreover, we'll have to store winmm card information to dsound driver somewhere in order to link them (and stop using the current hack) that's why some driver configuration will be necessary in the registry
Yes, we can't quite guess all this right, this is a job for freedesktop.org to standardize some setting so apps can easily get to that kind of info. It's just stupid that apps (outside KDE/GNOME) need to have their own setup dialogs, etc. And even more silly is that the user has to configure all this crap so many times it's not even funny.
see comment at the top of dlls/winmm/midimap/midimap.c
for the other settings , you have :
- the list of audio & video codecs (in driver32 section from system.ini)
- the list of known mci drivers. Firstly, looked for in the options
section of the wine config file. If nothing is defined, it's looked for in the mci section in the system.ini file
What about the stuff in win.ini/[mci extensions]. Is that used?
I've added the following as regedit settings:
[Software\Microsoft\Windows\CurrentVersion\Multimedia\MIDIMap] AutoScheme no no 0 ConfigureCount no no 4 CurrentInstrument no no Wine OSS midi CurrentScheme no no epp DriverList no no UseScheme no no 0 [System\CurrentControlSet\Control\MediaProperties\PrivateProperties\Midi\Schemes\] <nameScheme> no no [System\CurrentControlSet\Control\MediaProperties\PrivateProperties\Midi\Schemes\\] Channels no no system.ini/[mci] (needs porting to the registry) cdaudio no no mcicda.drv sequencer no no mciseq.drv waveaudio no no mciwave.drv avivideo no no mciavi.drv videodisc no no mcipionr.drv vcr no no mcivisca.drv MPEGVideo no no mciqtz.drv system.ini/[drivers32] (needs porting to the registry) MSACM.imaadpcm no no imaadp32.acm MSACM.msadpcm no no msadp32.acm VIDC.MRLE no no msrle32.dll win.ini/[mci extensions] (needs porting to the registry) cda no no cdaudio mid no no sequencer midi no no sequencer rmi no no sequencer aif, aifc, aiff... no no MPEGVideo
On Mon, 2003-09-22 at 05:50, Dimitrie O. Paun wrote:
On September 18, 2003 01:26 pm, Eric Pouech wrote:
the point is that it's not easy to tell between :
- two physical sound cards (one ALSA, one OSS)
- one physical sound card but with ALSA and OSS emulation on top of ALSA
moreover, we'll have to store winmm card information to dsound driver somewhere in order to link them (and stop using the current hack) that's why some driver configuration will be necessary in the registry
How many people really two different sound cards using two entirely different driver models at the same time? We can at least have a sensible default here.
Mike Hearn wrote:
On Mon, 2003-09-22 at 05:50, Dimitrie O. Paun wrote:
On September 18, 2003 01:26 pm, Eric Pouech wrote:
the point is that it's not easy to tell between :
- two physical sound cards (one ALSA, one OSS)
- one physical sound card but with ALSA and OSS emulation on top of ALSA
moreover, we'll have to store winmm card information to dsound driver somewhere in order to link them (and stop using the current hack) that's why some driver configuration will be necessary in the registry
How many people really two different sound cards using two entirely different driver models at the same time? We can at least have a sensible default here.
the default would be if both ALSA and OSS work on default card, then use ALSA, but it'll be hard to get further (especially when thinking of esd or arts). Except, if we just have a simple question: share the sound access with other apps => if yes, then try esd, arts... if no, then alsa or oss
A+
Dimitrie O. Paun wrote:
On September 18, 2003 01:26 pm, Eric Pouech wrote:
the point is that it's not easy to tell between :
- two physical sound cards (one ALSA, one OSS)
- one physical sound card but with ALSA and OSS emulation on top of ALSA
moreover, we'll have to store winmm card information to dsound driver somewhere in order to link them (and stop using the current hack) that's why some driver configuration will be necessary in the registry
Yes, we can't quite guess all this right, this is a job for freedesktop.org to standardize some setting so apps can easily get to that kind of info. It's just stupid that apps (outside KDE/GNOME) need to have their own setup dialogs, etc. And even more silly is that the user has to configure all this crap so many times it's not even funny.
agreed, but in the mean time we have to do something.
see comment at the top of dlls/winmm/midimap/midimap.c
for the other settings , you have :
- the list of audio & video codecs (in driver32 section from system.ini)
- the list of known mci drivers. Firstly, looked for in the options
section of the wine config file. If nothing is defined, it's looked for in the mci section in the system.ini file
What about the stuff in win.ini/[mci extensions]. Is that used?
yes, in some internal mci function (but that doesn't need to be changed by end users. we just need to list the default extensions for the given mci playback. I haven't found yet an equivalent in the registry
I've added the following as regedit settings:
[Software\Microsoft\Windows\CurrentVersion\Multimedia\MIDIMap] AutoScheme no no 0 ConfigureCount no no 4 CurrentInstrument no no Wine OSS midi CurrentScheme no no epp DriverList no no UseScheme no no 0 [System\CurrentControlSet\Control\MediaProperties\PrivateProperties\Midi\Schemes\] <nameScheme> no no [System\CurrentControlSet\Control\MediaProperties\PrivateProperties\Midi\Schemes\\] Channels no no
(those, BTW, are standard windows' registry entries)
A+
On Tue, 23 Sep 2003, Eric Pouech wrote:
What about the stuff in win.ini/[mci extensions]. Is that used?
yes, in some internal mci function (but that doesn't need to be changed by end users. we just need to list the default extensions for the given mci playback. I haven't found yet an equivalent in the registry
Well, it would be real nice to move these to the registry. If MS has no place, we can invent one of our own. To keep compatibility, we can look in win.ini, if not there, look in the registry. That will allow us to drop win.ini altogether, and have a cleaner install, simple documentation, etc.
Dimitrie O. Paun wrote:
On Tue, 23 Sep 2003, Eric Pouech wrote:
What about the stuff in win.ini/[mci extensions]. Is that used?
yes, in some internal mci function (but that doesn't need to be changed by end users. we just need to list the default extensions for the given mci playback. I haven't found yet an equivalent in the registry
Well, it would be real nice to move these to the registry. If MS has no place, we can invent one of our own. To keep compatibility, we can look in win.ini, if not there, look in the registry. That will allow us to drop win.ini altogether, and have a cleaner install, simple documentation, etc.
didn't search hard enough in fact, I was searching in Win9x, where it isn't present, and only configured in .ini files. In NT, they seem to be stored in
for win.ini in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\MCI Extensions
for system.ini in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\MCI32
A+
On September 23, 2003 02:47 pm, Eric Pouech wrote:
didn't search hard enough in fact, I was searching in Win9x, where it isn't present, and only configured in .ini files. In NT, they seem to be stored in
for win.ini in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\MCI Extensions
for system.ini in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\MCI32
OK, thank you (better late than never! :)
What about for system.ini/[drivers32]?
Dimitrie O. Paun wrote:
On September 23, 2003 02:47 pm, Eric Pouech wrote:
didn't search hard enough in fact, I was searching in Win9x, where it isn't present, and only configured in .ini files. In NT, they seem to be stored in
for win.ini in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\MCI Extensions
for system.ini in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\MCI32
OK, thank you (better late than never! :)
What about for system.ini/[drivers32]?
on NT, it's HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\drivers32, and it doesn't seem there's a win9x equivalent
A+
On Wed, 17 Sep 2003, Dimitrie O. Paun wrote: [...]
-- Do everybody agree with the "Needed" column? Most importantly, do you see items marked as "cfg" that shouldn't, or items that are not marked as "cfg" and they should? Please take a few min to review the list, so we can have a better idea of what needs to be done in winecfg.
I'm not clear about that one:
Name Needed Dynamic PerApp Default value Managed no no no
Do you mean to remove the option altogether and hard-code it to 'managed'?
While I agree that managed mode is the one true mode, I'm not sure we can completely remove the unmanaged mode: * until the window management rewrite is done we will still have Z-order issues that require either the unmanaged or desktop mode. Note that it's not 100% sure that these issues will be solved even after the window management rewrite. * afaik we cannot display the system menu in managed mode, i.e., in managed mode, clicking on the top-left window corner gives the window manager menu and not the application specified menu. Fortunately one very rarely needs this.
On Tue, 23 Sep 2003, Francois Gouget wrote:
Do you mean to remove the option altogether and hard-code it to 'managed'?
That was the intention at the time. I've changed it since to regedit -- it's good enough for now. I am aware of the Z-order problems, hopefully we'll get most apps to work in Managed mode before 0.9. It's on the TODO...
- UseDGA
This will be useful the day the DGA driver will have been fixed. Also the day we will use DGA mouse to have nice relative mouse grabbing :-)
- DesktopDoubleBuffered (not sure about this one)
Well, I think we should put this as True as default. At least, I never heard any report of issues / slowdowns with this set to TRUE. This option will be needed for quite some time (as the window management rewrite needed to suppress is not really in any Wine 1.0 scope).
Lionel
On Wed, 2003-09-17 at 20:30, Lionel Ulmer wrote:
- UseDGA
This will be useful the day the DGA driver will have been fixed. Also the day we will use DGA mouse to have nice relative mouse grabbing :-)
Yeah, sure, that's why I wanted it in the registry. It's broke. When it is fixed, we can put it back into the GUI (or better, have some auto detect code).
- DesktopDoubleBuffered (not sure about this one)
Well, I think we should put this as True as default. At least, I never heard any report of issues / slowdowns with this set to TRUE. This option will be needed for quite some time (as the window management rewrite needed to suppress is not really in any Wine 1.0 scope).
OK, will do, thanks.
-mike
-
Dimitrie O. Paun -
Dimitrie O. Paun -
Eric Pouech -
Francois Gouget -
Huw D M Davies -
Lionel Ulmer -
Mike Hearn