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: Max H. <max...@me...> - 2004-11-28 21:06:20
|
The amaroK team announces version 1.2-beta1 of the amaroK audio player!
Are you excited yet? We hope so! This release brings you among other things:
1. Happiness!
2. Job-satisfaction!
3. Better sex! (or -- if more applicable -- sex!)
(And the following new features):
* Full Audioscrobbler support
* Vorbis stream metadata support
* Cover fetching for specific Amazon locales
* Fabulous new eye-candy!
* Compile-time MySQL database support
* Configurable OSD text
* 10-band IIR equalizer for the GStreamer and xine engines
* Rewritten and vastly improved NMM-engine
* Automatic lyrics display
* Tweaks, fixes and other improvements!
Please download, enjoy and direct any feedback at our IRC channel or
mailing-list (details below), we promise to use all suggestions when deciding
on the development for 1.2-beta2. Thanks :-)
The amaroK team
---------------
amaroK is a soundsystem-independent audio-player for *nix. Its interface uses
a powerful "browser" metaphor that allows you to create playlists that make
the most of your music collection. We have a fast development-cycle and
super-happy users. We also provide pensions and other employment-benefits.
"Easily the best media-player for Linux at the moment. Install it now!"
- Linux Format Magazine
WWW: http://amarok.kde.org
IRC: irc.freenode.net #amarok
MAIL: ama...@li...
|
|
From: Dennis S. <sy...@yo...> - 2004-11-28 13:31:48
|
Thanks a lot for the patch, everything is merged and looking
good!!!, awesome :)
Regarding visual_plugin_get_list:
2004-11-28 Dennis Smit <ds...@ne...>
* libvisual/lv_plugin.c (visual_plugin_get_list):
Don't completely bail out when there is a invalid path in the
plugin
registry. Instead spit a warning and just use those that are
valid.
That is fixed as well, thanks for pointing out ;)
Cheers,
Dennis
On Sun, 2004-11-28 at 02:10 +0200, Vitaly V. Bursov wrote:
> Ok, here's a patch. I can't test bmp, xmms and nebulus right now,
> but "plugins" looks like works fine.
>
>
> Next, visual_plugin_get_list function will fail and return NULL
> if list with plugin directories contains non-existing (e.g.)
> directory even if there are other dirs with valid plugins...
> I think it's wrong.
>
|
|
From: Dennis S. <sy...@yo...> - 2004-11-28 12:49:16
|
On Sun, 2004-11-28 at 13:29 +0200, Vitaly V. Bursov wrote: > On Sun, 28 Nov 2004 03:03:52 +0100 > Dennis Smit <sy...@yo...> wrote: > > > for libvisual-display we're using: > > lvdisplay .. and no plugin path yet. > Hm. Is "lv" prefix necessary? anyway, it's in libvisual directory. > Currently I install drivers to libvisual/display/. ;) That is good! > > I think it's important to decide what we want here.. > > > > Aka how are we going to define the namespace of our libraries > > should we go lv_ lvw_ lvd_ ... or is visual lvwidget lvdisplay nicer ? > Lvd for structures, lvdisplay_ for functions. Ok, I'll be changing lvw to be lvwidget :) |
|
From: Vitaly V. B. <vit...@us...> - 2004-11-28 11:30:15
|
On Sun, 28 Nov 2004 03:03:52 +0100 Dennis Smit <sy...@yo...> wrote: > for libvisual-display we're using: > lvdisplay .. and no plugin path yet. Hm. Is "lv" prefix necessary? anyway, it's in libvisual directory. Currently I install drivers to libvisual/display/. ;) > I think it's important to decide what we want here.. > > Aka how are we going to define the namespace of our libraries > should we go lv_ lvw_ lvd_ ... or is visual lvwidget lvdisplay nicer ? Lvd for structures, lvdisplay_ for functions. > But in the current fashion, it would be include/lvdisplay... :) Yes, I agree. -- Vitaly GPG Key ID: F95A23B9 |
|
From: Vitaly V. B. <vit...@us...> - 2004-11-28 02:19:17
|
Ok, here's a patch. I can't test bmp, xmms and nebulus right now, but "plugins" looks like works fine. Next, visual_plugin_get_list function will fail and return NULL if list with plugin directories contains non-existing (e.g.) directory even if there are other dirs with valid plugins... I think it's wrong. -- Vitaly GPG Key ID: F95A23B9 |
|
From: Dennis S. <sy...@yo...> - 2004-11-28 02:04:08
|
Now we're talking about this anyway... We should get the API prefix right as well. for libvisual we're currently using: libvisual (for for plugin path as api namespace) for libvisual-widget we're using: lvw (same story) for libvisual-display we're using: lvdisplay .. and no plugin path yet. I think it's important to decide what we want here.. Aka how are we going to define the namespace of our libraries should we go lv_ lvw_ lvd_ ... or is visual lvwidget lvdisplay nicer ? I'm kinda undecided here, tempted to just 'let it go for a while' but that might be not the best thing to do! But in the current fashion, it would be include/lvdisplay... :) Cheers, Dennis On Sun, 2004-11-28 at 02:15 +0200, Vitaly V. Bursov wrote: > Dennis, > > How do you think lvdisplay's headers should be installed? > > include/libvisual/display > include/libvisual-display > include/lvdisplay > > Others? I'm not sure. > |
|
From: Dennis S. <sy...@yo...> - 2004-11-28 01:57:43
|
On Sat, 2004-11-27 at 23:26 +0200, Vitaly V. Bursov wrote: > On Sat, 27 Nov 2004 15:38:41 +0100 > Dennis Smit <sy...@yo...> wrote: > > > however I don't think it's a good idea to make the loader > > recursive. I gave the reason in an earlier post. > Maybe you're right... Why not to scan only first subdirectory > level? I think this is kinda 'hacky' like in 'well, we just scan the FIRST subdir.. I rather use the method we're using right now.. personally that is. > > Btw, do you have time to do this auto cleanup style for > > the other packages as well ? > Yeah. Alright, I'm very happy with that!! Thanks ;) |
|
From: Vitaly V. B. <vit...@us...> - 2004-11-28 00:15:11
|
Dennis, How do you think lvdisplay's headers should be installed? include/libvisual/display include/libvisual-display include/lvdisplay Others? I'm not sure. -- Vitaly GPG Key ID: F95A23B9 |
|
From: Vitaly V. B. <vit...@uk...> - 2004-11-27 23:49:03
|
On Sat, 27 Nov 2004 15:38:41 +0100 Dennis Smit <sy...@yo...> wrote: > however I don't think it's a good idea to make the loader > recursive. I gave the reason in an earlier post. Maybe you're right... Why not to scan only first subdirectory level? > Btw, do you have time to do this auto cleanup style for > the other packages as well ? Yeah. -- Vitaly GPG Key ID: F95A23B9 |
|
From: Dennis S. <sy...@yo...> - 2004-11-27 14:38:45
|
Patch has been merged! Thanks a lot it's a nice cleanup.
the LIBVISUAL_PLUGIN_BASE_DIR path has also been merged.
however I don't think it's a good idea to make the loader
recursive. I gave the reason in an earlier post.
Btw, do you have time to do this auto cleanup style for
the other packages as well ?
Thanks a lot,
Dennis
On Thu, 2004-11-25 at 20:19 +0200, Vitaly V. Bursov wrote:
> regarding to autotools. Patch modifies/adds these options
> --enable-debug
> --enable-extra-optimization
>
> it also defines LIBVISUAL_PLUGINS_BASE_DIR variable to specify base
> dir for plugins. i.e. dir that contains actor, input, morph.
>
> Please review.
>
> If you'll keep BASE_DIR portion of a patch, it would be nice if
> libvisual's plugin loader loaded LIBVISUAL_PLUGINS_BASE_DIR/*/*.so
> libraries, not LIBVISUAL_PLUGINS_BASE_DIR/{actor,...}/*.so.
>
> ps. lvdisplay autotoolsification is almost done :) it only depends
> on what you, Dennis, think about LIBVISUAL_PLUGINS_BASE_DIR etc.
>
|
|
From: Dennis S. <sy...@yo...> - 2004-11-27 14:18:52
|
Committed. On Sat, 2004-11-27 at 01:27 -0300, Duilio Javier Protti wrote: > Here is a patch for libvisual's configure.ac, with changes: > > - CFLAGS are not overrided anymore. > - DEBUG_CFLAGS are handled correctly (one option don't override the > other, like -ggdb3/-pg in the past). > - flags for thread linkage are guessed, AND INCLUDED on libvisual.pc, so > the clients of the library will link correctly against libvisual when > thread support is enabled. > > > Bye, > Duilio. > |
|
From: Dennis S. <sy...@yo...> - 2004-11-27 14:04:15
|
Heya, I've changed a few things in CVS regarding the gtk2.4< popup thingy, take a look. Also the GTK >= 2.4 check seems to fail. It's compiling the GtkRadioMenuItem thingy instead of combobox at my machine. While I'm on gtk CVS :) Cheers, Dennis |
|
From: Dennis S. <sy...@yo...> - 2004-11-27 12:13:31
|
On Sat, 2004-11-27 at 01:27 -0300, Duilio Javier Protti wrote: > Dennis, thanks a lot for the test program! Here I send attached the > patch for libvisual-widgets with gtk+ < 2.4, which works really well on > my system (gtk+ 2.2.2), but please test if you can. > > I will start to work on the gtk1 port, so when finished we can add > per-plugin config dialogs to libvisual-xmms. Alright you can, but keep in mind that the gtk2 widget isn't yet totally finished and needs a few cleanups, and I've got a theory about a possible thread race condition that would be fatal (very unlikely but it's there) I need to figure that out.. I advice you to wait till that is fixed, and then port the whole stuff over... But that is completely up to you. Also VisCPU needs a bit more attention maybe you can look at bit more to that ;) Thanks for the patch, I'm going to look at it and put it in CVS! How do you like the VisUI implementation btw ? :) Ooh about the libvisual-xmms/bmp clients... When lvdisplay is a bit more further (a few weeks) I think it's best to drop the current implementations, design a new one and do it from scratch. Cheers, Dennis |
|
From: Duilio J. P. <dp...@fc...> - 2004-11-27 04:24:59
|
Here is a patch for libvisual's configure.ac, with changes: - CFLAGS are not overrided anymore. - DEBUG_CFLAGS are handled correctly (one option don't override the other, like -ggdb3/-pg in the past). - flags for thread linkage are guessed, AND INCLUDED on libvisual.pc, so the clients of the library will link correctly against libvisual when thread support is enabled. Bye, Duilio. |
|
From: Duilio J. P. <dp...@fc...> - 2004-11-27 04:24:50
|
Dennis, thanks a lot for the test program! Here I send attached the patch for libvisual-widgets with gtk+ < 2.4, which works really well on my system (gtk+ 2.2.2), but please test if you can. I will start to work on the gtk1 port, so when finished we can add per-plugin config dialogs to libvisual-xmms. Bye, Duilio. |
|
From: Max H. <max...@me...> - 2004-11-26 16:45:11
|
I rather fancy little screenshot images from each visualisation on demand. = And=20 a little meta data. A good way in my mind to get this stuff without having = to=20 dlopen any plugins is to use freedesktop desktop files. In amaroK we use=20 desktop files to fish for our engine backends, they look a little like this: [Desktop Entry] Type=3DService Name=3Dxine Engine Name[sv]=3DXine-gr=C3=A4nssnitt ServiceTypes=3DamaroK/Plugin X-KDE-amaroK-plugintype=3Dengine X-KDE-amaroK-name=3Dxine-engine X-KDE-amaroK-authors=3DMax Howell X-KDE-amaroK-email=3Dm...@me... X-KDE-amaroK-rank=3D254 X-KDE-amaroK-version=3D1 X-KDE-amaroK-framework-version=3D3 The specification for the files is here:=20 http://freedesktop.org/wiki/Standards_2fbasedir_2dspec well it should be, but currently freedesktop.org seems to be broken. We use ktrader to get plugin information, which is fast because kde caches = the=20 data in a kind of "registry" file. I'm sure there is an equivalent for=20 glib/gnomelib clients. So each actor could have a screenshot.png in some share/ directory and the= =20 desktop for that actor could have a set of entries like: X-libvisual-type=3Dactor X-libvisual-name=3Dfoobar X-libvisual-screenshot=3D/path/to/png etc. The advantages is the lower load time for information, and that you don't h= ave=20 to recompile to change these details. But I dunno if that's a good enough=20 reason as you could always make a plugin cache. But this way you don't have= =20 to make more functions for extra meta data, nor update the api for new=20 metadata, and clients don't have to use new tools to get the data. There's probably more pros/cons, but I'm not extremely experienced with the= ir=20 use. Max =2D-=20 Max Howell; MK, UK; http://www.methylblue.com/ |
|
From: Dennis S. <sy...@yo...> - 2004-11-26 14:52:38
|
As a reply to your patch, could you explain a bit what you're doing, I don't think we need this new gobject boiler plating. I prefer to just set a pointer in our base class th a private and allocate it when you can't use gobject it's private system. Think about it. |
|
From: Dennis S. <sy...@yo...> - 2004-11-26 14:50:39
|
There are some errors in your test setup, I added them mixed with
the qouted part, look at it :)
>
> #include <gtk/gtk.h>
> #include <lvw/gtk2/lvw_gtk2_visui.h>
>
>
> int main (int argc, char *argv[])
> {
> VisUIWidget *lvwidget;
VisActor *actor;
> GtkWidget *window, *widget;
gtk_init (&argc, &argv);
visual_init (&argc,&argv);
> window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
> // lvwidget = visual_ui_label_new ("Hello World!", FALSE);
actor = visual_actor_new ("bumpscope");
visual_actor_realize (actor);
lvwidget = visual_plugin_get_userinterface (visual_actor_get_plugin (actor));
>
> widget = lvw_visui_new (lvwidget);
>
> gtk_container_add (GTK_CONTAINER(window), widget);
> // gtk_widget_show (widget);
>
> gtk_widget_show_all (window);
>
gtk_main ();
>
> return 0;
> }
>
>
>
> I'm doing something wrong? If somebody have another test for
> libvisual-widgets (that knows it works) please send to the list.
Here ya go :)
> I'll keep working on this tomorrow.
Cool, would be great to have it working on both gtk2.4 and (> 2.4)
Thanks,
Dennis
|
|
From: Duilio J. P. <dp...@fc...> - 2004-11-26 04:56:26
|
Ok, I send here a (incomplete) patch. With the simple test program:
#include <gtk/gtk.h>
#include <lvw/gtk2/lvw_gtk2_visui.h>
int main (int argc, char *argv[])
{
VisUIWidget *lvwidget;
GtkWidget *window, *widget;
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
lvwidget = visual_ui_label_new ("Hello World!", FALSE);
widget = lvw_visui_new (lvwidget);
gtk_container_add (GTK_CONTAINER(window), widget);
gtk_widget_show (widget);
gtk_widget_show (window);
return 0;
}
I have the following errors:
(process:11354): GLib-GObject-CRITICAL **: gtype.c:1871: initialization
assertion failed, use g_type_init() prior to this function
(process:11354): GLib-GObject-CRITICAL **: gtype.c:1871: initialization
assertion failed, use g_type_init() prior to this function
(process:11354): GLib-GObject-CRITICAL **: gtype.c:1871: initialization
assertion failed, use g_type_init() prior to this function
(process:11354): GLib-GObject-CRITICAL **: file gtype.c: line 1937
(g_type_add_interface_static): assertion `G_TYPE_IS_INSTANTIATABLE
(instance_type)' failed
(process:11354): GLib-GObject-CRITICAL **: gtype.c:1871: initialization
assertion failed, use g_type_init() prior to this function
(process:11354): GLib-GObject-CRITICAL **: gtype.c:1871: initialization
assertion failed, use g_type_init() prior to this function
(process:11354): GLib-GObject-CRITICAL **: gtype.c:1871: initialization
assertion failed, use g_type_init() prior to this function
(process:11354): GLib-GObject-CRITICAL **: file gobject.c: line 615
(g_object_new): assertion `G_TYPE_IS_OBJECT (object_type)' failed
Segmentation violation
I'm doing something wrong? If somebody have another test for
libvisual-widgets (that knows it works) please send to the list.
I'll keep working on this tomorrow.
Bye,
Duilio.
|
|
From: Dennis S. <sy...@yo...> - 2004-11-25 21:09:09
|
Ooh one other thing.. Lvdisplay looks good, the two GL contexts in one process transparantly is awesome! However there is this weird bug where sometimes a windows shows without a border! :) Any idea about this, can't find a good reproduction pattern tho... Cheers, Dennis |
|
From: Dennis S. <sy...@yo...> - 2004-11-25 21:07:13
|
On Thu, 2004-11-25 at 20:19 +0200, Vitaly V. Bursov wrote:
> On Wed, 24 Nov 2004 21:29:03 +0100
> Dennis Smit <sy...@yo...> wrote:
>
> > > That's wrong. I know no nvidia drivers (> 4xxx) that use GLX 1.2.
> > > GLX 1.2 is used by Mesa...
> >
> > Hmms that is strange, I'm on nvidia 100% positive...
>
> $ find /usr/X11R6/lib /usr/lib -name 'libglx*' -or -name '*GL*'
> should look smth like this... if there are some "strange" duplicates
> they may cause such problems.
Rightos, apt-get installed mesa3d again on an upgrade, I fixed this by
installing the new NVIDIA drivers ;), thanks !
> regarding to autotools. Patch modifies/adds these options
> --enable-debug
> --enable-extra-optimization
Sounds good, we already had --enable-debug I'm quite sure :)
> it also defines LIBVISUAL_PLUGINS_BASE_DIR variable to specify base
> dir for plugins. i.e. dir that contains actor, input, morph.
>
> Please review.
>
> If you'll keep BASE_DIR portion of a patch, it would be nice if
> libvisual's plugin loader loaded LIBVISUAL_PLUGINS_BASE_DIR/*/*.so
> libraries, not LIBVISUAL_PLUGINS_BASE_DIR/{actor,...}/*.so.
>
> ps. lvdisplay autotoolsification is almost done :) it only depends
> on what you, Dennis, think about LIBVISUAL_PLUGINS_BASE_DIR etc.
I partially agree with you, having the BASE_DIR stuff sounds good,
however having the plugin loader recursively aggegrate is doubtful.
someone might add a plugin path that is somewhere at top in the
filesystem and gets the plugin loader to recursive read half the
filesystem.
What do you think ?
Cheers,
Dennis
|
|
From: Vitaly V. B. <vit...@us...> - 2004-11-25 18:19:23
|
On Wed, 24 Nov 2004 21:29:03 +0100
Dennis Smit <sy...@yo...> wrote:
> > That's wrong. I know no nvidia drivers (> 4xxx) that use GLX 1.2.
> > GLX 1.2 is used by Mesa...
>
> Hmms that is strange, I'm on nvidia 100% positive...
$ find /usr/X11R6/lib /usr/lib -name 'libglx*' -or -name '*GL*'
should look smth like this... if there are some "strange" duplicates
they may cause such problems.
======
/usr/X11R6/lib/modules/extensions/libglx.so
/usr/X11R6/lib/modules/extensions/libglx.so.1.0.6629
/usr/X11R6/lib/libGLU.a
/usr/X11R6/lib/libGLU.so.1.3
/usr/X11R6/lib/libGLU.so.1
/usr/X11R6/lib/libGLU.so
/usr/X11R6/lib/libGLw.so.1.0
/usr/X11R6/lib/libGLw.so.1
/usr/X11R6/lib/libGLw.so
/usr/X11R6/lib/libGLw.a
/usr/lib/perl5/5.8.5/unicore/lib/lb/GL.pl
/usr/lib/libGL.so.1.0.6629
/usr/lib/libGLcore.so.1.0.6629
/usr/lib/libGL.la
/usr/lib/libGL.so.1
/usr/lib/libGL.so
/usr/lib/libGLcore.so.1
======
regarding to autotools. Patch modifies/adds these options
--enable-debug
--enable-extra-optimization
it also defines LIBVISUAL_PLUGINS_BASE_DIR variable to specify base
dir for plugins. i.e. dir that contains actor, input, morph.
Please review.
If you'll keep BASE_DIR portion of a patch, it would be nice if
libvisual's plugin loader loaded LIBVISUAL_PLUGINS_BASE_DIR/*/*.so
libraries, not LIBVISUAL_PLUGINS_BASE_DIR/{actor,...}/*.so.
ps. lvdisplay autotoolsification is almost done :) it only depends
on what you, Dennis, think about LIBVISUAL_PLUGINS_BASE_DIR etc.
--
Vitaly
GPG Key ID: F95A23B9
|
|
From: Dennis S. <sy...@yo...> - 2004-11-25 12:57:14
|
Alright, sounds excelent, I'm looking forward to the patch! On Wed, 2004-11-24 at 20:29 -0300, Duilio Javier Protti wrote: > I have found a way to fix this, the only issue is that glib will doesn't > have knowledge about the private info, but I think that's not a problem > on our context (the destroyer will get data he needs). > > I hope to have the patch tomorrow. > > > Bye, > Duilio. |
|
From: Dennis S. <sy...@yo...> - 2004-11-25 12:55:08
|
On Wed, 2004-11-24 at 21:35 +0200, Vitaly V. Bursov wrote: > On Wed, 24 Nov 2004 00:21:17 +0100 > Dennis Smit <sy...@yo...> wrote: > > > This way we provide a generalized ref counting interface. That > > also supports complex object desctructors that are set at object > > creation. With this change most of the other _free and _destroy > > functions are history and object disposing should be done using > > an visual_object_unref, and if you're really sure visual_object_destroy. > It would be nice to have some list of "deprecated" functions. Well, every _destroy and _free function except that of visual_object :) I haven't been really recording added and removed methods yet... You're right, we should do that a bit more active, but on the other side, we aren't yet stable API/ABI wise ;) > > To get this working, EVERY libvisual module needs a recompile. > > > > I haven't updated lvdisplay to this, Vitaly would you like to take > > a look at VisObjectifying lvdisplay ? > Done. Initial version. > > IMO everyting looks much better now! Thank you!, It looks really nice don't you think ?, I'm glad how it turned out. It also fixes many internal issues, like that we couldn't keep the config UI around after a plugin has been unloaded, now we can just refcount all the things involved and when the plugin unloads we still have our data. Cheers, Dennis |
|
From: Vitaly V. B. <vit...@uk...> - 2004-11-25 04:00:39
|
On Wed, 24 Nov 2004 00:21:17 +0100 Dennis Smit <sy...@yo...> wrote: > This way we provide a generalized ref counting interface. That > also supports complex object desctructors that are set at object > creation. With this change most of the other _free and _destroy > functions are history and object disposing should be done using > an visual_object_unref, and if you're really sure visual_object_destroy. It would be nice to have some list of "deprecated" functions. > To get this working, EVERY libvisual module needs a recompile. > > I haven't updated lvdisplay to this, Vitaly would you like to take > a look at VisObjectifying lvdisplay ? Done. Initial version. IMO everyting looks much better now! -- Vitaly GPG Key ID: F95A23B9 |
10 messages has been excluded from this view by a project administrator.
