libvisual-devel — libvisual mailinglist for developers

[Libvisual-devel] widgets configure.ac small update

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

I have changed just a bit the configure.ac, basicly removing some unused
checks.

I could not test the package yet because it doesn't build on my system,
because the use of GtkComboBox, which was introduced on gtk+-2.3 (I'm
using RedHat 9 with gtk+ 2.2.2). I think we must work around this,
because there is so much code out there with gtk+ < 2.4 things.


Bye,
Duilio.

[Libvisual-devel] libvisual-widgets

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

Heya List!

Alright, I've checked in libvisual-widgets, the gtk2 widget
included should work, however I haven't yet tested it.

The gtk2 widgets needs a huge cleanup, which I will do tomorrow,
after that I'll finish up VisUI in libvisual core, and update the
gtk2 widget to that. At that point we can start implementing the gtk1
and QT widget!

I don't want people to commit to this module yet, however if you
have suggestions / ideas, or patches for stupid mistakes or whatever.

Please post on the list, btw it's under module 'libvisual-widgets' (of
course).

This week is dedicated to VisUI and it's widgets for sure, I want to
nail this completely.

The week following I will work on remaining core lib issues, and after
that focus on libvisual-display. When that is ready to go, we can
start rewriting our clients, make them nice and compact, and let them 
use the super simple API provided by both lvwidget and lvdisplay!

Cheers,
Dennis

Re: [Libvisual-devel] VisCPU flags

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

On Tue, 2004-11-09 at 23:25 -0300, Duilio Javier Protti wrote:
> Reading file lv_cpuid.c I see:
> 
> enum {
>         CPU_FLAGS_TSC   = 1 << 4,
>         CPU_FLAGS_MMX   = 1 << 23,
>         CPU_FLAGS_SSE   = 1 << 25,
>         CPU_FLAGS_SSE2  = 1 << 26,
>         CPU_FLAGS_HT    = 1 << 28,
> };
>  
> enum {
>         CPU_FLAGS_EXT_3DNOWEXT  = 1 << 30,
>         CPU_FLAGS_EXT_3DNOW     = 1 << 31
> };
> 
> The problem with this code is that things like 3DNOW extension are
> vendor specific, i.e. on Intel machines bit 30 says if current machine
> is an IA64 or not.

Ai never knew...

> One way to work around this would be to give the second enum a name, say
> VisAMDFlagsExtended or something, and do that for every specific vendor
> supported. The problem with this is that the user of the library must be
> very carefull about seeing the flags accordingly with the current
> machine.
> 
> A better approach would be to not expose the flags directly as returned
> by the cpuid instruction, but instead make our own flags structure,
> where the user can test against it with macros in a safe way.

We don't, we have the VISUAL_CPU macros containing the final result in 
simply TRUE/FALSE.

[Libvisual-devel] VisCPU flags

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

Reading file lv_cpuid.c I see:

enum {
        CPU_FLAGS_TSC   = 1 << 4,
        CPU_FLAGS_MMX   = 1 << 23,
        CPU_FLAGS_SSE   = 1 << 25,
        CPU_FLAGS_SSE2  = 1 << 26,
        CPU_FLAGS_HT    = 1 << 28,
};
 
enum {
        CPU_FLAGS_EXT_3DNOWEXT  = 1 << 30,
        CPU_FLAGS_EXT_3DNOW     = 1 << 31
};

The problem with this code is that things like 3DNOW extension are
vendor specific, i.e. on Intel machines bit 30 says if current machine
is an IA64 or not.

One way to work around this would be to give the second enum a name, say
VisAMDFlagsExtended or something, and do that for every specific vendor
supported. The problem with this is that the user of the library must be
very carefull about seeing the flags accordingly with the current
machine.

A better approach would be to not expose the flags directly as returned
by the cpuid instruction, but instead make our own flags structure,
where the user can test against it with macros in a safe way.


Bye,
Duilio.

[Libvisual-devel] visual_time_usleep ()

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

Heya,

I was wondering if someone with experience regarding creating a decent 
usleep could have an extra look at visual_time_usleep () if it's ok
like this, or if there are more good fallbacks to do an non busy usleep.

Cheers,
Dennis

Re: [Libvisual-devel] [Fwd: Re: [lives-video] LiVES Clips from Piksel]

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

Absolutely awesome!!!!!! I can't wait to see more!!!

Seriously kick ass ;)


On Tue, 2004-11-09 at 14:53 +0000, salsaman wrote:
> Hi all,
> I am back from Piksel. I have an hour or so of demo material using 
> LiVES/libvisual. Can't edit it until laptop is back again.
> Here are some short clips:
> 
> 
> salsaman wrote:
> 
>  > 
> http://www.piksel.no/piksel04/piksel_vidblog/sunday_31/gabriel_showing_lives.avi
>  >
>  > http://www.piksel.no/piksel04/piksel_vidblog/wednesday_03/lives_01.avi
>  > http://www.piksel.no/piksel04/piksel_vidblog/wednesday_03/lives_02.avi
>  > http://www.piksel.no/piksel04/piksel_vidblog/wednesday_03/lives_03.avi
>  > http://www.piksel.no/piksel04/piksel_vidblog/wednesday_03/lives_04.avi
>  >
>  >
>  > Hmmm...no ogg theora though :-/
>  >
>  >
>  > Gabriel.
> 
> One of the clips is wrongly named:
> 
> http://www.piksel.no/piksel04/piksel_vidblog/wednesday_03/lives_03avi.avi
> 
> I have asked the BEK to correct this.
> 
> 
> More soon (I promise).
> 
> 
> Gabriel.
> 
> 
> 
> 
> *Yahoo! Groups Sponsor*
> ADVERTISEMENT
> <http://us.ard.yahoo.com/SIG=129ntaion/M=295196.4901138.6071305.3001176/D=groups/S=1708568770:HM/EXP=1100092969/A=2128215/R=0/SIG=10se96mf6/*http://companion.yahoo.com> 
> 
> 
> 
> ------------------------------------------------------------------------
> *Yahoo! Groups Links*
> 
>     * To visit your group on the web, go to:
>       http://groups.yahoo.com/group/lives-video/
>        
>     * To unsubscribe from this group, send an email to:
>       liv...@ya...
>       <mailto:liv...@ya...?subject=Unsubscribe>
>        
>     * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
> 
> 
> 

[Libvisual-devel] [Fwd: Re: [lives-video] LiVES Clips from Piksel]

[salsaman <sal...@xs...>]

Hi all,
I am back from Piksel. I have an hour or so of demo material using 
LiVES/libvisual. Can't edit it until laptop is back again.
Here are some short clips:


salsaman wrote:

 > 
http://www.piksel.no/piksel04/piksel_vidblog/sunday_31/gabriel_showing_lives.avi
 >
 > http://www.piksel.no/piksel04/piksel_vidblog/wednesday_03/lives_01.avi
 > http://www.piksel.no/piksel04/piksel_vidblog/wednesday_03/lives_02.avi
 > http://www.piksel.no/piksel04/piksel_vidblog/wednesday_03/lives_03.avi
 > http://www.piksel.no/piksel04/piksel_vidblog/wednesday_03/lives_04.avi
 >
 >
 > Hmmm...no ogg theora though :-/
 >
 >
 > Gabriel.

One of the clips is wrongly named:

http://www.piksel.no/piksel04/piksel_vidblog/wednesday_03/lives_03avi.avi

I have asked the BEK to correct this.


More soon (I promise).


Gabriel.




*Yahoo! Groups Sponsor*
ADVERTISEMENT
<http://us.ard.yahoo.com/SIG=129ntaion/M=295196.4901138.6071305.3001176/D=groups/S=1708568770:HM/EXP=1100092969/A=2128215/R=0/SIG=10se96mf6/*http://companion.yahoo.com> 



------------------------------------------------------------------------
*Yahoo! Groups Links*

    * To visit your group on the web, go to:
      http://groups.yahoo.com/group/lives-video/
       
    * To unsubscribe from this group, send an email to:
      liv...@ya...
      <mailto:liv...@ya...?subject=Unsubscribe>
       
    * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
      Service <http://docs.yahoo.com/info/terms/>.



-- 
The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.

-- George Bernard Shaw

[Libvisual-devel] Re: [Libvisual-users] Getting wierd error's

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

On Mon, 2004-11-08 at 17:11 -0800, acidblue wrote:
> On Sat, 2004-11-06 at 03:54, Dennis Smit wrote:
> > On Fri, 2004-11-05 at 23:01 -0800, acidblue wrote:
> > > > Reinstall, yes... However this is weird indeed, can you check if
> > > > you have a beepmp or bmp.pc in either /usr/lib/pkgconfig or
> > > > /usr/local/lib/pkgconfig ?
> > > 
> > > Yes bmp.pc is in /usr/local/lib/pkgconfig
> > > I'm about reinstall libvisual, we'll see
> > > how things go.
> > 
> > Try installing everything with ./configure --prefix=/usr/local this 
> > time, if that isn't working we probably screwed something up
> > in our package, that needs to be fixed ;)
> > 
> > Good luck and keep me updated.
> 
> I'm still getting the same error's when I run xmms "libvisual
> package not found" 
> I don't get any error's with bmp it's just not listed in 
> 'plugins'--'visualization' 

hmms, I have no idea, I'm CCing this to the devel list, maybe someone
has an idea.

All I can advice for now is 'wait to 0.2.0, due in probably something 
like 4 weeks' which really sucks to say ;(((....

I simply have no idea what could be wrong, is it possible to speak
to you on IRC so we can have a bit more 'interactive' debug session ?

Cheers,
Dennis

[Libvisual-devel] CVS needs complete rebuild.

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

Yeah, It's that time of the week again.

Just want to notify that you've got to rebuild everything LV related
because structs have been changed a bit (again) :)

Ooh and we started on VisCPU and visual_video_scaler!

Both thanks to Chong Kai Xiong!

Cheers,
Dennis

Re: [Libvisual-devel] NetBSD packages for libvisual available; patches

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

On Mon, 2004-11-08 at 15:33 +0100, Thomas Klausner wrote:
> Perhaps I wasn't clear enough on this -- it's not an actual
> problem, everything works even if the test is unchanged.

Hmms, alright, would be nice to have it going smooth tho :)

> Actually, that's very easy to fix, see attached diff. It's just
> a message :)

Aah doh, thanks for the patch! :)

> In the meantime I also made a package libvisual-gforce, which has
> only one problem: the check in unix/Headers/trunc.h doesn't work
> for me, since NetBSD does not have trunc(), but all of the tests
> are in #ifdef HAVE_CONFIG_H, and the configure script does not
> generate a config.h, but adds -Ds to the command line instead.
> 
> Also, the configure script doesn't even seem to check for trunc().

Hmms, same story, I suck with all these tools, do you think you can
brew up a patch for this ?

Another thing we could do is just always use:

#define trunc(x) (((x) > 0.0) ? floor(x) : ceil(x))

But that might has a speed penalty...

> If the trunc()-arguments are positive, one could use floor() instead,
> which is in C89 and thus probably more portable. (trunc() is new
> in C99.)

Never knew, ported this over quite roughly ;)

> libvisual-nebulus packaged without any problems.

Yay! :)

Cheers,
Dennis

Re: [Libvisual-devel] NetBSD packages for libvisual available; patches

[Thomas K. <tho...@us...>]

On Sat, Nov 06, 2004 at 07:35:48PM +0100, Dennis Smit wrote:
> > Also, the configure script complains about libdl missing;
> > however, on NetBSD (and the other BSDs too, I think) libdl
> > is not needed, the dl* functions are in libc itself. At
> > least it doesn't stop here :)
> 
> Hmms, I'm not too sure about this one, Duilio do you have more
> experience with this ?

Perhaps I wasn't clear enough on this -- it's not an actual
problem, everything works even if the test is unchanged.

> > And libvisual-plugins is lying to me -- the configure script
> > says:
> > install path                          : /usr/pkg/libvisual
> > while in reality, the plugins go into /usr/pkg/lib/libvisual.
> 
> Ai, my experience with auto* is very bad, Do you know a possible 
> solution for this ?

Actually, that's very easy to fix, see attached diff. It's just
a message :)

> I think we can nail most of it for atleast the next release by
> ourself, but nonetheless thank you! :)

Ok, I'm looking forward to it. :)

In the meantime I also made a package libvisual-gforce, which has
only one problem: the check in unix/Headers/trunc.h doesn't work
for me, since NetBSD does not have trunc(), but all of the tests
are in #ifdef HAVE_CONFIG_H, and the configure script does not
generate a config.h, but adds -Ds to the command line instead.

Also, the configure script doesn't even seem to check for trunc().

If the trunc()-arguments are positive, one could use floor() instead,
which is in C89 and thus probably more portable. (trunc() is new
in C99.)

libvisual-nebulus packaged without any problems.

Cheers,
 Thomas

Re: [Libvisual-devel] NetBSD packages for libvisual available; patches

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

On Fri, 2004-11-05 at 22:42 +0100, Thomas Klausner wrote:
> Hi!
> 
> I just made NetBSD packages for libvisual (0.1.7), libvisual-plugins
> (0.1.7), and libvisual-bmp (0.1.0). (pkgsrc/audio/libvisual*)

Thank you a lot!! :)

> I needed two patches for libvisual that should be integrated in
> the main tree in some form.

Both commited!, again, thanks a lot, I personally don't have much
experience with different systems than linux, so this is really
appreciated.

> Also, the configure script complains about libdl missing;
> however, on NetBSD (and the other BSDs too, I think) libdl
> is not needed, the dl* functions are in libc itself. At
> least it doesn't stop here :)

Hmms, I'm not too sure about this one, Duilio do you have more
experience with this ?

> And libvisual-plugins is lying to me -- the configure script
> says:
> install path                          : /usr/pkg/libvisual
> while in reality, the plugins go into /usr/pkg/lib/libvisual.

Ai, my experience with auto* is very bad, Do you know a possible 
solution for this ?

> I also tried using the plugins with bmp, and I get lots of:
> 	libvisual CRITICAL: XMMS plugin: visual_mem_free(): assertion `ptr != NULL' failed
> lines. Other errors I see (not so often):

This is known, and mostly fixed in CVS! :)

> On startup, right after "Last plugin: infinite":
> libvisual CRITICAL: XMMS plugin: visual_plugin_load(): assertion `ref != NULL' failed

Hmms, I've got to look into this...

> Right before "negotiating plugin libvisual DNA helix animation"
> and "negotiating plugin libvisual madspin port":
> libvisual CRITICAL: XMMS plugin: visual_video_free_buffer(): assertion `video->screenbuffer != NULL' failed

Yep known, this comes from the VisBin eventually, which is pure
suckage, 
I've simply done VisBin wrong, design and impl wise, and we're going
to redo it completely from scratch after all the stuff it will depend
on is implemented.

> Sometimes when switching:
> libvisual WARNING: XMMS plugin: visual_video_free_with_buffer(): VisVideo structure doesn't have an allocated screen buffer, visual_video_free() must be used
> libvisual WARNING: XMMS plugin: visual_video_free_with_buffer(): VisVideo structure doesn't have an allocated screen buffer, visual_video_free() must be used

Again, VisBin is broken :) will be fixed.

> Also, sometimes when disabling the plugin in bmp:
> libvisual CRITICAL: XMMS plugin: visual_actor_destroy(): assertion `actor != NULL' failed
> libvisual CRITICAL: XMMS plugin: visual_video_free_with_buffer(): assertion `video != NULL' failed

I've seen this, I will look into that as well.

> Tell me how I can help debugging them.

I think we can nail most of it for atleast the next release by
ourself, but nonetheless thank you! :)

> Cheers,
>  Thomas


Cheers and thanks a lot, it's really appreciated!

Dennis

[Libvisual-devel] NetBSD packages for libvisual available; patches

[Thomas K. <tho...@us...>]

Hi!

I just made NetBSD packages for libvisual (0.1.7), libvisual-plugins
(0.1.7), and libvisual-bmp (0.1.0). (pkgsrc/audio/libvisual*)

I needed two patches for libvisual that should be integrated in
the main tree in some form.

The first (patch-aa) deals with lv_common.h defining uint8_t
and friends, not caring if they are already defined.

The second (patch-ab) addresses lv_mem.h's use of
__attribute_malloc__ which seems to be a glibc'ism.
Of course, you could also hide it in more appropriate
ifdefs (something like __GLIBC__?).

Also, the configure script complains about libdl missing;
however, on NetBSD (and the other BSDs too, I think) libdl
is not needed, the dl* functions are in libc itself. At
least it doesn't stop here :)

libvisual-bmp has the following problem: it comes with the two
pixmaps libvisual-xmms-vis.bmp and libvisual-xmms-vis.xpm,
but looks for libvisual-bmp-vis.bmp during runtime. The files
should be renamed (and pixmaps/Makefile.am adapted).

And libvisual-plugins is lying to me -- the configure script
says:
install path                          : /usr/pkg/libvisual
while in reality, the plugins go into /usr/pkg/lib/libvisual.


I also tried using the plugins with bmp, and I get lots of:
	libvisual CRITICAL: XMMS plugin: visual_mem_free(): assertion `ptr != NULL' failed
lines. Other errors I see (not so often):

On startup, right after "Last plugin: infinite":
libvisual CRITICAL: XMMS plugin: visual_plugin_load(): assertion `ref != NULL' failed

Right before "negotiating plugin libvisual DNA helix animation"
and "negotiating plugin libvisual madspin port":
libvisual CRITICAL: XMMS plugin: visual_video_free_buffer(): assertion `video->screenbuffer != NULL' failed

Sometimes when switching:
libvisual WARNING: XMMS plugin: visual_video_free_with_buffer(): VisVideo structure doesn't have an allocated screen buffer, visual_video_free() must be used
libvisual WARNING: XMMS plugin: visual_video_free_with_buffer(): VisVideo structure doesn't have an allocated screen buffer, visual_video_free() must be used

Also, sometimes when disabling the plugin in bmp:
libvisual CRITICAL: XMMS plugin: visual_actor_destroy(): assertion `actor != NULL' failed
libvisual CRITICAL: XMMS plugin: visual_video_free_with_buffer(): assertion `video != NULL' failed

Tell me how I can help debugging them.

Cheers,
 Thomas

P.S.: Please CC me, I'm not on this mailing list.

[Libvisual-devel] CVS update,

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

When you compile from CVS, you'll need to make clean, remake, etc etc
every module that depends on libvisual, yeah structures changed a bit :)

Cheers,
Dennis

Re: [Libvisual-devel] libvisual-widget

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

On Thu, 2004-11-04 at 01:10 -0300, Duilio Javier Protti wrote:
> > Have you by any chance been able to look at the bilinair and nearest
> > scale functions ? :)
> > 
> > Cheers,
> > Dennis
> 
> Ok, I will try to do that before this weekend.

Ok sounds excelent!

Re: [Libvisual-devel] libvisual-widget

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

> Have you by any chance been able to look at the bilinair and nearest
> scale functions ? :)
> 
> Cheers,
> Dennis

Ok, I will try to do that before this weekend.


Bye,
Duilio.

Re: [Libvisual-devel] libvisual-widget

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

On Wed, 2004-11-03 at 13:39 -0300, Duilio Javier Protti wrote:
> > Regarding libvisual-widget:
> > 
> > I'd like to make one package containing widgets like VisUI widget, for
> > gtk2,gtk1 and QT (and later on a VisVideo in buffer fallback).
> > 
> > I don't have experience with linking multiple libraries, from 
> > multiple archives. Basicly after compilation, the first release should
> > come up with (optionally) 3 .so files, being gtk1 widget lib, gtk 2 
> > widget lib and the QT widget lib.
> > 
> > Anyone experience with such a (or likewise) setup who can help us a bit
> > regarding this ?
> 
> This is easy to do with autotools, basicly you must generate 3 different
> target instead of just one. I can do it if you want, but... where are
> the libvisual-widget? I mean, what the cvs module name is?

Aah, alright!, it's not yet in CVS :), or rather, the whole package 
hasn't been created yet, I'll do that when the gtk2 VisUI widget is
finished (it's nearly finished).

Have you by any chance been able to look at the bilinair and nearest
scale functions ? :)

Cheers,
Dennis

Re: [Libvisual-devel] libvisual-widget

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

> Regarding libvisual-widget:
> 
> I'd like to make one package containing widgets like VisUI widget, for
> gtk2,gtk1 and QT (and later on a VisVideo in buffer fallback).
> 
> I don't have experience with linking multiple libraries, from 
> multiple archives. Basicly after compilation, the first release should
> come up with (optionally) 3 .so files, being gtk1 widget lib, gtk 2 
> widget lib and the QT widget lib.
> 
> Anyone experience with such a (or likewise) setup who can help us a bit
> regarding this ?

This is easy to do with autotools, basicly you must generate 3 different
target instead of just one. I can do it if you want, but... where are
the libvisual-widget? I mean, what the cvs module name is?


Bye,
Duilio.

[Libvisual-devel] libvisual-widget

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

Heya list,

It has been kinda silence here lately!, but that doesn't mean
we haven't been doing anything.

Well, Deadchip, from BMP and I are still working on the gtk2 stuff, he
plans to fix my crap up a bit :)..

I'll be working on the error reporting, hopefully finishing that before 
the end of this week, and after that I'll be taking a look at
the plugin package :)

Regarding libvisual-widget:

I'd like to make one package containing widgets like VisUI widget, for
gtk2,gtk1 and QT (and later on a VisVideo in buffer fallback).

I don't have experience with linking multiple libraries, from 
multiple archives. Basicly after compilation, the first release should
come up with (optionally) 3 .so files, being gtk1 widget lib, gtk 2 
widget lib and the QT widget lib.

Anyone experience with such a (or likewise) setup who can help us a bit
regarding this ?

For the next release I also consider creating a master package, basicly
containing everything, and some good script that compiles all
the packages, in the right order, this for the ease of the user...
Not sure if it's a good idea so please comment on this as well :)

Cheers,
Dennis

Re: [Libvisual-devel] Visual Noatun 0.1 released

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

On Sun, 2004-10-24 at 17:04 +0200, mETz wrote:
> Moin,
> 
> Yesterday I finally released a first preview of Visual Noatun, a plugin for 
> Noatun (KDE media player) using libvisual. I based it on xmms-libvisual code 
> which was quite helpful with only parts of libvisual being documented so 
> far :)

Wow, we're sure happy with that!! :)

> Planned (or already working on) features:
> - configurable resolution for windowed mode
> - ability to turn off window resizing
> - different or same resolution for fullscreen mode as for windowed mode
> - start in fullscreen mode
> - random mode, i.e. switch to another actor and/or morph every x seconds

I'd like to point out that, when we release libvisual-display together
with the upcoming release, displaying will be very easy, and the
display type features you describe here, will (maybe not directly)
but eventually all be included in libvisual-display, keep that in 
mind :)

Regarding the random plugin, it's a good idea, We wanted to implement
such thing in the bin, or rather an extension to the bin, called
'AutoSched' I will work on that together with the new VisBin!

Also when we start on the new VisBin system, I will also documentate 
it :)

> Software needed:
> - KDE 3.2 or better
> - Noatun (part of kdemultimedia)
> - SDL 1.2.0 or better
> - libvisual 0.1.7
> 
> Sources are available at:
> http://metz.gehn.net/files/visualnoatun-0.1.tar.bz2
> 
> I'm already looking forward to see libvisual-0.2 (and maybe a semi-documented 
> VisualBin even if it's going to vanish soon).

Regarding the Bin, I'm not going to documentate the current code, if
you have questions, go ahead and ask those, I will gladly answer :)

When the bin is rewritten I'll make sure it's well API documentated.

I hope to do this either for 0.2.1, or 0.2.2, atleast we'll try asap :)

Thanks a lot and keep us updated!!

Dennis

[Libvisual-devel] Visual Noatun 0.1 released

[mETz <mE...@we...>]

Moin,

Yesterday I finally released a first preview of Visual Noatun, a plugin for 
Noatun (KDE media player) using libvisual. I based it on xmms-libvisual code 
which was quite helpful with only parts of libvisual being documented so 
far :)

Features already implemented:
- switch actor (using keypad + - or through config ui) 
- switch morph (through config ui)
- limit maximum fps (using page up/down or through config ui)
- runs in a process of its own so it cannot crash Noatun itself

Planned (or already working on) features:
- configurable resolution for windowed mode
- ability to turn off window resizing
- different or same resolution for fullscreen mode as for windowed mode
- start in fullscreen mode
- random mode, i.e. switch to another actor and/or morph every x seconds

Software needed:
- KDE 3.2 or better
- Noatun (part of kdemultimedia)
- SDL 1.2.0 or better
- libvisual 0.1.7

Sources are available at:
http://metz.gehn.net/files/visualnoatun-0.1.tar.bz2

I'm already looking forward to see libvisual-0.2 (and maybe a semi-documented 
VisualBin even if it's going to vanish soon).

Bye, Stefan aka mETz

[Libvisual-devel] VisParam serialisation.

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

Heya,

This isn't planned for next release but after 0.2.0
I want to get VisParam serialisation (aka config save)
working.

Maybe someone feels like thinking up a file format that contains
configuration, do we want separated files for every domain, or one
big registry, how do we want to structure the file, etc etc...

Of course I don't want to depend on things like libxml :)

Just give it a thought :)

I'm going to play some games, I'm majorly fed up with some of mine code
hehehe!

Cheers,
Dennis

[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] VisUI succes!

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

On Thu, 2004-10-21 at 22:15 -0300, Gustavo Sverzut Barbieri wrote:
> On Thursday 21 October 2004 18:25, Dennis Smit wrote:
> > Heya, well, I like to keep you guys updated, so here we go:
> >
> > http://www.plasser.nl/synap/libvisual/visui_gtk_demo5.png
> >
> > Code:
> >         actor = visual_actor_new ("madspin");
> >         visual_actor_realize (actor);
> >         main = visual_plugin_get_userinterface (visual_actor_get_plugin
> > (actor));
> >
> >         vuic = lvwidget_uicontainer_new (main);
> >
> >         gtk_container_add (GTK_CONTAINER (window), vuic);
> >
> >
> > We're getting there for sure !
> 
> Sure!
> 
> I hope you're willing to implement support for help on items, with tooltips 
> and things like that. The example you give is self explanatory, but other 
> options are so obscure to users that might need even multimedia 
> explanations... maybe html support for these?

I don't want to crack this up, let's see how this works for now, if
more is needed, we can implement more. an option to set tooltips isn't
a bad idea tho. Also, settings do apply directly, so figgling with an
option quickly explains it's purpose.

Cheers,
Dennis

Re: [Libvisual-devel] screenbuffer->pixels

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

On Thu, 2004-10-21 at 22:11 -0300, Gustavo Sverzut Barbieri wrote:
> On Thursday 21 October 2004 14:25, Dennis Smit wrote:
> > Heya,
> >
> > What do you guys favor:
> >
> > visual_video_set_buffer or visual_video_set_pixels ... ?
> 
> visual_video_set_buffer()
> 
> but I like video->pixels more... so take which one you like :/ 


I changed everything to video->pixels, and kept the video_set_buffer().