gtk preferences todo list

[Gildas Bazin]

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 
MODULE_CAPABILITY_VOUT_FILTER)

> *   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 :)

--
Gildas

(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>