[LONG] gtk preferences todo list

[Gildas Bazin]

On Wed, 27 Mar 2002 Loïc Minier Wrote:
>
> 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.
>

Ok, It maybe worth investigating the use of a combo-box.
But you're still missing the point here . This won't solve the real problem.
The problem is that the interface is _dynamically_ generated from all the config options registered by the plugins. That basically means that you've got no way to know in advance what the interface will look like, you've got no way to know which size it will have, etc...
This is the whole point of imposing a maximum size for this interface, and adding scrollbars if necessary.


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

Well, if it's what it takes to have some more control over what we want to display, then I think it's fine :)


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

I'm still not sure I understand the whole thing, but anyway I think it's at least worth investigating.

> I think this means no feature loss and the gtk interface also
>do things the command line can't (saving the configuration for example
>:)
>

Hey, nice idea, I need to implement this --save command line option :p

>
> 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 think you're right, the second part is just another option after all, so I suggest we get rid of this command line way of specifying an option for a plugin and use standard configuration options.
The deinterlace plugin will then just have a "deinterlace_method" option which will accept a string as a parameter.
This will certainly make things simpler.

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

Ok, I will investigate the feasibility of an enumerated type. Maybe as you suggest the best way will be to make this just a HINT for the interface plugin that will display the preferences dialog.

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

I found out what I actually dislike with the current tooltips implementation.
Usually tooltips should be triggered only when you place the mouse cursor over a specific area. But in our case, wherever you move the mouse, tooltips are always displayed. This is really annoying. You should think about restricting the hotspot to a narrower and more specific region, like for example just the label of the config option.

Cheers,

--
Gildas

-------------------------------------------------------------
NetCourrier, votre bureau virtuel sur Internet : Mail, Agenda, Clubs, Toolbar...
Web/Wap : www.netcourrier.com
Téléphone/Fax : 08 92 69 00 21 (0,34 € TTC/min)
Minitel: 3615 NETCOURRIER (0,15 € TTC/min)


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