[gst-devel] generic gstelement gui
SBaker at CHELLO.com
Mon Mar 4 02:18:06 CET 2002
> 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
> 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.
More information about the gstreamer-devel