gtk preferences todo list
lool at via.ecp.fr
Tue Mar 26 00:48:23 CET 2002
Why the preferences window sucks, and why it isn't its fault :
* It's too big : this is because of the huge clists (the tables with
the list of available plugins) and the fact that some tabs have two
clists (with exactly the same options).
To solve this we should have different module types for the filter
and *out plugins. First this would cause the clist to be half so big
because it would only list the plugins of one type, second the tabs
would only hold one clist instead of two. It is not an easy task
because it is actually necessary for filter modules to look exactly
like *out modules.
Another way to solve this (but I think we have to implement the
first solution anyway) would to use a combo box instead of the clist
where we could choose only one of the modules, and aside of it a
"Configuration" button which would open a new window where we could
configure all plugins of the current type (thanks to fenrir and sam
for suggesting this).
* A lot of descriptions are missing. They are defined in
src/interface/main.c as "_text" and "_longtext" definitions. If you
have some time it would be cool to add some of these because they are
used in tooltips.
* The highlight of checkboxes is not extended to the description
beside them which confuses the user. If you know a way of achieving
this in gtk, I'm interested. This is because of the gtk structure used
to align the descriptions verticaly, this structure also makes the
tooltip between the description and the widget (if you place the
cursor between them). This is actually something I consider as a BUG
but it's a lot of dirty work to correct it and is not so disturbing.
* For things like the audio output format, we need a new type of
module option where you can only choose one. The same type could be
used for a plugin selection (for example --vout could only be x11, xv,
or sdl and not any string like in the "Selected :" text box right now).
Another example of this would be audio output frequency, but it
should be read of the output device (not in the interface code of
course), and this is non-trivial.
Help and critics needed,
Loïc Minier <lool at via.ecp.fr>
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://www.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>
More information about the vlc-devel