[gst-devel] generic gstelement gui

[Baker, Steve]

wingo spoketh:

> yo, i've got a generic gui for gstelements that i use in beatbox. it's
> pretty modular, i can hack it out of there in about an hour or so. i'm
> thinking of adding it to gst-editor cvs in 
> libs/gst/element-ui/, because
> the same code can be used in gst-editor and in gst-launch-gui (both of
> which run right now btw; -editor still sucks though).
> 
> this gui will receive notification signals, so it updates as 
> the plugin
> changes state, etc, and it is (i think) threadsafe (ie, can receive
> notifications from elements that are in other threads).
> 
> right now it has an optionmenu that you choose the prop you 
> want to mess
> with from, but i think in the future it can have three modes of
> operation, i think - compact (one-GtkLabel height), normal (as it is
> now), and full (list all of the properties, like the old 
> (nonfunctional)
> editor code did). the view should be settable by an object property.
> it's in gtk.
> 
> so what i'm wondering is does it sound like a good idea to add this to
> gst-editor cvs. this is really a question for steveb i suppose, as you
> were thinking of this before too.

That sounds great. I say stick it in.

> in the future we really will need to have some sort of property flag
> that indicates that a certain property would be interesting to change,
> from the user's perspective. like all of the ladspa paramters for
> instance are interesting, but only location and offset are interesting
> on a filesrc.

dparams are shaping up for a commit.  One thing I want to add would be a way
to mirror some dparams as element properties for convenience in gst-launch.
If this element property could be flagged not to display, users won't get
confused about which one to use.

cheers