gtk preferences todo list
gbazin at netcourrier.com
Tue Mar 26 22:13:27 CET 2002
On Tuesday 26 March 2002 00:48, Loïc Minier wrote:
> 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).
I don't really agree with this. If the interface is too big, it's because
no limit is imposed on its size. Ok the clists are big, but you cannot rely
on the fact that a clist will have only a few items. For example in the
future we could have 20 or more filter plugins...
I think you need to set a maximum size and add a scrollbar for some widgets
like the plugin lists and the main interface ( like it was done in first
version of the interface ;)
Even if you decide to change the plugin list into a combobox, you still
have the problem that you don't know how many options the current category
will have... if there are too many you'll then have the same problem....
The size of the font can matter too, even with few option you can get a big
interface if the font is quite big.
And yes, I've been looking at the web site you told me about
(www.iarchitect.com/tabs.htm) but I'm still convinced we should use
scrollbars, especially since the interface is generated dynamically and
these scrollbars will only be shown if they are needed.
As for using a combo box for selecting plugins, well I originally did this
when I was working on the interface but as I also wanted an easy way to
configure all the plugins, I decided for a clist. If you manage to build
something more convenient to access the plugins configuration then I'm all
for it :) (right now I don't really see how you want to do this. Maybe you
could develop this a little bit more ?)
Apart from that, I do agree we'll need to differentiate the filters from
the output plugins (add MODULE_CAPABILITY_AOUT_FILTER and
> * 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.
With the current configuration architecture, we cannot do this ( I mean:
propose only a few possible values for an option). This configuration
modules has been designed to be simple but flexible enough to store the
configuration values we usually need (right now: ints and strings, other
types can map into these ones like for example the boolean type which is an
int. I also plan to add a new float type soon).
I think what you propose would add too much complexity. And you also have
to remember that plugins can have parameters included in their name (look
at the filter plugins) so you cannot impose a choice to the user as he has
to be able to modify the name to his will.
What I'm considering supporting right now is be to be able to add a range
when defining a int config option.
Becarefull with the "Selected :" text box, it has been put there for the
reason above (plugin names can include parameters) so users can actually
type what they want.
Ok, it's still not perfect yet but nevertheless you did a great job Loïc :)
(PS: I'm also getting used to the tooltips :) but an option to disable them
would still be nice )
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