Re: [Libvisual-devel] VisParamContainer question

[Burkhard P. <pl...@ip...>]

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.

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.

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.

The wrapper code is here:

http://gmerlin.cvs.sourceforge.net/gmerlin/gmerlin/lib/bglv.c?view=markup
http://gmerlin.cvs.sourceforge.net/gmerlin/gmerlin/include/bglv.h?view=markup

The gmerlin-visualizer is also in good shape.

I'll now finish my libvisual port of lemuria. When I'm done, I'll give you some
CVS links, for those who want to try all this.

Burkhard