Thread: [Libvisual-devel] xmms plugin

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

The configure dialog on xmms plugin is almost finished, so please check
the CVS and test it when you have some time, and update translations too.
Bye,
Duilio.

On Sat, 2004-10-02 at 18:34 -0300, Duilio Protti wrote:
> The configure dialog on xmms plugin is almost finished, so please check
> the CVS and test it when you have some time, and update translations too.

It looks VERY good, very nice Duilio!

If we could just get this 'double click on plugin, start' thing 
working... I'll research that for a bit as well..

What are your plans after it's finished ?

Thanks,
Dennis

> What are your plans after it's finished ?
> 
> Thanks,
> Dennis

Well, I want to implement the per-plugin configure dialog, which
will allow set the values for the param entries.

I'll do it generating standard widgets depending on the type
of each entry. I think this would be better than wait VisUI.

I was thinking about VisUI, and I'm convinced now that we must
not implement this module. Developers have whithin libvisual 
framework all what they need to implement his own UI's.

Without VisUI we have less dependency on the target, and
less work will be required on a port. But well, is just my
opinion :-)

Bye,
Duilio.

On Sun, 2004-10-03 at 18:17 -0300, Duilio Javier Protti wrote:
> > What are your plans after it's finished ?
> > 
> > Thanks,
> > Dennis
> 
> Well, I want to implement the per-plugin configure dialog, which
> will allow set the values for the param entries.
> 
> I'll do it generating standard widgets depending on the type
> of each entry. I think this would be better than wait VisUI.
> 
> I was thinking about VisUI, and I'm convinced now that we must
> not implement this module. Developers have whithin libvisual 
> framework all what they need to implement his own UI's.
> 
> Without VisUI we have less dependency on the target, and
> less work will be required on a port. But well, is just my
> opinion :-)

I think that parsing just the VisParamEntries won't provide a nice
user interface experience, especially when it comes to big
lists of VisParamEntries. The VisUI module could give some hints
to the UI builder like, grouping, what kind of input entry, lay
restrictions on the input. VisUI won't be complex, or big, it's just
a few extra hints so a way nicer UI can be build.

My 2cents.

Cheers,
Dennis

> I think that parsing just the VisParamEntries won't provide a nice
> user interface experience, especially when it comes to big
> lists of VisParamEntries. The VisUI module could give some hints
> to the UI builder like, grouping, what kind of input entry, lay
> restrictions on the input. VisUI won't be complex, or big, it's just
> a few extra hints so a way nicer UI can be build.
> 
> My 2cents.
> 
> Cheers,
> Dennis

Oh, I see now what are your plans for VisUI! But, how exactly we can
give that hints. I remember you have mentioned something like libglade
does.

Doing with the thing we have now won't be difficult:
- grouping of params could be done changing to a VisList of
VisParamContainer's on VisPluginData structure.
- lay restrictions on the input could be done adding a pointer to a
'validator' function, which returns TRUE if the given value for the
VisParam a valid one (and probably also return a message string in 
case of error), and will be provided by the plugin writer.

But well, VisUI still being a good idea, I suggest these easy changes
just to concentrate on other things for a while, like VisFont and the
actual libvisual-display.

Bye,
Duilio.

On Tue, 2004-10-05 at 02:50 -0300, Duilio Javier Protti wrote:
> Oh, I see now what are your plans for VisUI! But, how exactly we can
> give that hints. I remember you have mentioned something like libglade
> does.

There will be a VisUIContainer
kinda thing (don't take things to literally
btw, I'm just sketching).

You can pack other VisUIContainers in that
like a VisUIGroup.

(we will keep it very basic)

For example:
___
VisUIContainer *uicont = visual_plugin_get_ui_container (plugin);

VisUIGroup *uigroup = visual_ui_group_new ("Sexy configs");
VisUILabel *uilabel = visual_ui_label_new ("Something: ");
VisUIText *uitext = visual_ui_text_new (paramentry);
VisUIBox *uibox = visual_ui_box_new (VISUAL_UI_HBOX);

visual_ui_box_pack (uibox, uilabel);
visual_ui_box_pack (uibox, uitext);
visual_ui_group_add (uigroup, uibox);

visual_ui_container_add (uicont, uigroup);
___

And have some good API to get extract the userinterface data
so you can easily build it within your app.

I really think it's important to have a facility to describe 
userinterfaces in, atleast to some degree... If people have comments,
thoughts, please comment now, so we can all think about it for a while.

> Doing with the thing we have now won't be difficult:
> - grouping of params could be done changing to a VisList of
> VisParamContainer's on VisPluginData structure.

Won't do that, it's hacky. It's working around the real problem.

> - lay restrictions on the input could be done adding a pointer to a
> 'validator' function, which returns TRUE if the given value for the
> VisParam a valid one (and probably also return a message string in 
> case of error), and will be provided by the plugin writer.

This can be described on UI niveau, where I think this should 
be handled.

> 
> But well, VisUI still being a good idea, I suggest these easy changes
> just to concentrate on other things for a while, like VisFont and the
> actual libvisual-display.

Sorry, I won't change things, to be reverted at a later point. We are
still in development, we don't have to be production ready at this
moment. Rather solve the problems once and right, than solve
them twice. I rather call us stable, both API/ABI when we're done
than when we're not done, but just want people to use us. This is my
opinion. I think that, atleast in the beginning Vitaly will be working
mostly on the libvisual-display stuff. It's in good hands for sure...

I also agree that our ROADMAP has to be revised a bit, I like to give
VisThread a very low piority, but raise the piority of VisFont
and VisAudio rewrite.

The ROADMAP is still a very good overview about, what NEEDS to be done.

Not what needs to be done at which point. It's a nice guide, but it's 
far from final. Till now we have mostly been working on our 'feelings'
and I think it's turning out very well.

I personally, will continue work on the core library, I will
need some help here and there, but generally, I can pull it off :)

I'm getting used to the stress introduced by my new school, so I'm able
to hack more again :) What we really could use is some anthousiastic
plugin porter!, now we have a website, it's time for a new
call for help 'Plugin porters required' :).. hehehe.

Cheers and thanks,
Dennis

> There will be a VisUIContainer
> kinda thing (don't take things to literally
> btw, I'm just sketching).
> 
> You can pack other VisUIContainers in that
> like a VisUIGroup.
> 
> (we will keep it very basic)
> 
> For example:
> ___
> VisUIContainer *uicont = visual_plugin_get_ui_container (plugin);
> 
> VisUIGroup *uigroup = visual_ui_group_new ("Sexy configs");
> VisUILabel *uilabel = visual_ui_label_new ("Something: ");
> VisUIText *uitext = visual_ui_text_new (paramentry);
> VisUIBox *uibox = visual_ui_box_new (VISUAL_UI_HBOX);
> 
> visual_ui_box_pack (uibox, uilabel);
> visual_ui_box_pack (uibox, uitext);
> visual_ui_group_add (uigroup, uibox);
> 
> visual_ui_container_add (uicont, uigroup);
> ___
> 
> 
> And have some good API to get extract the userinterface data
> so you can easily build it within your app.

I see... I was believed that extraction and generation of UI would be
doing it automatically by libvisual, but if this is responsibility of
the developer, I think that VisUI is the right way.
We must work on this next?

Bye,
Duilio.

On Tue, 2004-10-05 at 22:18 -0300, Duilio Javier Protti wrote:
> I see... I was believed that extraction and generation of UI would be
> doing it automatically by libvisual, but if this is responsibility of
> the developer, I think that VisUI is the right way.
> We must work on this next?

VisUI is too much for the next release, So I think it's most important
to fix the small issues, and get the XMMS plugin stable (fix GL
at startup and such)... And also stress test it a bit to see if there
aren't any crashes left anylonger... If you have time, It might also be
nice to use GtkCList and the method xmms uses to check for double 
clicks to morph to plugins. I think that this is quite important because
right now there isn't an intuitive way to start a different plugin.

I'll be doing some more cleanups in libvisual itself and then I want to
do a bugfix release. After that I want to work on the following items:

1. VisUI
2. VisVideo scaler, both NEAREST and BILINEAR methods. (need this for 
   good coverart supprt within amarok.)
3. Portability fixes.
4. All kind of things that comeup within this cycle.

What is your idea about this ?

Cheers,
Dennis

> VisUI is too much for the next release, So I think it's most important
> to fix the small issues, and get the XMMS plugin stable (fix GL
> at startup and such)... And also stress test it a bit to see if there
> aren't any crashes left anylonger... If you have time, It might also be
> nice to use GtkCList and the method xmms uses to check for double 
> clicks to morph to plugins. I think that this is quite important because
> right now there isn't an intuitive way to start a different plugin.

Ok, I will work on this. I have tried to do it without with the current
GtkList, listen on the GDK_BUTTON_PRESS event and using a timer for to
detect the double, and it works well on configure dialog alone, but it
is trashed by SDL when the SDL screen is created (probably SDL sets
again the X event listeners). So I will rewrite this to use GtkCList. I
will be on travel this weekend, I hope can do this before, but not shure
:-(

> I'll be doing some more cleanups in libvisual itself and then I want to
> do a bugfix release. After that I want to work on the following items:
> 
> 1. VisUI
> 2. VisVideo scaler, both NEAREST and BILINEAR methods. (need this for 
>    good coverart supprt within amarok.)
> 3. Portability fixes.
> 4. All kind of things that comeup within this cycle.
> 
> What is your idea about this ?
> 
> Cheers,
> Dennis

I think are all good ideas! I suggest add one more: review all the API
functions looking for pointer arguments that will not be changed, and
change them to 'const'.

Bye,
Duilio.

On Thu, 2004-10-07 at 01:20 -0300, Duilio Javier Protti wrote:
> will be on travel this weekend, I hope can do this before, but not shure
> :-(

Alright, take your time :)

> I think are all good ideas! I suggest add one more: review all the API
> functions looking for pointer arguments that will not be changed, and
> change them to 'const'.

That as well, ofcourse we should keep reviewing anyway, When you spot
something that is really out of place, or should be done different,
just post on the list :)

Cheers,
Dennis

Thread: [Libvisual-devel] xmms plugin

Audio visualisation library

libvisual-devel