Re: [Libvisual-devel] VisParamContainer question

[Dennis S. <den...@gm...>]

On Nov 6, 2007 3:07 PM, Burkhard Plaum <pl...@ip...> wrote:

> Hi,
>
> Dennis Smit schrieb:
>
> > You are completely right!!! my mistake.
> >
> > the example I posted was using macros for:
> >
> > VisCollectionIterator iter;
> > visual_collection_get_iterator (&iter, collection);
> > while (visual_collection_iterator_has_more (&iter)) {
> >  VisHashmapChainEntry *entry = visual_collection_iterator_get_data
> (&iter);
> >  visual_collection_iterator_next (&iter);
> >  }
> >  visual_object_unref (VISUAL_OBJECT (&iter));
> > }
> >
>
> That didn't work either, but I succeeded with
>
> VisParamContainer * params;
> int num_parameters;
> VisListEntry * list_entry;
> VisParamEntry *param_entry;
>
> list_entry = (VisListEntry*)0;
>
> params = visual_plugin_get_params(visual_actor_get_plugin(actor));
> while(visual_list_next(&params->entries, &list_entry))
>   num_parameters++;
>
> /* ... */
>
> list_entry = (VisListEntry*)0;
>
> for(i = 0; i < num_parameters; i++)
>    {
>    visual_list_next(&params->entries, &list_entry);
>    param_entry = list_entry->data;
>
>    /* ... */
>    }
>
> Also I parse the VisUIWidget to get more informations, like limits for
> numeric parameters.
>
> One thing could be improved I think: Currently the VisUIWidget adds labels
> in addition to the mutators. This makes it difficult to get the label text
> corresponding to a mutator without parsing the whole layout of the dialog
> (or implemeting a VisUI backend, which is impossible in gmerlin).
> If label was a member of VisParamEntry, things would become much simpler.


The VisParamEntry its name might be describing enough in most cases tho
(which should be seen as a label).


>
>
> In fact, gmerlins native parameter definitions are like a mixture of
> VisParamEntry and VisUIWidget. The advantage is, that you have all
> informations
> (label, tooltips, ranges, default values etc.) in one statically defined
> struct.
> The disadvantage is that plugin programmers have no control over the
> actual layout
> of the dialog, except the order.
>

I like to have the UI control, but I agree that limits should move to
VisParam. I did some of that work on the 060 branch, but that died since I
ran out of time a year ago ;(.


>
> Now the good news: My libvisual wrapper works perfectly now with the
> following features:
>
> - All parameter types (using VisParamEntry and VisUIWidget) except
>   VISUAL_PARAM_ENTRY_TYPE_PALETTE and VISUAL_PARAM_ENTRY_TYPE_OBJECT
> - Mouse, Keyboard and resize events
> - Full OpenGL support
> - Non-OpenGL plugins render using gmerlins native methods (this means
>   in most cases XVideo or OpenGL hardware scaling). A pretty decent
> software
>   scaler is used, if neither OpenGL nor XVideo are present.
> - Embeddable into foreign windows using the XEMBED protocol
> - Visualizations are run in a slave process, so plugins can link to
>   arbitrarily broken libraries, leak memory and crash as much as they want
> :)
>   Communication with the slave process is done via a bidirectional pipe.
> - Tested with all plugins from libvisual-plugins-0.4.0 (except Gdkpixbuf)
> as
>   well as ProjectM. No crash observed until now.
> - Uses gmerlins method of scanning plugin directories and checking only
> the
>   modules, which have a changed file timestamp (to save startup time).
>   The actual dlopen()ing is done by libvisual.
>

That is really really neat!

Cheers,
Dennis