Updated winecfg to do list
m.hearn at signal.QinetiQ.com
Wed Sep 29 05:53:12 CDT 2004
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:
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 is "--drive-detect")
gui_mode = FALSE;
> - 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
> - The Add/Remove application buttons are *way* too big!
> - 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,
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?
> - 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.
More information about the wine-devel