[LONG] gtk preferences todo list

[Loïc Minier]

On Tue, Mar 26, 2002, Gildas Bazin wrote:
> 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...

 Currently, the interface is huge because of the number of lines of the
clist and the fact that they are sometimes two clists. These things can
both be corrected by splitting the module types in "filter" and "*out".
 I perfectly agree that the number of plugins will still be a problem
longterm-speaking. And that's why I offer the second solution of the
combo-box.

 I simply think it would be overloading the interface too much to try to
configure everything in the same tab.

> I've been looking at the web site you told me about 
> (www.iarchitect.com/tabs.htm)

 (Courtesy of sam.)

> these scrollbars will only be shown if they are needed.

 That is not always true. Especially if you create every window with
a scrollbar, you end up by getting a too small window for the main
configuration or a too big one for plugin specific configs if you set
the default size by yourself.

 So we would have to check before displaying it if the window is "quite
empty" and we do not have to set the default size or "quite loaded" and
set the default size accordingly. I thinks that's *ugly*.

> (right now I don't really see how you want to do this. Maybe you could
> develop this a little bit more ?)

 The idea of the combo box was originally mine to replace the clist
because I wanted to reflect a "one choice only" option. This was a
mistake because all plugins were not easily configurable and the list
was not clearly displayed. I understand this was wrong.

 The actual idea (courtesy of fenrir and sam) is to have following :
 ____ ____,----._______ _______
|intf|aout|VOUT|vfilter|decoder|
,---------'    `---------------.
|  ________ _     _________    |
| | xvideo |V|   |configure|   |
|  -------- -     ---------    |
| . . . . . . . . . . . . . .  |
|           _________          |
| DISPLAY: |         |         |
|           ---------          |

 (I hope you can read the preceding drawing.)

 So basically it would be my first idea but the configure button would
always be available and would open a window with a clist of all plugins.
Each plugin would be configurable and the one highlighted there would
reflect the value of the combo box.

 Yes this suppress the possibility to enter a bad value _in the gtk
interface_, where you could be nastier thru the command line for
example. I think this means no feature loss and the gtk interface also
do things the command line can't (saving the configuration for example
:)

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

 Yes I agree it's enough right now, it would just be better to have some
better types. As soon as we have that option and your float type, it's
enough. I see that tools as the mathematics needed to define lists,
arrays, or the type of a value.
 In the same way, the "PATH" and the "STRING" types coexist but they are
used in the same manner right now, in a text box. You see we could have
a file browsing window for the PATH option and just a text box for a
string.

 So I see this descriptions at intf guidelines as well as a storage
definition and I think that it would be cool to have these types
longterm.

 The best argument I could give for that is exactly what solves your
filter-name problem. If I get it correctly, when we use the deinterlace
filter, we type "deinterlace:bob". I don't see this as a string but
either as the command-line way of specifying a string parameter to a
plugin. So let's call the second part filter-method, and make an option
out of it ! I would define that option as a string with the value of either "bob" or "weave". That's why I suggested that new « enumerated » type.

> (PS: I'm also getting used to the tooltips :) but an option to disable them 
> would still be nice )

 Okay, I'll try to do that for you   ;^)

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