Updated winecfg to do list

[Mike Hearn]

OK, well assuming that Alexandre commits the last of my patches to 
winecfg at some point (I suspect there is a reason they aren't already 
...), here is the updated todo list for winecfg based on my last email 
on the subject:

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