From: Dennis S. <sy...@yo...> - 2005-02-01 02:10:50
|
Heya fellahs, Major changes went into libvisual, some might be unstable, even completely broken. I've put online libvisual 0.2.0pre1, PLEASE test this release, report if it works, and especially if it does NOT work! If no critical borkness is detected, this will be the release in only a few days from now. Available: http://www.plasser.nl/synap/libvisual/snapshots/libvisual-0.2.0.tar.bz2 http://www.plasser.nl/synap/libvisual/snapshots/libvisual- plugins-0.2.0.tar.bz2 http://www.plasser.nl/synap/libvisual/snapshots/libvisual- xmms-0.2.0.tar.bz2 http://www.plasser.nl/synap/libvisual/snapshots/libvisual- bmp-0.2.0.tar.bz2 NOTE: G-Force and nebulus are now merged INTO libvisual-plugins. NEWS: libvisual: New in 0.2.0pre1: 2005-02-01: * VisTransform subsystem. (Dennis) * visual_palette_color_cycle() function. (Dennis) * visual_param_container_copy_match() function. (Dennis) * visual_param_container_copy() function. (Dennis) * visual_timer_elapsed_msecs() function. (Dennis) * VisCPU subsystem. (Dennis) * visual_mem_copy(), will contain mmx, sse versions later on. (Dennis) * MMX version of the 32bits bilinear filter. (Jean-Christophe) * Fixed the visual_video_blit_overlay(). (Dennis) * MMX versions of the 32bits alpha overlay. (Dennis) * VisPluginEnviron system added. (Vitaly, Dennis) * Nearest scalers. (Chong Kai Xiong, Dennis) * Bilinear scalers. (Jean-Christophe, Dennis) * VisError error values, and human readable errors. (Dennis) * Objectification of all libvisual structures. (Dennis) * Complete VisObject system. (Dennis) * VisSongInfo, use the bilinear filterer, scaler for coverart. (Dennis) * VisPalette VisParamEntry type. (Dennis) * VisObject VisParamEntry type. (Dennis) * VisThread threading wrapper system. (Dennis) * VisUI Complete userinterface abstraction layer. (Dennis) * Have a string only plugin type, plugins are now members of domains. (Dennis, Vitaly) * Many many fixes, improvements and such. (Everyone) libvisual-plugins: New in 0.2.0pre1: 2005-02-01: * Adding pseudotoad flower actor plugin, ported. (Dennis) * Adding dancing particles plugin, ported. (Dennis) * Including G-Force in package. (Dennis) * Including Nebulus in package. (Dennis) * Adding corona actor plugin, ported. (Dennis, Jean-Christophe) * Fixed bumpscope actor plugin. (Dennis) * MMX code added to JESS, alphablend, oinksie (Dennis) * Fixing many bugs in plugins. (Everyone) * Adding VisUI userinterfaces to plugins, not usable yet because there is no client support yet. (Dennis) the other stuff is purely maintaince and api updateness. Cheers, Dennis |
From: Michael A. P. <mp...@ma...> - 2005-02-01 05:16:17
Attachments:
libvisual-plugins.spec
|
On 01/31/2005 06:10:46 PM, Dennis Smit wrote: > Heya fellahs, >=20 > Major changes went into libvisual, some might be unstable, even > completely broken. >=20 > I've put online libvisual 0.2.0pre1, PLEASE test this release, report > if it works, and especially if it does NOT work! Fedora Core 3 uninstalled previous libvisual stuff completely compiled libvisual and then libvisual-plugins and then libvisual-xmms Build methos was via rpm During build of libvisual-plugins, the make install threw all the =20 plugins into %buildroot/usr/lib the .la files did have correct path ( /usr/lib/libvisual/whatever/ ) =20 but that's not where they were installed (it is in the stable version) However - when I had the spec file manually create the directorys and =20 move the plugins - they work fine with the xmms-plugin Note on the xmms plugin - when it starts from cli, it complains that it =20 failed to load /usr/lib/libvisual/transform That directory does not exist, I don't know if it is suppose to - but =20 the visualizers (so far anyway) do seem to work - at least in xmms. Just earlier this month - GStreamer put out a bunch of updates, and the =20 libvisual plugins worked in totem again - I haven't tried with the =20 0.2.0 libvisual, but if there is a problem - then I'm guessing that's a =20 GStreamer-plugins patch that would be needed. I'll try that tomorrow afternoon (rebuild the libvisual gstreamer =20 plugin and see if it builds and works) But other than the makefile issue in the rpm specfile with where the =20 plugins go, it seems to work. Attached is that specfile. |
From: Dennis S. <sy...@yo...> - 2005-02-01 08:45:57
|
On Tue, 2005-02-01 at 05:16 +0000, Michael A. Peters wrote: > On 01/31/2005 06:10:46 PM, Dennis Smit wrote: > > Heya fellahs, > > > > Major changes went into libvisual, some might be unstable, even > > completely broken. > > > > I've put online libvisual 0.2.0pre1, PLEASE test this release, report > > if it works, and especially if it does NOT work! > > Fedora Core 3 > > uninstalled previous libvisual stuff completely > > compiled libvisual and then libvisual-plugins and then libvisual-xmms > > Build methos was via rpm > > During build of libvisual-plugins, the make install threw all the > plugins into > > %buildroot/usr/lib > > the .la files did have correct path ( /usr/lib/libvisual/whatever/ ) > but that's not where they were installed (it is in the stable version) I don't have much experience with building rpm packages, however using the .spec file, this should be solved ? Or, what should I do with the spec file, is it advisible to include it in the CVS development tree ? > However - when I had the spec file manually create the directorys and > move the plugins - they work fine with the xmms-plugin > > Note on the xmms plugin - when it starts from cli, it complains that it > failed to load /usr/lib/libvisual/transform Nothing harmful, point is that there are no transform plugins yet, so the directory isn't created :). > Just earlier this month - GStreamer put out a bunch of updates, and the > libvisual plugins worked in totem again - I haven't tried with the > 0.2.0 libvisual, but if there is a problem - then I'm guessing that's a > GStreamer-plugins patch that would be needed. I think they'll have to update. > I'll try that tomorrow afternoon (rebuild the libvisual gstreamer > plugin and see if it builds and works) > > But other than the makefile issue in the rpm specfile with where the > plugins go, it seems to work. Attached is that specfile. Thanks a lot for testing, this is much appreciated! Cheerios, Dennis |
From: Michael A. P. <mp...@ma...> - 2005-02-01 07:06:18
|
>=20 > the other stuff is purely maintaince and api updateness. Would it be possible to version the pkgconfig file? GStreamer plugins builds against it, but I'm guessing due to the api =20 updateness, the plugin doesn't load. If the pkgconfig file were =20 versioned, then gstreamer-plugins would not try to build the libvisual =20 plugin until they update their plugin for the new apu. |
From: Dennis S. <sy...@yo...> - 2005-02-01 08:54:56
|
On Tue, 2005-02-01 at 07:06 +0000, Michael A. Peters wrote: > > > > the other stuff is purely maintaince and api updateness. > > Would it be possible to version the pkgconfig file? > GStreamer plugins builds against it, but I'm guessing due to the api > updateness, the plugin doesn't load. If the pkgconfig file were > versioned, then gstreamer-plugins would not try to build the libvisual > plugin until they update their plugin for the new apu. Actually, it should be versioned, you're talking about the libvisual.pc file right ? |
From: Michael A. P. <mp...@ma...> - 2005-02-05 02:40:52
|
On 02/01/2005 12:54:51 AM, Dennis Smit wrote: >=20 > Actually, it should be versioned, you're talking about the > libvisual.pc > file right ? Yes. The file name itself is used by a lot of configure scripts - and the =20 filename itself should be a different name so that you can have =20 multiple API versions installed side by side. |
From: Dennis S. <sy...@yo...> - 2005-02-05 08:55:44
|
On Sat, 2005-02-05 at 02:40 +0000, Michael A. Peters wrote: > On 02/01/2005 12:54:51 AM, Dennis Smit wrote: > > > > > Actually, it should be versioned, you're talking about the > > libvisual.pc > > file right ? > > Yes. > The file name itself is used by a lot of configure scripts - and the > filename itself should be a different name so that you can have > multiple API versions installed side by side. Ahyeah, But we don't have branches yet, so :). |