Menu
▾
▴
libvisual-devel — libvisual mailinglist for developers
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
(38) |
May
(22) |
Jun
(92) |
Jul
(101) |
Aug
(18) |
Sep
(286) |
Oct
(180) |
Nov
(73) |
Dec
(14) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(18) |
Feb
(74) |
Mar
(56) |
Apr
(11) |
May
(5) |
Jun
(4) |
Jul
(20) |
Aug
(4) |
Sep
|
Oct
|
Nov
(1) |
Dec
(2) |
| 2006 |
Jan
(11) |
Feb
(2) |
Mar
(10) |
Apr
(2) |
May
(1) |
Jun
|
Jul
(24) |
Aug
(11) |
Sep
(5) |
Oct
(16) |
Nov
(25) |
Dec
(8) |
| 2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(1) |
Aug
|
Sep
|
Oct
(4) |
Nov
(12) |
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
|
From: <jo...@so...> - 2005-03-19 17:26:54
|
On Tue, 15 Mar 2005 16:01:14 +0100, Dennis Smit <sy...@yo...> wrote: > I don't have experience with docbook :) Ah ... ok, I'll see if I can't convert it if I get the time. > How is your project going ? It's coming along. It will use Libvisual for visualisation and it can display both types of visualisations in the background. To get the OpenGL plug-ins to work I have to render it to a GLX pbuffer (pixel-buffer.) Bit of a struggle to get it working correctly, but it works allright now (except on older ATI cards, such as my laptop's :( Best, Jon Øyvind Kjellman |
|
From: Dennis S. <sy...@yo...> - 2005-03-16 22:09:38
|
2005-03-16 Dennis Smit <ds...@ne...>
* configure.ac: Adding detection for gthread, fixing spelling
mistakes.
* libvisual.pc.in: Add package dep.
* libvisual/Makefile.am: Add thread libs/cflags.
Patch by Duilio, thanks!
On Tue, 2005-03-15 at 21:37 -0300, Duilio Javier Protti wrote:
> Ok, here is the patch, plus small correction within libvisual.pc.in.
>
> About Gthread, are you sure that this is what you want? I mean, gthread
> is by itself an abstraction library around the native thread
> implementation, so in general there will be always one of such
> implementations present, so probably we will never use gthread.
>
>
> Bye,
> Duilio.
>
> Dennis Smit wrote:
> > Nice,
> >
> > One remark, could you change the patch so that glib is actually the
> > fallback, and not the native impl ?
> >
> > If you change that, I'll commit the patch :)
> >
> > Cheers,
> > Dennis
>
|
|
From: Dennis S. <sy...@yo...> - 2005-03-16 08:01:03
|
On Tue, 2005-03-15 at 21:37 -0300, Duilio Javier Protti wrote: > Ok, here is the patch, plus small correction within libvisual.pc.in. > > About Gthread, are you sure that this is what you want? I mean, gthread > is by itself an abstraction library around the native thread > implementation, so in general there will be always one of such > implementations present, so probably we will never use gthread. True, but we might not have a backend for some weird unix systems. and we can use gthread as a fallback there. Not sure, what does solaris use for threading ? > > Bye, > Duilio. > > Dennis Smit wrote: > > Nice, > > > > One remark, could you change the patch so that glib is actually the > > fallback, and not the native impl ? > > > > If you change that, I'll commit the patch :) > > > > Cheers, > > Dennis > |
|
From: Duilio J. P. <dp...@fc...> - 2005-03-16 00:22:31
|
Ok, here is the patch, plus small correction within libvisual.pc.in. About Gthread, are you sure that this is what you want? I mean, gthread is by itself an abstraction library around the native thread implementation, so in general there will be always one of such implementations present, so probably we will never use gthread. Bye, Duilio. Dennis Smit wrote: > Nice, > > One remark, could you change the patch so that glib is actually the > fallback, and not the native impl ? > > If you change that, I'll commit the patch :) > > Cheers, > Dennis |
|
From: Dennis S. <sy...@yo...> - 2005-03-15 18:57:21
|
Nice, One remark, could you change the patch so that glib is actually the fallback, and not the native impl ? If you change that, I'll commit the patch :) Cheers, Dennis On Tue, 2005-03-15 at 14:22 -0300, Duilio J. Protti wrote: > Ok, here is the patch which allow libvisual to detect gthread-2.0 > presence during configure process. > > To use Gthread *within* libivisual, the macro LV_HAVE_GTHREAD2 is > defined on config.h on top level source dir. > > > Bye, > Duilio. > |
|
From: Duilio J. P. <dp...@fl...> - 2005-03-15 17:30:12
|
Ok, here is the patch which allow libvisual to detect gthread-2.0 presence during configure process. To use Gthread *within* libivisual, the macro LV_HAVE_GTHREAD2 is defined on config.h on top level source dir. Bye, Duilio. |
|
From: Dennis S. <sy...@yo...> - 2005-03-15 15:01:14
|
On Fri, 2005-03-11 at 18:31 +0100, Jon =C3=98yvind Kjellman wrote: > On Wed, 09 Mar 2005 21:18:45 +0100, Dennis Smit <sy...@yo...> wro= te: > > visual_object_destroy ( ( VisObject ) actor ) ; > > The visual_object_destroy (...) function works on all obje > > > > Please should use visual_object_unref (VISUAL_OBJECT (actor)); >=20 > Fixed, new version attached. Looks very cool, the pdf seems to be rendered better as well! > > I'd love to have the LaTeX source btw :), and could you tell me how > > converting to docbook is done ? >=20 > I don't know docbook, but I assume you know it since you wanted docbook= . I =20 > don't think converting it will be a problem either way. Latex is very =20 > verbose, and I haven't used anything fancy so anyone should be able to = =20 > figure it out. (Just notice that I've created some macros/special comma= nds =20 > at the top that prints 'actor', 'video', 'input' and 'bin' in =20 > inline-codestyle.) I've added the Latex source to the package. I don't have experience with docbook :) > > Anyway it's a very good start, I am seriously very happy with it! >=20 > Glad to hear that. >=20 > I've also added a short BSD-like license to the example.c file, just to= =20 > keep things straight. Good thinking > Feel free to upload the things on your SF website, I don't really have = =20 > anywhere to host it, so ... Unless there's more you'd want me to change= ? I am going to talk about website changes to our web admin, and place it=20 online, again thanks a lot! How is your project going ? Cheers, Dennis |
|
From: Dennis S. <sy...@yo...> - 2005-03-14 15:43:47
|
Thanks for the sharp stuff, I merged all but the object->priv leak.
When a priv is set, this is either already maintained by that object, or
it should be managed yourself, for example by overriding the dtor.
Thanks for the other changes.
On Mon, 2005-03-14 at 12:11 -0300, Duilio J. Protti wrote:
> Index: libvisual/lv_object.c
> ===================================================================
> RCS file: /cvsroot/libvisual/libvisual/libvisual/lv_object.c,v
> retrieving revision 1.6
> diff -u -r1.6 lv_object.c
> --- libvisual/lv_object.c 1 Jan 2005 14:20:52 -0000 1.6
> +++ libvisual/lv_object.c 14 Mar 2005 13:16:44 -0000
> @@ -182,6 +182,9 @@
> {
> visual_log_return_val_if_fail (object != NULL, -
> VISUAL_ERROR_OBJECT_NULL);
>
> + /* mhm, this can lead to a memory leak. We must check here
> + for priv == NULL and return some -VISUAl_ERROR_NON_NULL
> + when it's not, or print some debug message at least. */
> object->priv = priv;
>
> return VISUAL_OK;
> Index: libvisual/lv_plugin.c
> ===================================================================
> RCS file: /cvsroot/libvisual/libvisual/libvisual/lv_plugin.c,v
> retrieving revision 1.64
> diff -u -r1.64 lv_plugin.c
> --- libvisual/lv_plugin.c 9 Mar 2005 12:28:34 -0000 1.64
> +++ libvisual/lv_plugin.c 14 Mar 2005 13:16:44 -0000
> @@ -419,6 +419,7 @@
> VisList *list;
> VisListEntry *entry = NULL;
> VisPluginRef *ref;
> + int ret;
>
> visual_log_return_val_if_fail (pluglist != NULL, NULL);
>
> @@ -432,11 +433,15 @@
>
> while ((ref = visual_list_next (pluglist, &entry)) != NULL) {
>
> - if (visual_plugin_type_member_of (ref->info->type,
> domain)) {
> + ret = visual_plugin_type_member_of (ref->info->type,
> domain);
> + if (ret == TRUE) {
> visual_object_ref (VISUAL_OBJECT (ref));
>
> visual_list_add (list, ref);
> }
> + else if (ret != FALSE) {
> + visual_log (VISUAL_LOG_WARNING,
> visual_error_to_string (ret));
> + }
> }
>
> return list;
> @@ -522,7 +527,8 @@
> {
> VisPluginRef **ref;
> char temp[1024];
> - int i, j, n, len;
> + int i, j, n;
> + size_t len;
> int cnt = 0;
>
> #if defined(VISUAL_OS_WIN32)
> @@ -1180,10 +1186,10 @@
> }
> }
>
> - } while (nflag = strchr (nflag, '|') + 1);
> + } while ((nflag = strchr (nflag, '|') + 1));
>
> visual_mem_free (flags);
> -
> +
> return FALSE;
> }
|
|
From: Duilio J. P. <dp...@fc...> - 2005-03-14 15:19:21
|
hehe, is truth. |
|
From: Dennis S. <sy...@yo...> - 2005-03-14 15:12:39
|
I suspect you forgot the attachment ;) On Mon, 2005-03-14 at 10:15 -0300, Duilio J. Protti wrote: > Please take a look at these small things I have catched using the splint > tool on modules lv_object and lv_plugin. There are other things to > investigate, like the uintX_t 'typeofing' stuff. > > > Bye, > Duilio. > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Libvisual-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libvisual-devel |
|
From: Duilio J. P. <dp...@fl...> - 2005-03-14 14:06:40
|
Please take a look at these small things I have catched using the splint tool on modules lv_object and lv_plugin. There are other things to investigate, like the uintX_t 'typeofing' stuff. Bye, Duilio. |
|
From: Mark K. <ma...@we...> - 2005-03-14 12:37:05
|
The amaroK team announces version 1.2.2 of the amaroK audio player
amaroK 1.2.2 offers many bugfixes, improvements and new features over the
previous release. We are especially happy to present the new Theming support
for amaroK, making it possible to style the Context-Browser with your favor=
ite
designs. Happy theming!=20
=20
ChangeLog relative to amaroK 1.2.1:
FEATURES:
* Context Browser CSS styles can now be installed and selected from the
appearance settings.
* Append Suggestions now has an icon in the statusbar.
* When selecting multiple files, the "View/Edit Meta Information" dialog
will show the tags that are common to all of them. (BR 100423)
* A line graph equalizer added as a script "graphequalizer."
CHANGES:
* Add 25-track and 50-track smart-playlists.
* Update current-track icons to include greater padding.
* The contextbrowser now uses data:-URLs instead of temp image files, so
they cannot be left on disk when amaroK terminates unexpectedly, and =
the
Konqueror/Universal sidebar can show them when amaroK is not running.
BUGFIXES:
* escape '&' char in contextmenu entry (BR 101276)
* Track is set as a number in the database, so shouldn't be added round=
ed
by quotes. (BR 101208)
* Rewrote the broken .pls playlist parser.
* Handle delay gap between songs properly with aRts engine. (BR 90404)
* Switched order of "Make playlist" and "Queue after current track" men=
us
to avoid playlist destruction. (BR 96164 part 1)
* Visualizations with LibVisual didn't work in some cases. (BR 99627)
* amaroK could fail to build if the whole kdeextragear-1 module was
compiled, due to conflicts with K3B on the MusicBrainz check.
(BR 100906)
* Images shown on OSD where incorrect for action notifications.
* The handbook translations were not built when amaroK was installed fr=
om
the tarball. I've written a new release script in Ruby, which can
handle the new structure of kde-i18n. (BR 100498)
* GStreamer-engine can now play vorbis radio streams properly, with
full metadata support. (BR 89821)
* GStreamer-engine now uses the "decodebin" autoplugger, which fixes
the lag issues that some users had during crossfading. (BR 99570)
The amaroK team
=2D--------------
amaroK is a soundsystem-independent audio-player for *nix. Its interface us=
es=20
a powerful "browser" metaphor that allows you to create playlists that make=
=20
the most of your music collection. We have a fast development-cycle and=20
super-happy users. We also provide pensions and other employment-benefits.
"Easily the best media-player for Linux at the moment. Install it now!"
=A0 =A0 - Linux Format Magazine
WWW: =A0http://amarok.kde.org
WIKI: http://amarok.kde.org/wiki/
IRC: =A0irc.freenode.net #amarok
MAIL: ama...@li...
|
|
From: Duilio J. P. <dp...@fl...> - 2005-03-13 22:28:57
|
I have added two small programs to test gtk1 and gtk2 backends. They will reside only on the repository, not in the distro package. Bye, Duilio. |
|
From: Duilio J. P. <dp...@fl...> - 2005-03-13 22:27:25
|
Well, it make use of gtk1 widgets only if they are present. If that is the case, the xmms plugin allow to change the options of every libvisual plugin that provides an user interface. libvisual-widgets still having some small problem on installation, I will take a look at this. Bye, Duilio. |
|
From: Duilio J. P. <dp...@fl...> - 2005-03-12 22:10:24
|
I have commited an initial backend for gtk+. Still missing some
components, but is enough for test, specially for finding building
problems and such.
About building problems with this module, if when 'make install' you
have something like:
/bin/sh ../libtool --mode=install /usr/bin/install -c liblvwidget_gtk2.la /home/dprotti/lib/liblvwidget_gtk2.la
/usr/bin/install -c .libs/liblvwidget_gtk2.lai /home/dprotti/lib/liblvwidget_gtk2.la
/usr/bin/install: cannot stat `.libs/liblvwidget_gtk2.lai': No such file or directory
make[2]: *** [install-libLTLIBRARIES] Error 1
make[1]: *** [install-am] Error 2
make: *** [install-recursive] Error 1
that's due to and odd error on automake's. I'm not shure why, but
sometimes automake gets confused when building two or more different
libtool targets, and this is the case. You can fix it editing
ltmain.sh script on top source directory, looking for something like:
# Install the pseudo-library for information purposes.
name=`$echo "X$file" | $Xsed -e "s%^.*/%%"`
instname="$dir/$name"i
$show "$install_prog $instname $destdir/$name"
$run eval "$install_prog $instname $destdir/$name" || exit $?
just remove that tail 'i' on third line above, and rebuild everything.
I have notices of other projects having the same problem. Of course,
we must make distro packages with the hacked ltmain.sh.
Please test!
Bye,
Duilio.
|
|
From: <jo...@so...> - 2005-03-11 17:23:17
|
On Wed, 09 Mar 2005 21:18:45 +0100, Dennis Smit <sy...@yo...> wrote: > visual_object_destroy ( ( VisObject ) actor ) ; > The visual_object_destroy (...) function works on all obje > > Please should use visual_object_unref (VISUAL_OBJECT (actor)); Fixed, new version attached. > I'd love to have the LaTeX source btw :), and could you tell me how > converting to docbook is done ? I don't know docbook, but I assume you know it since you wanted docbook. I don't think converting it will be a problem either way. Latex is very verbose, and I haven't used anything fancy so anyone should be able to figure it out. (Just notice that I've created some macros/special commands at the top that prints 'actor', 'video', 'input' and 'bin' in inline-codestyle.) I've added the Latex source to the package. > Anyway it's a very good start, I am seriously very happy with it! Glad to hear that. I've also added a short BSD-like license to the example.c file, just to keep things straight. Feel free to upload the things on your SF website, I don't really have anywhere to host it, so ... Unless there's more you'd want me to change? Best, Jon Øyvind |
|
From: Dennis S. <sy...@yo...> - 2005-03-09 20:18:55
|
Heya Jon, Wow, super cool, I've read over it, some small comments: visual_object_destroy ( ( VisObject ) actor ) ; The visual_object_destroy (...) function works on all obje Please should use visual_object_unref (VISUAL_OBJECT (actor)); Overall it's a very good start, it's especially great to serve as a 'get started' manual. I am very happy with it! I'd love to have the LaTeX source btw :), and could you tell me how converting to docbook is done ? Anyway it's a very good start, I am seriously very happy with it! Regarding the sample size, I think the alsa plugin isn't particular=20 great either, but we have to look into that.=20 Cheers, Dennis On Wed, 2005-03-09 at 20:20 +0100, Jon =C3=98yvind Kjellman wrote: > Hello again. I said I'd make a tutorial and example program, so here th= ey =20 > are. It's not very polished and didn't turn out the way I expected. The= re =20 > might be grave errors (both factual and grammatical) so, please, do =20 > comment on it. >=20 > I've got the document in latex format so it can be converted to html, b= ut =20 > some formatting is ruined. I can post the latex source if anyone wants = to =20 > convert it to docbook. BTW, The pdf isn't optimal either, the codelisti= ngs =20 > spill over the margin, but it's readable. >=20 > Oh, and regarding the discussion on sample-size yesterday, todays sampl= es =20 > seem to big. Many plug-ins 'flow' badly, and there's notable delay on s= ome. >=20 > Best, > Jon =C3=98yvind |
|
From: <jo...@so...> - 2005-03-09 19:12:17
|
Hello again. I said I'd make a tutorial and example program, so here they are. It's not very polished and didn't turn out the way I expected. There might be grave errors (both factual and grammatical) so, please, do comment on it. I've got the document in latex format so it can be converted to html, but some formatting is ruined. I can post the latex source if anyone wants to convert it to docbook. BTW, The pdf isn't optimal either, the codelistings spill over the margin, but it's readable. Oh, and regarding the discussion on sample-size yesterday, todays samples seem to big. Many plug-ins 'flow' badly, and there's notable delay on some. Best, Jon Øyvind |
|
From: Dennis S. <sy...@yo...> - 2005-03-09 18:55:24
|
Heya, I checked in the following toy: libvisual-hackground/playground/libvis-vnc.c It needs libvncviewer 0.7.1 It's just a hack, but the idea is fun! Vitaly, I had a look at making a libvncviewer backend within lvdisplay, but failed completely *hehe*, but it might be a fun idea. one could easily set up some graphical statics station using libvisual and libvisual-display: vnc backend, could be fun. It's far too slow for actor plugins of course, still fun, but hey. Cheers, Dennis |
|
From: Dennis S. <sy...@yo...> - 2005-03-09 11:24:41
|
On Wed, 2005-03-09 at 12:01 +0100, Burkhard Plaum wrote: > Dennis Smit wrote: > > > Just a small example: We wouldn't be able to be used by commercial > > gstreamer products. Or by closed source media plugins on the windows > > platform. > > If you write the best visualization framework on this planet, > you have the chance to make all commercial programs obsolete, > so the GPL apps would win. I am not yet placing my bets on that :) > > It's just closing the doors, for many possibilities. > > Using LGPL closes the doors for the possibility to use > GPL libs. It has two sides yes, I've chosen this one ;) > Nobody paid me a cent for writing my stuff, so why should I allow > others to make money with it? I can't care too much about others making profit using lv, not sure how the other developers thing about this topic. But I think that total widespread is more important in this case ;) > Everyone has his own brain yea :-) Very true :) Cheers, Dennis |
|
From: Burkhard P. <pl...@ip...> - 2005-03-09 10:55:25
|
Dennis Smit wrote: > Just a small example: We wouldn't be able to be used by commercial > gstreamer products. Or by closed source media plugins on the windows > platform. If you write the best visualization framework on this planet, you have the chance to make all commercial programs obsolete, so the GPL apps would win. > It's just closing the doors, for many possibilities. Using LGPL closes the doors for the possibility to use GPL libs. Nobody paid me a cent for writing my stuff, so why should I allow others to make money with it? Everyone has his own brain yea :-) Cheers Burkhard |
|
From: Dennis S. <sy...@yo...> - 2005-03-08 17:33:02
|
On Tue, 2005-03-08 at 18:26 +0100, Burkhard Plaum wrote: > > Bummer, I really want a LGPL library, > Why? Because I refuse to close the doors for non GPL compatible software. Just a small example: We wouldn't be able to be used by commercial gstreamer products. Or by closed source media plugins on the windows platform. It's just closing the doors, for many possibilities. Cheers, Dennis |
|
From: Burkhard P. <pl...@ip...> - 2005-03-08 17:22:28
|
> Bummer, I really want a LGPL library, Why? -- _____________________________ Dr.-Ing. Burkhard Plaum Institut fuer Plasmaforschung Pfaffenwaldring 31 70569 Stuttgart Tel.: +49 711 685-2187 Fax.: -3102 |
|
From: Dennis S. <sy...@yo...> - 2005-03-08 17:00:45
|
On Tue, 2005-03-08 at 17:56 +0100, Burkhard Plaum wrote: > Ok, then a generic audio converter becomes necessary. > It could, however, be a bit more simple than in gavl, because the > output format is always the same. Yep. > > I think that a dependency is going to give us problems, also since we're > > porting to windows, mac os X. > > The ANSI C-part of gavl should be quite portable. > The MMX stuff (used for Video only at the moment) should be disabled > by the configure script on unsupported platforms. > > > However would you mind us assimilating > > features from gavl into our VisAudio ? > > Hmm, depends on how it's done. If single functions are copied and > pasted, I don't want them to become LGPL. > > If you write an own implementation based on IDEAS from gavl, it's ok. I think we have to use the ideas then, since GPL licensing libvisual is not an option for me. > > The biggest problem is > > that we're LGPL and you're GPL. > > If I gain something from it, we could solve this. > > But the only nonstandard dependency of gavl is libsamplerate, which is > also GPL. So forget resampling (or switch to GPL). Bummer, I really want a LGPL library, so we have to work out something differently. But you have put much research into gavl for sure, so we can use the lessons you've learned. Thanks, Dennis |
|
From: Burkhard P. <pl...@ip...> - 2005-03-08 16:52:15
|
Dennis Smit wrote: > The idea is to provide ONE format to the VisActor plugins, since they > shouldn't be dealing with all kind of different formats. Makes sense. > However we > should be able to handle input in different formats nicely. Ok, then a generic audio converter becomes necessary. It could, however, be a bit more simple than in gavl, because the output format is always the same. > I think that a dependency is going to give us problems, also since we're > porting to windows, mac os X. The ANSI C-part of gavl should be quite portable. The MMX stuff (used for Video only at the moment) should be disabled by the configure script on unsupported platforms. > However would you mind us assimilating > features from gavl into our VisAudio ? Hmm, depends on how it's done. If single functions are copied and pasted, I don't want them to become LGPL. If you write an own implementation based on IDEAS from gavl, it's ok. > The biggest problem is > that we're LGPL and you're GPL. If I gain something from it, we could solve this. But the only nonstandard dependency of gavl is libsamplerate, which is also GPL. So forget resampling (or switch to GPL). -- _____________________________ Dr.-Ing. Burkhard Plaum Institut fuer Plasmaforschung Pfaffenwaldring 31 70569 Stuttgart Tel.: +49 711 685-2187 Fax.: -3102 |
10 messages has been excluded from this view by a project administrator.
