http://www.winehq.org/hypermail/wine-devel/2004/08/0007.html
I'm probably not going to do any more work on winecfg for a while.
You probably want to increase the size of the drive mappings list so it fills the tab, currently there is just a lot of empty space at the top of the pane now you removed the old stuff.
If AJ commits the last two patches, this is done. In fact, the editing has been moved into the main tab, as there isn't much reason to have a separate window for this and it simplifies the UI and code somewhat.
Also we should kill the autodetect button. This is done by wineprefixcreate these days, or should be.
Getting there ... drive autodetection is implemented. The heuristics could perhaps be improved but they'll do for now. But, we need to call it from wineprefixcreate. This means adding code like so to main():
if (argv[0] is "--drive-detect")
{
gui_mode = FALSE;
auto_detect_drives();
return apply_drive_changes();
}- Drive editing seems broken. The list box only updates the second time I hit edit. err:winecfg:applyDriveChanges unable to set volume label for devicename of 'H:\', label of ''
With my last two patches, this works for me.
- Browse in the "Add/Edit drive" dialog is a WRITEME
Oh hum, good point. I suspect this still does nothing, I don't remember.
We need to make sure / is mapped (there is a function to do this in drivedetect.c), trigger the shell directory select dialog, then if we had to map / automatically, unmap it again. Not too hard to implement. We can probably slide this for 0.9, it's not essential.
- Build system isn't right: I did a cvs update but the res files weren't recreated properly. I had to do a make clean to get the gui updates.
Probably my [ab]uses of make depend, can be ignored.
- "Add Application" has poor usability: we always use a file browser dialog box even though the most common use case is just "foo.exe", ie the user knows the name and doesn't care about the location. Worse we start in the c:\windows\desktop folder for some reason, meaning users might accidentally select a .lnk file!
Well, we still use a file open dialog but at least it starts in c:\ now and is filtered on EXE files. If somebody wants to implement a natty dialog like the GNOME run window, go for it! This would be a nice usability improvement, especially if you implemented then used listview tile mode.
- The Add/Remove application buttons are *way* too big!
Fixed
- Obviously, once audio autodetection has been moved into the drivers we need to kill the audio tab.
Still needs to be done. Not all that hard.
- Libraries tab just has generally poor usability, actually. The first item in the radio group is "Builtin" meaning that's the one users are most likely to select, it should be "builtin, native" followed by "native, builtin"
Lots of tweaks to this tab, I find it a lot more convenient to work with now. The main remaining problem is that enter always triggers OK in the applet itself, and when you're typing in a new DLL you want to add, you want enter to add it not close the window! Not sure how to fix this without messing up the property sheet API.
- We ask the user to understand a magic * symbol to set the default - what is up with that?
Fixed.
- There are no helpful default entries in the drop down box for setting a DLL override, and when you add one the tree does not expand so to actually *set* it you have to expand the tree then select the new override.
It doesn't use a treeview anymore, but the combo box could definitely use some of the most common entries to give people a hint.
- We have way too many (eg, more than zero) tree controls in this app.
Fixed. This simplifies the code enormously. I don't think there's really any problem with selecting the app you want to edit on the first tab and it means there aren't any wierd states anymore where you can have a selection in the treeview that doesn't actually mean anything. The titlebar now reflects the app you're editing.
- Drive mappings list is really unclear, there's no separation between the "Drive X:" label and the unix path its mapped to.
This is improved a bit now too but really I'd like to see us use the listview control with a header control here.
So in summary the BIG things we need to do before we can consider winecfg good enough for 0.9 are:
* Delete the audio tab and use autodetection at wine startup instead * Add a --drive-detect switch and use it from wineprefixcreate * Update the docs to reflect usage of the new tool (Brian is on this)
After 0.9 we can look at more UI improvements, importing some artwork to make it prettier, maybe eliminating the property sheet as that's a big pain to work with (though, it may be also that our control is buggy :), and so on. Probably adding more prefs as well, for things like printing and fonts maybe.
I'd like to see us get winecfg to some kind of finished, releasable 1.0 state before the end of the year though and then we can mark that task as done on the TODO list.
thanks -mike
