libvisual-devel

[Libvisual-devel] libvisual-display updates, and some extras

[Dennis S. <sy...@yo...>]

Vitaly has been completely rocking on libvisual-display!

The glx plugin works, both with framebuffer and GL, everyone
who is interested check out libvisual-display, lot's to come
in this department. I want to convert our current clients to
libvisual-display ASAP, we won't get it working before the 0.1.7
release so I plan it for the 0.2.0 release.


On the list for 0.2.0:
* Good error reporting.
* VisUI.
* Gtk1 and Gtk2 VisUI builder.
* Good Beep Media Player client (this is important, they don't have
  many visuals ported to their player yet, and we will instantly bring
  most of the xmms collection and extras, so we can be a big player    
  here).
* API reviews.
* Portability fixes.
* VisVideo it's scaler.
* Libvisual-display support in clients.
* All kind of things that come up.

When the error reporting stuff is in place, Gustavo
will be working on the python bindings, which will
enable the freevo (http://freevo.sf.net) project to
use libvisual.

This is our plan of universal domination, anyone comments ?

Cheers,
Dennis

Re: [Libvisual-devel] libvisual-display updates, and some extras

[Duilio J. P. <dp...@fc...>]

> On the list for 0.2.0:
> * Good error reporting.
> * VisUI.

Good for both!

> * Gtk1 and Gtk2 VisUI builder.

This surprise me. I was believed that final UI building would be 
responsibility of the programmer.

> * Good Beep Media Player client (this is important, they don't have
>   many visuals ported to their player yet, and we will instantly bring
>   most of the xmms collection and extras, so we can be a big player    
>   here).

I'm agree this is important.

> * API reviews.
> * Portability fixes.
> * VisVideo it's scaler.
> * Libvisual-display support in clients.
> * All kind of things that come up.
> 
> When the error reporting stuff is in place, Gustavo
> will be working on the python bindings, which will
> enable the freevo (http://freevo.sf.net) project to
> use libvisual.
> 
> This is our plan of universal domination, anyone comments ?
> 
> Cheers,
> Dennis

Just one more comment. I think would be better to keep release on 0.1.8.
Why? just because of the future libtool versioning system. Remember that
when we switch to the libtool system, we must start from 0.0.0. The
question is, what we will do with the current 0.1.x series? I was
thinking on just skip this series and jump to 0.2.x series (0.1.x would
became like a devel series, which exactly was it is). This way there
would be no confusse with people using old packages.

Other possibility would be to introduce libtool versioning right now,
but I think is not the moment yet. Remember the current:revision:age
scheme of libtool (which is reflected on the package number). 'current'
must be incremented every time you change an actual API function, and
that will happen for a while on libvisual, so we will have
libvisual-10.0.4 really soon :-)


Bye,
Duilio.

Re: [Libvisual-devel] libvisual-display updates, and some extras

[Dennis S. <sy...@yo...>]

On Fri, 2004-10-15 at 00:49 -0300, Duilio Javier Protti wrote:
> > On the list for 0.2.0:
> > * Good error reporting.
> > * VisUI.
> 
> Good for both!
> 
> > * Gtk1 and Gtk2 VisUI builder.
> 
> This surprise me. I was believed that final UI building would be 
> responsibility of the programmer.

It is, but since we have to write these widgets anyway, in gtk1 for
xmms and in gtk2 for bmp, I don't think it hurts to generalise them
in a separated libvisual-widgets package, so everyone can use them
easily. Aka that way we make the code reusable.

> > * API reviews.
> > * Portability fixes.
> > * VisVideo it's scaler.
> > * Libvisual-display support in clients.
> > * All kind of things that come up.
> > 
> > When the error reporting stuff is in place, Gustavo
> > will be working on the python bindings, which will
> > enable the freevo (http://freevo.sf.net) project to
> > use libvisual.
> > 
> > This is our plan of universal domination, anyone comments ?
> > 
> > Cheers,
> > Dennis
> 
> Just one more comment. I think would be better to keep release on 0.1.8.
> Why? just because of the future libtool versioning system. Remember that
> when we switch to the libtool system, we must start from 0.0.0. The
> question is, what we will do with the current 0.1.x series? I was
> thinking on just skip this series and jump to 0.2.x series (0.1.x would
> became like a devel series, which exactly was it is). This way there
> would be no confusse with people using old packages.

Maybe it's better to use #defines for setting version anyway, so we have
more control regarding that, I'd like to do a 0.2.0 to sign it's 
significancy, and because it will be major API incompatible.

> Other possibility would be to introduce libtool versioning right now,
> but I think is not the moment yet. Remember the current:revision:age
> scheme of libtool (which is reflected on the package number). 'current'
> must be incremented every time you change an actual API function, and
> that will happen for a while on libvisual, so we will have
> libvisual-10.0.4 really soon :-)

Maybe we should use a different versioning scheme after all... not sure

[Libvisual-devel] about versioning system

[Duilio J. P. <dp...@fc...>]

Dennis wrote on another thread:
> Maybe it's better to use #defines for setting version anyway, so we have
> more control regarding that, I'd like to do a 0.2.0 to sign it's 
> significancy, and because it will be major API incompatible.
> 
> > Other possibility would be to introduce libtool versioning right now,
> > but I think is not the moment yet. Remember the current:revision:age
> > scheme of libtool (which is reflected on the package number). 'current'
> > must be incremented every time you change an actual API function, and
> > that will happen for a while on libvisual, so we will have
> > libvisual-10.0.4 really soon :-)
> 
> Maybe we should use a different versioning scheme after all... not sure

Of course versioning system could be controlled during configure time, 
through pkg-config. In fact there are so many things in common between
libtool and pkg-config objectives, that libtool project's people are
thinking about 'merge' the two projects someway.
Anyway, we can control versions entirely through pkg-config, we just
must very strict about this on any new release (specially when some day
became projects using libvisual outside our own).


Bye,
Duilio.

Re: [Libvisual-devel] libvisual-display updates, and some extras

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

>>>* Gtk1 and Gtk2 VisUI builder.
>>
>>This surprise me. I was believed that final UI building would be 
>>responsibility of the programmer.
> 
> It is, but since we have to write these widgets anyway, in gtk1 for
> xmms and in gtk2 for bmp, I don't think it hurts to generalise them
> in a separated libvisual-widgets package, so everyone can use them
> easily. Aka that way we make the code reusable.

And users always have the same configuration dialogs,
no matter what application they use.

>>>This is our plan of universal domination, anyone comments ?

Maybe QT widgets? I personally hate KDE/Qt but many people don't.

-- 
_____________________________
Dr.-Ing. Burkhard Plaum
Institut fuer Plasmaforschung
Pfaffenwaldring 31
70569 Stuttgart
Tel.: +49 711 685-2187
Fax.:            -3102

Re: [Libvisual-devel] libvisual-display updates, and some extras

[Dennis S. <sy...@yo...>]

On Fri, 2004-10-15 at 15:35 +0200, Burkhard Plaum wrote:
> >>>* Gtk1 and Gtk2 VisUI builder.
> >>
> >>This surprise me. I was believed that final UI building would be 
> >>responsibility of the programmer.
> > 
> > It is, but since we have to write these widgets anyway, in gtk1 for
> > xmms and in gtk2 for bmp, I don't think it hurts to generalise them
> > in a separated libvisual-widgets package, so everyone can use them
> > easily. Aka that way we make the code reusable.
> 
> And users always have the same configuration dialogs,
> no matter what application they use.

Yeah, this is especially important, probably even more
important than ease of development, consistention.

> >>>This is our plan of universal domination, anyone comments ?
> 
> Maybe QT widgets? I personally hate KDE/Qt but many people don't.

I'm not a KDE user, but I don't hate it, everyone has their freedom
of choice, and I'd like to see us everywhere, we're 'neutral' so to
say. I think amarok would really like to have a QT config widget for
libvisual, tho they should look into that themself :), because I'm
just completely QT clueless.. heheh!

Cheers,
Dennis