From sjoeboo at sjoeboo.com Wed Jun 14 10:50:15 2006 From: sjoeboo at sjoeboo.com (sjoeboo) Date: Wed, 14 Jun 2006 7:50:15 -0700 Subject: totem and goom information... Message-ID: <5135b2d86e5568cedc7e8138809a3b9f@localhost> Good "morning" everyone, So, my (and what should be everyones) favorite music player for gnome, rhythmbox, has been on a steady march of advancement for the past few months, with a whole slew of new features comming about. One thing I though of recently is visualizations, and how ncie it would be to have at least one, possibly as a plugin. I know totem uses GOOM to do this, and was wondering what I might have to do in terms of gstreamer etc to have rhythmbox use it as well. I was looking around on the Totem site for a mailing list etc, but couldn't find anything. Does anyone know where I might find more info for something like this? Thanks, and keep up the great work. -- Matthew Nicholson sjoeboo at sjoeboo.com sjoeboo.com From doclivingston@gmail.com Wed Jun 7 10:49:16 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6DFBE3B0CC1 for ; Wed, 7 Jun 2006 10:49:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21939-01 for ; Wed, 7 Jun 2006 10:49:15 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.229]) by menubar.gnome.org (Postfix) with ESMTP id D14723B03C1 for ; Wed, 7 Jun 2006 10:49:14 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id 50so195010wri for ; Wed, 07 Jun 2006 07:49:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:reply-to:to:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=D3/oYUbzoxrxaC8A9PmKhslTLvhndfLfj1yY1UbjWdxPLOVTGGtYcu0ciGotAkdC9rpqkdcPnVZMxJ6dpbOroKn3+pabYkPihqGfxJAljTjii14F9PbbIilMLHmiNyw9SX693UyHiryeZOKfQoct7i10NaO3a8zimwOM5qcjmis= Received: by 10.65.232.13 with SMTP id j13mr502626qbr; Wed, 07 Jun 2006 07:49:14 -0700 (PDT) Received: from alyrion.local ( [144.139.19.99]) by mx.gmail.com with ESMTP id e14sm242982qba.2006.06.07.07.49.12; Wed, 07 Jun 2006 07:49:14 -0700 (PDT) From: "James \"Doc\" Livingston" To: gnome-multimedia@gnome.org Content-Type: text/plain Date: Thu, 08 Jun 2006 00:49:05 +1000 Message-Id: <1149691745.5417.19.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.309 tagged_above=-999 required=2 tests=[AWL=0.291, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.309 X-Spam-Level: Subject: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: doclivingston@gmail.com List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 14:49:16 -0000 G'day everyone, Currently various multi-media application behave differently when the "scrolling" (up/down arrow, page up/down mouse wheel) actions are performed on their seek slider. There have been bugs (at least 164351 and 330570) filed against several applications asking that they behave like others, and it would be good to have consistent behaviour. Essentially the questions is what should happen when the user performs these actions? Should the "up" actions seek forward in time, seek back in time, or do nothing? Currently Totem and Gnome Sound Recorder map "up" to seek forwards in time, Sound-Juicer and Rhythmbox map "up" to seek back in time, and Banshee and Muine don't seek when the user does this. Which is correct is a matter of debate, and when I started a discussion about this on #gnome-hackers (which obviously isn't filled with "average users") a while back, people seemed to be split roughly equally between the options. Some of the point for up=forwards are: * people associate up with increasing the time from the start Some of the point for up=backwards are: * people associate up with increasing the time remaining (only applicable if it's shown to the user) * people associate up with "going towards the start", like for documents/web pages Some of the point for taking no action: * these are "vertical" scroll events and the slider is horizontal, so should do nothing Regardless of which is generally considered "best", I think having it consistent between application is important. Cheers, James "Doc" Livingston -- [Request for the names of the kings who became Nazgul] Dashur, Daensir, Prantsur, Vicksinn, Comuet, Cupuid, Dondor, Blitsun, and Rodulf, Witch-King of Angmar. -- Joseph Michael Bay From hadess@hadess.net Wed Jun 7 10:58:17 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 067753B0272 for ; Wed, 7 Jun 2006 10:58:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22613-04 for ; Wed, 7 Jun 2006 10:58:16 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id EA5A23B03C4 for ; Wed, 7 Jun 2006 10:58:15 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57EwBfm003839; Wed, 7 Jun 2006 10:58:11 -0400 Received: from pobox.surrey.redhat.com (pobox.surrey.redhat.com [172.16.10.17]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57EwASg001552; Wed, 7 Jun 2006 10:58:10 -0400 Received: from bnocera.surrey.redhat.com (bnocera.surrey.redhat.com [172.16.10.53]) by pobox.surrey.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57Ew9om000601; Wed, 7 Jun 2006 15:58:09 +0100 From: Bastien Nocera To: doclivingston@gmail.com In-Reply-To: <1149691745.5417.19.camel@localhost.localdomain> References: <1149691745.5417.19.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8 Date: Wed, 07 Jun 2006 15:58:09 +0100 Message-Id: <1149692289.14668.24.camel@bnocera.surrey.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-27) Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.954 tagged_above=-999 required=2 tests=[AWL=-0.496, BAYES_00=-2.599, SPF_FAIL=1.142, SPF_HELO_PASS=-0.001] X-Spam-Score: -1.954 X-Spam-Level: Cc: gnome-multimedia@gnome.org Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 14:58:17 -0000 On Thu, 2006-06-08 at 00:49 +1000, James "Doc" Livingston wrote: > G'day everyone, > Essentially the questions is what should happen when the user performs > these actions? Should the "up" actions seek forward in time, seek back > in time, or do nothing? Same problem for the volume sliders by default. Obviously, I think that apps should seek forward in time with up, and backwards with down. And I also think that when scrolling down, the step should be shorter than when moving forward (because it makes it easier to find precise points in the timeline). Maybe we need to move things like the volume widget, and some "seek sliders" to a library like gnome-media? -- Bastien Nocera If I'm not challenged, I can do nothing. Maybe my next film will be in Japanese. -- Alejandro González Iñárittu From abockover@novell.com Wed Jun 7 11:08:04 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C6EB33B022D for ; Wed, 7 Jun 2006 11:08:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23164-09 for ; Wed, 7 Jun 2006 11:08:04 -0400 (EDT) Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.25.9.101]) by menubar.gnome.org (Postfix) with ESMTP id B3F5E3B0127 for ; Wed, 7 Jun 2006 11:08:03 -0400 (EDT) Received: from [192.168.0.101] (cpe-024-162-230-116.nc.res.rr.com [24.162.230.116]) by ms-smtp-02.southeast.rr.com (8.13.6/8.13.6) with ESMTP id k57F7xLC012187; Wed, 7 Jun 2006 11:07:59 -0400 (EDT) From: Aaron Bockover To: doclivingston@gmail.com In-Reply-To: <1149691745.5417.19.camel@localhost.localdomain> References: <1149691745.5417.19.camel@localhost.localdomain> Content-Type: text/plain Date: Wed, 07 Jun 2006 11:04:47 -0400 Message-Id: <1149692687.14205.10.camel@sledipus.rex> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.472 tagged_above=-999 required=2 tests=[AWL=-0.073, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2] X-Spam-Score: -2.472 X-Spam-Level: Cc: gnome-multimedia@gnome.org Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 15:08:05 -0000 On Thu, 2006-06-08 at 00:49 +1000, James "Doc" Livingston wrote: > Currently various multi-media application behave differently when the > "scrolling" (up/down arrow, page up/down mouse wheel) actions are > performed on their seek slider. There have been bugs (at least 164351 > and 330570) filed against several applications asking that they behave > like others, and it would be good to have consistent behaviour. Agreed. > Currently Totem and Gnome Sound Recorder map "up" to seek forwards in > time, Sound-Juicer and Rhythmbox map "up" to seek back in time, and > Banshee and Muine don't seek when the user does this. Banshee (and Muine?) seeks on CTRL+Left/Right. > Some of the point for up=forwards are: > * people associate up with increasing the time from the start > Time is usually displayed on the X axis... sliders for seeking are usually horizontal... so Up/Down keys for this mess with my mind > Some of the point for up=backwards are: > * people associate up with increasing the time remaining (only > applicable if it's shown to the user) > * people associate up with "going towards the start", like for > documents/web pages Again, for me it's more literal connection with visual objects... if I press the right arrow, I am scrolling my time graph "into the future." Volume is my Y axis. > Some of the point for taking no action: > * these are "vertical" scroll events and the slider is horizontal, so > should do nothing I don't think this is should be a no-action case. I think representations just should be "on-axis" (of course feelings are going to differ, this are just how I interpret position) >From a more technical (and possibly usability) standpoint, my objection to up/down is that it's used by and is more important to other widgets (our track views in Banshee/RB), meaning the slider needs focus for the keys to actually seek. In Banshee you can press CTRL+Left/Right anywhere and it seeks. Cheers, Aaron From rbultje@ronald.bitfreak.net Wed Jun 7 11:46:19 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3D92F3B04A2 for ; Wed, 7 Jun 2006 11:46:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26037-06 for ; Wed, 7 Jun 2006 11:46:15 -0400 (EDT) Received: from ms-smtp-01.rdc-nyc.rr.com (ms-smtp-01.rdc-nyc.rr.com [24.29.109.5]) by menubar.gnome.org (Postfix) with ESMTP id 8B1693B022D for ; Wed, 7 Jun 2006 11:46:15 -0400 (EDT) Received: from [192.168.0.103] (cpe-66-65-0-167.nyc.res.rr.com [66.65.0.167]) by ms-smtp-01.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id k57Fk2jY021579; Wed, 7 Jun 2006 11:46:13 -0400 (EDT) From: "Ronald S. Bultje" To: Bastien Nocera In-Reply-To: <1149692289.14668.24.camel@bnocera.surrey.redhat.com> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> Content-Type: text/plain Date: Wed, 07 Jun 2006 11:44:22 -0400 Message-Id: <1149695062.2855.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.561 tagged_above=-999 required=2 tests=[AWL=0.038, BAYES_00=-2.599] X-Spam-Score: -2.561 X-Spam-Level: Cc: gnome-multimedia@gnome.org Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 15:46:19 -0000 On Wed, 2006-06-07 at 15:58 +0100, Bastien Nocera wrote: > Maybe we need to move things like the volume widget, and some "seek > sliders" to a library like gnome-media? I would personally prefer libegg (or bacon, where the volume widget resides). I've never really seen gnome-media as a widget-library, but more like a bunch of applications and utilities. I totally don't mind each app making their own copy if such widgets, as long as they update their copy reasonably often. Cheers, Ronald From abockover@novell.com Wed Jun 7 11:58:56 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D43973B0411 for ; Wed, 7 Jun 2006 11:58:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26954-08 for ; Wed, 7 Jun 2006 11:58:56 -0400 (EDT) Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.25.9.101]) by menubar.gnome.org (Postfix) with ESMTP id 120B23B0D4B for ; Wed, 7 Jun 2006 11:58:56 -0400 (EDT) Received: from [192.168.0.101] (cpe-024-162-230-116.nc.res.rr.com [24.162.230.116]) by ms-smtp-02.southeast.rr.com (8.13.6/8.13.6) with ESMTP id k57FwrFL000910; Wed, 7 Jun 2006 11:58:54 -0400 (EDT) From: Aaron Bockover To: "Ronald S. Bultje" In-Reply-To: <1149695062.2855.2.camel@localhost.localdomain> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> <1149695062.2855.2.camel@localhost.localdomain> Content-Type: text/plain Date: Wed, 07 Jun 2006 11:55:41 -0400 Message-Id: <1149695742.15592.1.camel@sledipus.rex> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.473 tagged_above=-999 required=2 tests=[AWL=-0.074, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2] X-Spam-Score: -2.473 X-Spam-Level: Cc: gnome-multimedia@gnome.org, Bastien Nocera Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 15:58:57 -0000 On Wed, 2006-06-07 at 11:44 -0400, Ronald S. Bultje wrote: > On Wed, 2006-06-07 at 15:58 +0100, Bastien Nocera wrote: > > Maybe we need to move things like the volume widget, and some "seek > > sliders" to a library like gnome-media? > > I would personally prefer libegg (or bacon, where the volume widget > resides). I've never really seen gnome-media as a widget-library, but > more like a bunch of applications and utilities. > > I totally don't mind each app making their own copy if such widgets, as > long as they update their copy reasonably often. I agree here; bacon would probably be best if it were to be in a library, but I think applications providing copies is fine too. I wouldn't want to depend on bacon (or gnome-media) for a widget. --Aaron From hadess@hadess.net Wed Jun 7 12:02:02 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 001A03B0DF9 for ; Wed, 7 Jun 2006 12:02:02 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27399-05 for ; Wed, 7 Jun 2006 12:01:59 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 9822B3B0E10 for ; Wed, 7 Jun 2006 12:00:49 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57G0nE9001971; Wed, 7 Jun 2006 12:00:49 -0400 Received: from pobox.surrey.redhat.com (pobox.surrey.redhat.com [172.16.10.17]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57G0mZE021228; Wed, 7 Jun 2006 12:00:48 -0400 Received: from bnocera.surrey.redhat.com (bnocera.surrey.redhat.com [172.16.10.53]) by pobox.surrey.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57G0lTo006172; Wed, 7 Jun 2006 17:00:47 +0100 From: Bastien Nocera To: Aaron Bockover In-Reply-To: <1149695742.15592.1.camel@sledipus.rex> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> <1149695062.2855.2.camel@localhost.localdomain> <1149695742.15592.1.camel@sledipus.rex> Content-Type: text/plain Date: Wed, 07 Jun 2006 17:00:47 +0100 Message-Id: <1149696047.14668.35.camel@bnocera.surrey.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-27) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.953 tagged_above=-999 required=2 tests=[AWL=-0.495, BAYES_00=-2.599, SPF_FAIL=1.142, SPF_HELO_PASS=-0.001] X-Spam-Score: -1.953 X-Spam-Level: Cc: "Ronald S. Bultje" , gnome-multimedia@gnome.org Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 16:02:02 -0000 On Wed, 2006-06-07 at 11:55 -0400, Aaron Bockover wrote: > On Wed, 2006-06-07 at 11:44 -0400, Ronald S. Bultje wrote: > > On Wed, 2006-06-07 at 15:58 +0100, Bastien Nocera wrote: > > > Maybe we need to move things like the volume widget, and some "seek > > > sliders" to a library like gnome-media? > > > > I would personally prefer libegg (or bacon, where the volume widget > > resides). I've never really seen gnome-media as a widget-library, but > > more like a bunch of applications and utilities. > > > > I totally don't mind each app making their own copy if such widgets, as > > long as they update their copy reasonably often. > > I agree here; bacon would probably be best if it were to be in a > library, but I think applications providing copies is fine too. I > wouldn't want to depend on bacon (or gnome-media) for a widget. libbacon is a cut'n'paste library like libegg, so not a problem. -- Bastien Nocera Lucas has made a vacuous, boring, pretentious, retroactively destructive sequel. He has lost the plot. The man is a fool. -- Simon Pegg (on the Phantom Menace) From uraeus@linuxrising.org Fri Jun 9 10:13:15 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 91BCF3B01D8 for ; Fri, 9 Jun 2006 10:13:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29942-03 for ; Fri, 9 Jun 2006 10:13:14 -0400 (EDT) Received: from mx1.es6.egwn.net (server02.es6.egwn.net [195.10.6.12]) by menubar.gnome.org (Postfix) with ESMTP id E0C263B01BE for ; Fri, 9 Jun 2006 10:13:13 -0400 (EDT) Received: from [192.168.1.235] (core.fluendo.com [195.10.6.237]) by mx1.es6.egwn.net (Postfix) with ESMTP id 9E4AC4F81BC; Fri, 9 Jun 2006 16:13:11 +0200 (CEST) From: Christian Fredrik Kalager Schaller To: Bastien Nocera In-Reply-To: <1149696047.14668.35.camel@bnocera.surrey.redhat.com> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> <1149695062.2855.2.camel@localhost.localdomain> <1149695742.15592.1.camel@sledipus.rex> <1149696047.14668.35.camel@bnocera.surrey.redhat.com> Content-Type: text/plain Date: Fri, 09 Jun 2006 16:11:58 +0200 Message-Id: <1149862318.2356.36.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.397 tagged_above=-999 required=2 tests=[AWL=1.202, BAYES_00=-2.599] X-Spam-Score: -1.397 X-Spam-Level: Cc: "Ronald S. Bultje" , gnome-multimedia@gnome.org Subject: a general multimedia library - Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 14:13:15 -0000 Well the topic of having a multimedia widget library has been discussed multiple times and maybe now is the time to move on it? Currently there are multiple things I see that would be natural to put into such a library: a) the gconf schemas in gnome-media b) the playlist parser library in totem c) the seek sliders widgets mentioned here d) a simple to use GStreamer GTK+ video widget e) others things? Basically this library would/could contain things which are higher level our not directly in the scope of GStreamer. Or which is very GTK+/GNOME related. Christian On Wed, 2006-06-07 at 17:00 +0100, Bastien Nocera wrote: > On Wed, 2006-06-07 at 11:55 -0400, Aaron Bockover wrote: > > On Wed, 2006-06-07 at 11:44 -0400, Ronald S. Bultje wrote: > > > On Wed, 2006-06-07 at 15:58 +0100, Bastien Nocera wrote: > > > > Maybe we need to move things like the volume widget, and some "seek > > > > sliders" to a library like gnome-media? > > > > > > I would personally prefer libegg (or bacon, where the volume widget > > > resides). I've never really seen gnome-media as a widget-library, but > > > more like a bunch of applications and utilities. > > > > > > I totally don't mind each app making their own copy if such widgets, as > > > long as they update their copy reasonably often. > > > > I agree here; bacon would probably be best if it were to be in a > > library, but I think applications providing copies is fine too. I > > wouldn't want to depend on bacon (or gnome-media) for a widget. > > libbacon is a cut'n'paste library like libegg, so not a problem. > From rbultje@ronald.bitfreak.net Fri Jun 9 10:47:45 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B71663B0413 for ; Fri, 9 Jun 2006 10:47:45 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32342-10 for ; Fri, 9 Jun 2006 10:47:42 -0400 (EDT) Received: from ms-smtp-03.rdc-nyc.rr.com (ms-smtp-03.rdc-nyc.rr.com [24.29.109.7]) by menubar.gnome.org (Postfix) with ESMTP id 215673B0FF1 for ; Fri, 9 Jun 2006 10:47:42 -0400 (EDT) Received: from [192.168.0.103] (cpe-66-65-0-167.nyc.res.rr.com [66.65.0.167]) by ms-smtp-03.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id k59Eld9O019647; Fri, 9 Jun 2006 10:47:40 -0400 (EDT) From: "Ronald S. Bultje" To: Christian Fredrik Kalager Schaller In-Reply-To: <1149862318.2356.36.camel@localhost.localdomain> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> <1149695062.2855.2.camel@localhost.localdomain> <1149695742.15592.1.camel@sledipus.rex> <1149696047.14668.35.camel@bnocera.surrey.redhat.com> <1149862318.2356.36.camel@localhost.localdomain> Content-Type: text/plain Date: Fri, 09 Jun 2006 10:46:01 -0400 Message-Id: <1149864361.2869.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.563 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599] X-Spam-Score: -2.563 X-Spam-Level: Cc: gnome-multimedia@gnome.org, Bastien Nocera Subject: Re: a general multimedia library - Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 14:47:45 -0000 Hi, On Fri, 2006-06-09 at 16:11 +0200, Christian Fredrik Kalager Schaller wrote: > Well the topic of having a multimedia widget library has been discussed > multiple times and maybe now is the time to move on it? If someone believes that this would be useful and should be done, then that person should go ahead and do it. Ronald From thomas@apestaart.org Fri Jun 9 15:11:02 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 78FFA3B00E9 for ; Fri, 9 Jun 2006 15:11:02 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15077-08 for ; Fri, 9 Jun 2006 15:11:01 -0400 (EDT) Received: from mx1.es6.egwn.net (server02.es6.egwn.net [195.10.6.12]) by menubar.gnome.org (Postfix) with ESMTP id E94F03B0149 for ; Fri, 9 Jun 2006 15:11:00 -0400 (EDT) Received: from mx1.fr4.egwn.net (server07.fr4.egwn.net [62.39.85.77]) by mx1.es6.egwn.net (Postfix) with ESMTP id 0FC914F822C; Fri, 9 Jun 2006 21:10:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mx1.fr4.egwn.net (spiffy mail daemon) with ESMTP id CB4CC83BFD; Fri, 9 Jun 2006 21:10:47 +0200 (CEST) Received: from mx1.fr4.egwn.net ([127.0.0.1]) by localhost (server07.fr4.egwn.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22095-43; Fri, 9 Jun 2006 21:10:47 +0200 (CEST) Received: from thread.fluendo.lan (core.fluendo.com [195.10.6.237]) by mx1.fr4.egwn.net (spiffy mail daemon) with ESMTP id D8A3283BF8; Fri, 9 Jun 2006 21:10:46 +0200 (CEST) Received: from otto.amantes (thomas.fluendo.lan [192.168.1.10]) by thread.fluendo.lan (Postfix) with ESMTP id 8DDD1FE93; Fri, 9 Jun 2006 21:10:57 +0200 (CEST) Received: from otto.amantes (otto.amantes [127.0.0.1]) by otto.amantes (Postfix) with ESMTP id 9B95DEFC0D; Fri, 9 Jun 2006 21:11:00 +0200 (CEST) Content-Type: multipart/mixed; boundary="127.0.0.1.500.4863.1149880260.533.2" MIME-Version: 1.0 To: gstreamer-devel@lists.sourceforge.net, gstreamer-announce@lists.sourceforge.net, kde-multimedia@kde.org, gnome-multimedia@gnome.org Message-Id: <20060609191100.9B95DEFC0D@otto.amantes> Date: Fri, 9 Jun 2006 21:11:00 +0200 (CEST) From: thomas@apestaart.org X-Scanned: By amavis at egwn.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: Yes, score=2.06 tagged_above=-999 required=2 tests=[AWL=-1.482, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, MIME_BASE64_TEXT=1.885, NO_REAL_NAME=0.961, RCVD_IN_SBL=3.16] X-Spam-Score: 2.06 X-Spam-Level: ** X-Spam-Flag: YES Cc: Subject: RELEASE: GStreamer 0.10.7 'Soepeke, ik zie ou' X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 19:11:02 -0000 --127.0.0.1.500.4863.1149880260.533.2 Content-Type: text/plain This mail announces the release of GStreamer 0.10.7 'Soepeke, ik zie ou'. GStreamer is a streaming media framework that allows the construction of graphs of elements which operate on media data. Applications using this library can do anything from real-time sound processing over playing video to capturing audio, video, and even other types of media data. Its architecture allows for adding new data types or processing capabilities simply by installing new plug-ins. GStreamer is the core module, containing libraries, headers, the basic object hierarchy, and a set of media-agnostic core elements. For more information, see [http://gstreamer.freedesktop.org/modules/gstreamer.html] To file bugs, go to [http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer&component=gstreamer+%28core%29] --127.0.0.1.500.4863.1149880260.533.2 Content-Type: text/plain; name=RELEASE Content-Transfer-Encoding: base64 ClJlbGVhc2Ugbm90ZXMgZm9yIEdTdHJlYW1lcsKgMC4xMC43ICJTb2VwZWtlLCBpayB6aWUgb3Ui CiAgICAgICAgCgoKVGhlIEdTdHJlYW1lciB0ZWFtIGlzIHByb3VkIHRvIGFubm91bmNlIGEgbmV3 IHJlbGVhc2UKaW4gdGhlIDAuMTAueCBzdGFibGUgc2VyaWVzIG9mIHRoZQpjb3JlIG9mIHRoZSBH U3RyZWFtZXIgc3RyZWFtaW5nIG1lZGlhIGZyYW1ld29yay4KCgpUaGUgMC4xMC54IHNlcmllcyBp cyBhIHN0YWJsZSBzZXJpZXMgdGFyZ2V0ZWQgYXQgZW5kIHVzZXJzLgpJdCBpcyBub3QgQVBJIG9y IEFCSSBjb21wYXRpYmxlIHdpdGggdGhlIHN0YWJsZSAwLjgueCBzZXJpZXMuCkl0IGlzLCBob3dl dmVyLCBwYXJhbGxlbCBpbnN0YWxsYWJsZSB3aXRoIHRoZSAwLjgueCBzZXJpZXMuCgoKVGhlIDAu MTAueCBzZXJpZXMgaGFzIGJlZW4gcmV3b3JrZWQgZm9yIHRocmVhZHNhZmV0eS4gIEl0IGFsc28g ZmVhdHVyZXMKdmFyaW91cyBmZWF0dXJlIGFkZGl0aW9ucyBhbmQgZW5jaGFuY2VtZW50cy4KCgpU aGlzIG1vZHVsZSwgZ3N0cmVhbWVyLCBvbmx5IGNvbnRhaW5zIGNvcmUgZnVuY3Rpb25hbGl0eS4K Rm9yIGFjdHVhbCBtZWRpYSBwbGF5YmFjaywgeW91IHdpbGwgbmVlZCBvdGhlciBtb2R1bGVzLgoK Z3N0LXBsdWdpbnMtYmFzZQpjb250YWlucyBhIGJhc2ljIHNldCBvZiB3ZWxsLXN1cHBvcnRlZCBw bHVnLWlucwpnc3QtcGx1Z2lucy1nb29kCmNvbnRhaW5zIGEgc2V0IG9mIHdlbGwtc3VwcG9ydGVk IHBsdWctaW5zIHVuZGVyIG91ciBwcmVmZXJyZWQgbGljZW5zZQpnc3QtcGx1Z2lucy11Z2x5CmNv bnRhaW5zIGEgc2V0IG9mIHdlbGwtc3VwcG9ydGVkIHBsdWctaW5zLCBidXQgbWlnaHQgcG9zZSBw cm9ibGVtcyBmb3IKICAgIGRpc3RyaWJ1dG9ycwpnc3QtcGx1Z2lucy1iYWQKY29udGFpbnMgYSBz ZXQgb2YgbGVzcyBzdXBwb3J0ZWQgcGx1Zy1pbnMgdGhhdCBoYXZlbid0IHBhc3NlZCB0aGUKICAg IHJpZ29yb3VzIHF1YWxpdHkgdGVzdGluZyB3ZSBleHBlY3QKCgoKICAKRmVhdHVyZXMgb2YgdGhp cyByZWxlYXNlCiAgICAKICAgICAgKiBQYXJhbGxlbCBpbnN0YWxsYWJpbGl0eSB3aXRoIDAuOC54 IHNlcmllcwogICAgICAqIFRocmVhZHNhZmUgZGVzaWduIGFuZCBBUEkKICAgICAgKiBSZWdpc3Ry eSBjYWNoZSB1cGRhdGluZyBpcyBub3cgZG9uZSBpbiBhIGZvcmssIHNvIG5vIHBsdWdpbnMgYXJl IGxlZnQgb3BlbmVkCiAgICAgICogTmV3IHZlcnNpb24gb2YgZGF0YSBwcm90b2NvbCBub3cgc2Vy aWFsaXplcyBldmVudHMKICAgICAgKiBxdWV1ZSBmaXhlcwogICAgICAqIHdpbjMyIGZpeGVzCgpC dWdzIGZpeGVkIGluIHRoaXMgcmVsZWFzZQogICAgCiAgICAgICogMzM4MzM1IDogW3BhdGNoXSBt ZW1sZWFrIGluIGdzdC11dGlscy5jIChsZWFrIHBhZHMgZnJvbSBpdGVyYXRvcikKICAgICAgKiAz NDM1OTggOiB1bmRlZmluZWQgc3ltYm9sIGluIGNvcmVpbmRleGVycyB3aGVuIHVzaW5nIC0tZGlz YWJsZS1sb2EuLi4KICAgICAgKiAzMzY5MjkgOiBHc3RDb2xsZWN0UGFkcyBkb2VzIG5vdCBjbGVh ci9yZXNldCBzZWdtZW50IGluZm8gYWZ0ZXIgZmwuLi4KICAgICAgKiAzMzcxMDAgOiBbZmFrZXNp bmtdIGFkZCAiIHByZXJvbGwtaGFuZG9mZiAiIHNpZ25hbAogICAgICAqIDMzOTkxOCA6IEdzdFRh Z1NldHRlciBtZXJnZS1tb2RlIGRlc2NyaXB0aW9uIHVuY2xlYXIsIGFuZCBpbXBsZW1lbi4uLgog ICAgICAqIDM0MDUwMSA6IFtmaWxlc3JjXSBnaXZlIHByaW1hcnkgcmFuawogICAgICAqIDM0MTY2 MiA6IGdzdC1sYXVuY2ggcHJpbnRfdGFncygpIGZpeAogICAgICAqIDM0MjIzOCA6IEFQSTogZ3N0 X2VsZW1lbnRfc2Vla19zaW1wbGUKICAgICAgKiAzNDIzMjEgOiBHU1RfUVVFUllfUE9TSVRJT04g ZmFpbHMgaWYgR3N0QmFzZVNyYyBpbiBnZXRfcmFuZ2UgbW9kZQogICAgICAqIDM0Mjc3NyA6IHJl YnVpbGRpbmcgdGhlIHJlZ2lzdHJ5IGxlYXZlcyBhbGwgcGx1Z2lucyBpbiBtZW1vcnkKICAgICAg KiAzNDI4MjAgOiBnc3RuZXRjbGllbnRjbG9jay5jKDQ1Myk6IHNlcnZhZGRyIHVzZWQgYmVmb3Jl IHNldAogICAgICAqIDM0MzA1NyA6IGdzdC1sYXVuY2gtMC4xMCBzZWdmYXVsdHMgd2hlbiBwYXNz ZWQgZ3N0LXBsdWdpbi1wYXRoIGFuZC4uLgogICAgICAqIDM0MzM0MSA6IFtBUEldIGFkZCBHU1Rf VEFHX1BSRVZJRVdfSU1BR0UKICAgICAgKiAzNDM4MjcgOiBsZWFrIGluIGdzdF9pbmRleF9ndHlw ZV9yZXNvbHZlcgogICAgICAqIDM0MzkyOSA6IFVzZSBvZiAvLyBpbiBwdWJsaWMgaGVhZGVyCiAg ICAgICogMzQzOTg4IDogZGF0YSBwcm90b2NvbCBuZWVkcyBleHRlbmRpbmcgdG8gaGFuZGxlIGV2 ZW50cyBiZXR0ZXIKICAgICAgKiAzNDE0NzkgOiBUb28gbWFueSBwbHVnaW5zIGxvYWRlZCBldmVu IGZvciB1cC10by1kYXRlIHJlZ2lzdHJ5CiAgICAgICogMzQzMzM0IDogR3N0Q29sbGVjdFBhZHMg dGVzdHN1aXRlIGFuZCBmaXhlcwogICAgICAqIDM0MzUzOCA6IEdzdENvbGxlY3RQYWRzIGRvZXNu J3QgcmVzZXQgRU9TIGZpZWxkcyB3aGVuIHN0b3BwZWQKCkFQSSBjaGFuZ2VkIGluIHRoaXMgcmVs ZWFzZQogICAgIAoKLSBBUEkgYWRkaXRpb25zOgogICAgCiogZ3N0X2VsZW1lbnRfc2Vla19zaW1w bGUoKQoqIEdTVF9GTE9XX0NVU1RPTV9TVUNDRVNTCiogR1NUX0ZMT1dfQ1VTVE9NX0VSUk9SCiog R1NUX0ZMT1dfSVNfU1VDQ0VTUwoqIGdzdF9jb2xsZWN0X3BhZHNfc2V0X2ZsdXNoaW5nKCkKKiBH U1RfVEFHX1BSRVZJRVdfSU1BR0UKKiBnc3RfZHBfY3JjKCkKKiBHc3REUFBhY2tldGl6ZXIKKiBH c3REUFZlcnNpb24KKiBHc3RGYWtlU2luazo6cHJlcm9sbC1oYW5kb2ZmCiogR3N0RmFrZVNpbms6 OnVzZS1tbWFwCgpEb3dubG9hZAoKWW91IGNhbiBmaW5kIHNvdXJjZSByZWxlYXNlcyBvZiBnc3Ry ZWFtZXIgaW4gdGhlIGRvd25sb2FkIGRpcmVjdG9yeToKaHR0cDovL2dzdHJlYW1lci5mcmVlZGVz a3RvcC5vcmcvc3JjL2dzdHJlYW1lci8KCkdTdHJlYW1lciBIb21lcGFnZQoKTW9yZSBkZXRhaWxz IGNhbiBiZSBmb3VuZCBvbiB0aGUgcHJvamVjdCdzIHdlYnNpdGU6Cmh0dHA6Ly9nc3RyZWFtZXIu ZnJlZWRlc2t0b3Aub3JnLwoKU3VwcG9ydCBhbmQgQnVncwoKV2UgdXNlIEdOT01FJ3MgYnVnemls bGEgZm9yIGJ1ZyByZXBvcnRzIGFuZCBmZWF0dXJlIHJlcXVlc3RzOgpodHRwOi8vYnVnemlsbGEu Z25vbWUub3JnL2VudGVyX2J1Zy5jZ2k/cHJvZHVjdD1HU3RyZWFtZXIKCkRldmVsb3BlcnMKCkNW UyBpcyBob3N0ZWQgb24gY3ZzLmZyZWVkZXNrdG9wLm9yZy4KQWxsIGNvZGUgaXMgaW4gQ1ZTIGFu ZCBjYW4gYmUgY2hlY2tlZCBvdXQgZnJvbSB0aGVyZS4KSW50ZXJlc3RlZCBkZXZlbG9wZXJzIG9m IHRoZSBjb3JlIGxpYnJhcnksIHBsdWctaW5zLCBhbmQgYXBwbGljYXRpb25zIHNob3VsZApzdWJz Y3JpYmUgdG8gdGhlIGdzdHJlYW1lci1kZXZlbCBsaXN0LiBJZiB0aGVyZSBpcyBzdWZmaWNpZW50 IGludGVyZXN0IHdlCndpbGwgY3JlYXRlIG1vcmUgbGlzdHMgYXMgbmVjZXNzYXJ5LgoKICAgICAg ICAKQXBwbGljYXRpb25zCgpBcHBsaWNhdGlvbnMgcG9ydGVkIHRvIEdTdHJlYW1lciAwLjEwIGlu Y2x1ZGUgVG90ZW0sIFJoeXRobUJveCwgU291bmQtSnVpY2VyLApHbm9tZSBNZWRpYSwgRmx1bW90 aW9uLCBBbWFyb2ssIEphbWJvcmVlLCBQaXRpdmksIElzdGFuYnVsLCBBbm5vQW1wLCBFbGlzYSwg YW5kIG90aGVycy4KTGV0IHVzIGtub3cgaWYgeW91IHdhbnQgdG8gYmUgYWRkZWQgdG8gdGhpcyBs aXN0LgoKICAKQ29udHJpYnV0b3JzIHRvIHRoaXMgcmVsZWFzZQogICAgCiAgICAgICogQWxlc3Nh bmRybyBEZWNpbmEKICAgICAgKiBFZHdhcmQgSGVydmV5CiAgICAgICogSmFuIFNjaG1pZHQKICAg ICAgKiBKdWxpZW4gTW91dHRlCiAgICAgICogTHV0eiBNdWVsbGVyCiAgICAgICogTWFyayBOYXV3 ZWxhZXJ0cwogICAgICAqIE1pY2hhZWwgU21pdGgKICAgICAgKiBTZWJhc3RpZW4gTW91dHRlCiAg ICAgICogU3RlZmFuIEtvc3QKICAgICAgKiBUaG9tYXMgVmFuZGVyIFN0aWNoZWxlCiAgICAgICog VGltLVBoaWxpcHAgTcO8bGxlcgogICAgICAqIFdpbSBUYXltYW5zCiAgICAgICogWmFoZWVyIEFi YmFzIE1lcmFsaQrCoA== --127.0.0.1.500.4863.1149880260.533.2-- From thomas@apestaart.org Fri Jun 9 15:11:49 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5C75C3B00E9 for ; Fri, 9 Jun 2006 15:11:49 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15136-05 for ; Fri, 9 Jun 2006 15:11:48 -0400 (EDT) Received: from mx1.es6.egwn.net (server02.es6.egwn.net [195.10.6.12]) by menubar.gnome.org (Postfix) with ESMTP id 0A9E03B0149 for ; Fri, 9 Jun 2006 15:11:47 -0400 (EDT) Received: from mx1.fr4.egwn.net (server07.fr4.egwn.net [62.39.85.77]) by mx1.es6.egwn.net (Postfix) with ESMTP id 5C5134F822C; Fri, 9 Jun 2006 21:11:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mx1.fr4.egwn.net (spiffy mail daemon) with ESMTP id 20D9883BFD; Fri, 9 Jun 2006 21:11:35 +0200 (CEST) Received: from mx1.fr4.egwn.net ([127.0.0.1]) by localhost (server07.fr4.egwn.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23574-43; Fri, 9 Jun 2006 21:11:34 +0200 (CEST) Received: from thread.fluendo.lan (core.fluendo.com [195.10.6.237]) by mx1.fr4.egwn.net (spiffy mail daemon) with ESMTP id 33DE383BF8; Fri, 9 Jun 2006 21:11:34 +0200 (CEST) Received: from otto.amantes (thomas.fluendo.lan [192.168.1.10]) by thread.fluendo.lan (Postfix) with ESMTP id 071AFFE93; Fri, 9 Jun 2006 21:11:45 +0200 (CEST) Received: from otto.amantes (otto.amantes [127.0.0.1]) by otto.amantes (Postfix) with ESMTP id 35F55EFC0D; Fri, 9 Jun 2006 21:11:48 +0200 (CEST) Content-Type: multipart/mixed; boundary="127.0.0.1.500.5548.1149880308.216.2" MIME-Version: 1.0 To: gstreamer-devel@lists.sourceforge.net, gstreamer-announce@lists.sourceforge.net, kde-multimedia@kde.org, gnome-multimedia@gnome.org Message-Id: <20060609191148.35F55EFC0D@otto.amantes> Date: Fri, 9 Jun 2006 21:11:48 +0200 (CEST) From: thomas@apestaart.org X-Scanned: By amavis at egwn.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: Yes, score=2.198 tagged_above=-999 required=2 tests=[AWL=-1.575, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, MIME_BASE64_TEXT=1.885, NO_REAL_NAME=0.961, RCVD_IN_SBL=3.16, TW_EG=0.077, TW_EV=0.077, TW_FD=0.077] X-Spam-Score: 2.198 X-Spam-Level: ** X-Spam-Flag: YES Cc: Subject: RELEASE: GStreamer Base Plug-ins 0.10.8 'Moar gij zie mij nie' X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 19:11:49 -0000 --127.0.0.1.500.5548.1149880308.216.2 Content-Type: text/plain This mail announces the release of GStreamer Base Plug-ins 0.10.8 'Moar gij zie mij nie'. GStreamer Base Plug-ins is a well-groomed and well-maintained collection of GStreamer plug-ins and elements, spanning the range of possible types of elements one would want to write for GStreamer. It also contains helper libraries and base classes useful for writing elements. A wide range of video and audio decoders, encoders, and filters are included. For more information, see [http://gstreamer.freedesktop.org/modules/gst-plugins-base.html] To file bugs, go to [http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer&component=gst-plugins-base] --127.0.0.1.500.5548.1149880308.216.2 Content-Type: text/plain; name=RELEASE Content-Transfer-Encoding: base64 ClJlbGVhc2Ugbm90ZXMgZm9yIEdTdHJlYW1lciBCYXNlIFBsdWctaW5zwqAwLjEwLjggIk1vYXIg Z2lqIHppZXQgbWlqIG5pZSIKICAgICAgICAKCgpUaGUgR1N0cmVhbWVyIHRlYW0gaXMgcHJvdWQg dG8gYW5ub3VuY2UgYSBuZXcgcmVsZWFzZQppbiB0aGUgMC4xMC54IHN0YWJsZSBzZXJpZXMgb2Yg dGhlCkdTdHJlYW1lciBCYXNlIFBsdWctaW5zLgoKClRoZSAwLjEwLnggc2VyaWVzIGlzIGEgc3Rh YmxlIHNlcmllcyB0YXJnZXRlZCBhdCBlbmQgdXNlcnMuCkl0IGlzIG5vdCBBUEkgb3IgQUJJIGNv bXBhdGlibGUgd2l0aCB0aGUgc3RhYmxlIDAuOC54IHNlcmllcy4KSXQgaXMsIGhvd2V2ZXIsIHBh cmFsbGVsIGluc3RhbGxhYmxlIHdpdGggdGhlIDAuOC54IHNlcmllcy4KCgoKVGhpcyBtb2R1bGUg Y29udGFpbnMgYSBzZXQgb2YgcmVmZXJlbmNlIHBsdWdpbnMsIGJhc2UgY2xhc3NlcyBmb3Igb3Ro ZXIKcGx1Z2lucywgYW5kIGhlbHBlciBsaWJyYXJpZXMuCgpUaGlzIG1vZHVsZSBpcyBrZXB0IHVw LXRvLWRhdGUgdG9nZXRoZXIgd2l0aCB0aGUgY29yZSBkZXZlbG9wbWVudHMuICBFbGVtZW50Cndy aXRlcnMgc2hvdWxkIGxvb2sgYXQgdGhlIGVsZW1lbnRzIGluIHRoaXMgbW9kdWxlIGFzIGEgcmVm ZXJlbmNlIGZvcgp0aGVpciBkZXZlbG9wbWVudC4KClRoaXMgbW9kdWxlIGNvbnRhaW5zIGVsZW1l bnRzIGZvciwgYW1vbmcgb3RoZXJzOgoKICBkZXZpY2UgcGx1Z2luczogeCh2KWltYWdlc2luaywg YWxzYSwgdjRsc3JjLCBjZHBhcmFub2lhCiAgY29udGFpbmVyczogb2dnCiAgY29kZWNzOiB2b3Ji aXMsIHRoZW9yYQogIHRleHQ6IHRleHRvdmVybGF5LCBzdWJwYXJzZQogIHNvdXJjZXM6IGF1ZGlv dGVzdHNyYywgdmlkZW90ZXN0c3JjLCBnbm9tZXZmc3NyYwogIG5ldHdvcms6IHRjcAogIHR5cGVm aW5kCiAgYXVkaW8gcHJvY2Vzc2luZzogYXVkaW9jb252ZXJ0LCBhZGRlciwgYXVkaW9yYXRlLCBh dWRpb3NjYWxlLCB2b2x1bWUKICB2aXN1YWxpc2F0aW9uOiBsaWJ2aXN1YWwKICB2aWRlbyBwcm9j ZXNzaW5nOiBmZm1wZWdjb2xvcnNwYWNlCiAgYWdncmVnYXRlIGVsZW1lbnRzOiBkZWNvZGViaW4s IHBsYXliaW4KCgpPdGhlciBtb2R1bGVzIGNvbnRhaW5pbmcgcGx1Zy1pbnMgYXJlOgoKCmdzdC1w bHVnaW5zLWdvb2QKY29udGFpbnMgYSBzZXQgb2Ygd2VsbC1zdXBwb3J0ZWQgcGx1Zy1pbnMgdW5k ZXIgb3VyIHByZWZlcnJlZCBsaWNlbnNlCmdzdC1wbHVnaW5zLXVnbHkKY29udGFpbnMgYSBzZXQg b2Ygd2VsbC1zdXBwb3J0ZWQgcGx1Zy1pbnMsIGJ1dCBtaWdodCBwb3NlIHByb2JsZW1zIGZvcgog ICAgZGlzdHJpYnV0b3JzCmdzdC1wbHVnaW5zLWJhZApjb250YWlucyBhIHNldCBvZiBsZXNzIHN1 cHBvcnRlZCBwbHVnLWlucyB0aGF0IGhhdmVuJ3QgcGFzc2VkIHRoZQogICAgcmlnb3JvdXMgcXVh bGl0eSB0ZXN0aW5nIHdlIGV4cGVjdAoKCgogIApGZWF0dXJlcyBvZiB0aGlzIHJlbGVhc2UKICAg IAogICAgICAqIFBhcmFsbGVsIGluc3RhbGxhYmlsaXR5IHdpdGggMC44Lnggc2VyaWVzCiAgICAg ICogVGhyZWFkc2FmZSBkZXNpZ24gYW5kIEFQSQogICAgICAqIGFsc2FzaW5rIHByb2JpbmcgZml4 ZXMKICAgICAgKiB4dmltYWdlc2luayBlcnJvciByZXBvcnRpbmcgZml4ZXMKICAgICAgKiBzdWJ0 aXRsZSBmaXhlcwogICAgICAqIGFkZGVyIGZpeGVzCiAgICAgICogdm9yYmlzIG11bHRpY2hhbm5l bCBmaXhlcwogICAgICAqIG11bHRpZmRzaW5rIHN0cmVhbWhlYWRlciBmaXhlcwoKQnVncyBmaXhl ZCBpbiB0aGlzIHJlbGVhc2UKICAgIAogICAgICAqIDE2OTkzNiA6IFtzdWJwYXJzZV0gc3VwcG9y dCBmb3IgU0FNSSBzdWJ0aXRsZXMKICAgICAgKiAzMTUzMTIgOiBHc3RyZWFtZXIgWHYgdXNlcyBS R0IgaW5zdGVhZCBvZiBZVVYuCiAgICAgICogMzM0MDAyIDogdmlkZW80bGludXggc2hvdWxkbid0 IGRlcGVuZCBvbiBYIGluIGNvbmZpZ3VyZSBzY3JpcHQKICAgICAgKiAzMzY4ODEgOiBbbGlidmlz dWFsXSBhZGRpdGlvbmFsIHN1cHBvcnQgZm9yIGxpYnZpc3VhbC0wLjQKICAgICAgKiAzMzc1NDQg OiBbeHZpbWFnZXNpbmtdIEludGVybmFsIEVycm9yIHdoZW4gaW1hZ2UgaXMgdG9vIGxhcmdlCiAg ICAgICogMzM5NTIwIDogW3N1YnBhcnNlXSBhZGQgIiBlbmNvZGluZyAiIHByb3BlcnR5CiAgICAg ICogMzQwOTA5IDogW2Fsc2FzaW5rXSBjYW4ndCBlbmFibGUgc3BkaWYgb3V0cHV0CiAgICAgICog MzQxNTQyIDogc29tZSB1c2VycyBoYXZlIGFuIGFzc2VydGlvbiBmYWlsZWQ6IChHU1RfVklERU9f U0lOS19XSURULi4uCiAgICAgICogMzQxNTYyIDogYXVkaW9jb252ZXJ0IGRvZXNuJ3QgbGlzdCBm b3JtYXRzIGluIG9yZGVyIG9mIHByZWZlcmVuY2UKICAgICAgKiAzNDE2OTYgOiBhdWRpb2NvbnZl cnQgY3Jhc2hlcyBpZiBjb252ZXJ0aW5nIGZyb20gYSBmb3JtYXQgd2l0aCBubyAuLi4KICAgICAg KiAzNDE3MTkgOiBiaXNlY3Rpb24gYWxnb3JpdGhtIGluIG9nZyBkb2Vzbid0IGJpc2VjdCBpbiBz b21lIGNhc2VzCiAgICAgICogMzQxNzMyIDogW2Fsc2FzaW5rXSBkb2Vzbid0IHF1ZXJ5IHN1cHBv cnRlZCBzYW1wbGUgcmF0ZXMKICAgICAgKiAzNDE4NzMgOiBbYWxzYXNpbmtdIG1pbm9yIG1lbW9y eSBsZWFrLCB1c2VzIHVucHJvdGVjdGVkIHN0YXRpYyB2YXIuLi4KICAgICAgKiAzNDIxNDMgOiBb c3VicGFyc2VdIHNhbWkgcGFyc2VyIG5lZWRzIHRvIGVzY2FwZSBjaGFyYWN0ZXJzCiAgICAgICog MzQyMTgxIDogW2Fsc2FdIGFkZCBwcm9wZXJ0eSBwcm9iZSBpbnRlcmZhY2UgdG8gYWxzYXNpbmsg YW5kIGFsc2FzcmMKICAgICAgKiAzNDIyNjggOiBbcGxheWJpbl0gYWRkICdzdWJ0aXRsZS1lbmNv ZGluZycgcHJvcGVydHkKICAgICAgKiAzNDIzNDUgOiBbcmlmZl0gRWxlcGhhbnQncyBEcmVhbSBB VkkgZG9lcyBub3QgcGxheSwgSlVOSyBjaHVuayBiZWYuLi4KICAgICAgKiAzNDI1NjYgOiBCdWls ZGluZyB3aXRob3V0IEdUSysgZmFpbHMKICAgICAgKiAzNDMzOTcgOiBILjI2NC9BQUMgbW92aWUg ZGVhZGxvY2tzIHdpdGggdG90ZW0gaW4gZ3N0cmVhbWVyIGNvZGUsIHAuLi4KICAgICAgKiAzMzk5 MzUgOiBbYWRkZXJdIGRlYWQtbG9ja3Mgd2hlbiBhZGRpbmcgc2luayBwYWRzIGluIFBBVVNFRCBz dGF0ZQoKRG93bmxvYWQKCllvdSBjYW4gZmluZCBzb3VyY2UgcmVsZWFzZXMgb2YgZ3N0LXBsdWdp bnMtYmFzZSBpbiB0aGUgZG93bmxvYWQgZGlyZWN0b3J5OgpodHRwOi8vZ3N0cmVhbWVyLmZyZWVk ZXNrdG9wLm9yZy9zcmMvZ3N0LXBsdWdpbnMtYmFzZS8KCkdTdHJlYW1lciBIb21lcGFnZQoKTW9y ZSBkZXRhaWxzIGNhbiBiZSBmb3VuZCBvbiB0aGUgcHJvamVjdCdzIHdlYnNpdGU6Cmh0dHA6Ly9n c3RyZWFtZXIuZnJlZWRlc2t0b3Aub3JnLwoKU3VwcG9ydCBhbmQgQnVncwoKV2UgdXNlIEdOT01F J3MgYnVnemlsbGEgZm9yIGJ1ZyByZXBvcnRzIGFuZCBmZWF0dXJlIHJlcXVlc3RzOgpodHRwOi8v YnVnemlsbGEuZ25vbWUub3JnL2VudGVyX2J1Zy5jZ2k/cHJvZHVjdD1HU3RyZWFtZXIKCkRldmVs b3BlcnMKCkNWUyBpcyBob3N0ZWQgb24gY3ZzLmZyZWVkZXNrdG9wLm9yZy4KQWxsIGNvZGUgaXMg aW4gQ1ZTIGFuZCBjYW4gYmUgY2hlY2tlZCBvdXQgZnJvbSB0aGVyZS4KSW50ZXJlc3RlZCBkZXZl bG9wZXJzIG9mIHRoZSBjb3JlIGxpYnJhcnksIHBsdWctaW5zLCBhbmQgYXBwbGljYXRpb25zIHNo b3VsZApzdWJzY3JpYmUgdG8gdGhlIGdzdHJlYW1lci1kZXZlbCBsaXN0LiBJZiB0aGVyZSBpcyBz dWZmaWNpZW50IGludGVyZXN0IHdlCndpbGwgY3JlYXRlIG1vcmUgbGlzdHMgYXMgbmVjZXNzYXJ5 LgoKICAgICAgICAKQXBwbGljYXRpb25zCiAgCkNvbnRyaWJ1dG9ycyB0byB0aGlzIHJlbGVhc2UK ICAgIAogICAgICAqIEVkd2FyZCBIZXJ2ZXkKICAgICAgKiBKYW4gU2NobWlkdAogICAgICAqIEp1 bGllbiBNb3V0dGUKICAgICAgKiBNYXJ0aW4gU3p1bGVja2kKICAgICAgKiBNaWNoYWVsIFNtaXRo CiAgICAgICogUGV0ZXIgS2plbGxlcnN0ZWR0CiAgICAgICogU2ViYXN0aWVuIE1vdXR0ZQogICAg ICAqIFN0ZWZhbiBLb3N0CiAgICAgICogVGhvbWFzIFZhbmRlciBTdGljaGVsZQogICAgICAqIFRp bS1QaGlsaXBwIE3DvGxsZXIKICAgICAgKiBXaW0gVGF5bWFucwogICAgICAqIFlvdW5nLUhvIENo YQogICAgICAqIFphaGVlciBBYmJhcyBNZXJhbGkKwqA= --127.0.0.1.500.5548.1149880308.216.2-- From thomas@apestaart.org Sat Jun 10 13:20:04 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 77ABD3B0280 for ; Sat, 10 Jun 2006 13:20:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16793-02 for ; Sat, 10 Jun 2006 13:20:03 -0400 (EDT) Received: from core.fluendo.com (core.fluendo.com [195.10.6.237]) by menubar.gnome.org (Postfix) with ESMTP id E5DCC3B01B8 for ; Sat, 10 Jun 2006 13:20:02 -0400 (EDT) Received: from onzenbak.amantes (70.Red-81-38-184.dynamicIP.rima-tde.net [81.38.184.70]) by core.fluendo.com (Postfix) with ESMTP id 205F71DC; Sat, 10 Jun 2006 19:20:01 +0200 (CEST) Received: from otto.amantes (otto.amantes [192.168.1.10]) by onzenbak.amantes (Postfix) with ESMTP id 4680720476; Sat, 10 Jun 2006 19:19:58 +0200 (CEST) Received: from otto.amantes (otto.amantes [127.0.0.1]) by otto.amantes (Postfix) with ESMTP id 3B641EFC0D; Sat, 10 Jun 2006 19:20:01 +0200 (CEST) Content-Type: multipart/mixed; boundary="127.0.0.1.500.6078.1149960001.170.2" MIME-Version: 1.0 To: gstreamer-devel@lists.sourceforge.net, gstreamer-announce@lists.sourceforge.net, kde-multimedia@kde.org, gnome-multimedia@gnome.org Message-Id: <20060610172001.3B641EFC0D@otto.amantes> Date: Sat, 10 Jun 2006 19:20:01 +0200 (CEST) From: thomas@apestaart.org X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.991 tagged_above=-999 required=2 tests=[AWL=-1.373, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, MIME_BASE64_TEXT=1.885, NO_REAL_NAME=0.961] X-Spam-Score: -0.991 X-Spam-Level: Cc: Subject: RELEASE: GStreamer 0.10.8 'Soepeke, ik zie ou nog altijd nie' X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 17:20:04 -0000 --127.0.0.1.500.6078.1149960001.170.2 Content-Type: text/plain This mail announces the release of GStreamer 0.10.8 'Soepeke, ik zie ou nog altijd nie'. GStreamer is a streaming media framework that allows the construction of graphs of elements which operate on media data. Applications using this library can do anything from real-time sound processing over playing video to capturing audio, video, and even other types of media data. Its architecture allows for adding new data types or processing capabilities simply by installing new plug-ins. GStreamer is the core module, containing libraries, headers, the basic object hierarchy, and a set of media-agnostic core elements. For more information, see [http://gstreamer.freedesktop.org/modules/gstreamer.html] To file bugs, go to [http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer&component=gstreamer+%28core%29] --127.0.0.1.500.6078.1149960001.170.2 Content-Type: text/plain; name=RELEASE Content-Transfer-Encoding: base64 ClJlbGVhc2Ugbm90ZXMgZm9yIEdTdHJlYW1lcsKgMC4xMC44ICJTb2VwZWtlLCBpayB6aWUgb3Ug bm9nIGFsdGlqZCBuaWUiCiAgICAgICAgCgoKVGhlIEdTdHJlYW1lciB0ZWFtIGlzIHByb3VkIHRv IGFubm91bmNlIGEgbmV3IHJlbGVhc2UKaW4gdGhlIDAuMTAueCBzdGFibGUgc2VyaWVzIG9mIHRo ZQpjb3JlIG9mIHRoZSBHU3RyZWFtZXIgc3RyZWFtaW5nIG1lZGlhIGZyYW1ld29yay4KCgpUaGUg MC4xMC54IHNlcmllcyBpcyBhIHN0YWJsZSBzZXJpZXMgdGFyZ2V0ZWQgYXQgZW5kIHVzZXJzLgpJ dCBpcyBub3QgQVBJIG9yIEFCSSBjb21wYXRpYmxlIHdpdGggdGhlIHN0YWJsZSAwLjgueCBzZXJp ZXMuCkl0IGlzLCBob3dldmVyLCBwYXJhbGxlbCBpbnN0YWxsYWJsZSB3aXRoIHRoZSAwLjgueCBz ZXJpZXMuCgoKVGhlIDAuMTAueCBzZXJpZXMgaGFzIGJlZW4gcmV3b3JrZWQgZm9yIHRocmVhZHNh ZmV0eS4gIEl0IGFsc28gZmVhdHVyZXMKdmFyaW91cyBmZWF0dXJlIGFkZGl0aW9ucyBhbmQgZW5j aGFuY2VtZW50cy4KCgpUaGlzIG1vZHVsZSwgZ3N0cmVhbWVyLCBvbmx5IGNvbnRhaW5zIGNvcmUg ZnVuY3Rpb25hbGl0eS4KRm9yIGFjdHVhbCBtZWRpYSBwbGF5YmFjaywgeW91IHdpbGwgbmVlZCBv dGhlciBtb2R1bGVzLgoKZ3N0LXBsdWdpbnMtYmFzZQpjb250YWlucyBhIGJhc2ljIHNldCBvZiB3 ZWxsLXN1cHBvcnRlZCBwbHVnLWlucwpnc3QtcGx1Z2lucy1nb29kCmNvbnRhaW5zIGEgc2V0IG9m IHdlbGwtc3VwcG9ydGVkIHBsdWctaW5zIHVuZGVyIG91ciBwcmVmZXJyZWQgbGljZW5zZQpnc3Qt cGx1Z2lucy11Z2x5CmNvbnRhaW5zIGEgc2V0IG9mIHdlbGwtc3VwcG9ydGVkIHBsdWctaW5zLCBi dXQgbWlnaHQgcG9zZSBwcm9ibGVtcyBmb3IKICAgIGRpc3RyaWJ1dG9ycwpnc3QtcGx1Z2lucy1i YWQKY29udGFpbnMgYSBzZXQgb2YgbGVzcyBzdXBwb3J0ZWQgcGx1Zy1pbnMgdGhhdCBoYXZlbid0 IHBhc3NlZCB0aGUKICAgIHJpZ29yb3VzIHF1YWxpdHkgdGVzdGluZyB3ZSBleHBlY3QKCgoKICAK RmVhdHVyZXMgb2YgdGhpcyByZWxlYXNlCiAgICAKICAgICAgKiBQYXJhbGxlbCBpbnN0YWxsYWJp bGl0eSB3aXRoIDAuOC54IHNlcmllcwogICAgICAqIFRocmVhZHNhZmUgZGVzaWduIGFuZCBBUEkK ICAgICAgKiBJbXBvcnRhbnQgZml4IGZvciByZWdpc3RyeSB1cGRhdGUgY2F1c2luZyBhcHBsZXRz IG5vdCB0byBsb2FkCgpCdWdzIGZpeGVkIGluIHRoaXMgcmVsZWFzZQogICAgCiAgICAgICogMzQ0 NDc0IDogR25vbWUgTWl4ZXIgQXBwbGV0IGRvZXNuJ3Qgd2FudCB0byBsb2FkCgpEb3dubG9hZAoK WW91IGNhbiBmaW5kIHNvdXJjZSByZWxlYXNlcyBvZiBnc3RyZWFtZXIgaW4gdGhlIGRvd25sb2Fk IGRpcmVjdG9yeToKaHR0cDovL2dzdHJlYW1lci5mcmVlZGVza3RvcC5vcmcvc3JjL2dzdHJlYW1l ci8KCkdTdHJlYW1lciBIb21lcGFnZQoKTW9yZSBkZXRhaWxzIGNhbiBiZSBmb3VuZCBvbiB0aGUg cHJvamVjdCdzIHdlYnNpdGU6Cmh0dHA6Ly9nc3RyZWFtZXIuZnJlZWRlc2t0b3Aub3JnLwoKU3Vw cG9ydCBhbmQgQnVncwoKV2UgdXNlIEdOT01FJ3MgYnVnemlsbGEgZm9yIGJ1ZyByZXBvcnRzIGFu ZCBmZWF0dXJlIHJlcXVlc3RzOgpodHRwOi8vYnVnemlsbGEuZ25vbWUub3JnL2VudGVyX2J1Zy5j Z2k/cHJvZHVjdD1HU3RyZWFtZXIKCkRldmVsb3BlcnMKCkNWUyBpcyBob3N0ZWQgb24gY3ZzLmZy ZWVkZXNrdG9wLm9yZy4KQWxsIGNvZGUgaXMgaW4gQ1ZTIGFuZCBjYW4gYmUgY2hlY2tlZCBvdXQg ZnJvbSB0aGVyZS4KSW50ZXJlc3RlZCBkZXZlbG9wZXJzIG9mIHRoZSBjb3JlIGxpYnJhcnksIHBs dWctaW5zLCBhbmQgYXBwbGljYXRpb25zIHNob3VsZApzdWJzY3JpYmUgdG8gdGhlIGdzdHJlYW1l ci1kZXZlbCBsaXN0LiBJZiB0aGVyZSBpcyBzdWZmaWNpZW50IGludGVyZXN0IHdlCndpbGwgY3Jl YXRlIG1vcmUgbGlzdHMgYXMgbmVjZXNzYXJ5LgoKICAgICAgICAKQXBwbGljYXRpb25zCgpBcHBs aWNhdGlvbnMgcG9ydGVkIHRvIEdTdHJlYW1lciAwLjEwIGluY2x1ZGUgVG90ZW0sIFJoeXRobUJv eCwgU291bmQtSnVpY2VyLApHbm9tZSBNZWRpYSwgRmx1bW90aW9uLCBBbWFyb2ssIEphbWJvcmVl LCBQaXRpdmksIElzdGFuYnVsLCBBbm5vQW1wLCBFbGlzYSwgYW5kIG90aGVycy4KTGV0IHVzIGtu b3cgaWYgeW91IHdhbnQgdG8gYmUgYWRkZWQgdG8gdGhpcyBsaXN0LgoKICAKQ29udHJpYnV0b3Jz IHRvIHRoaXMgcmVsZWFzZQogICAgCiAgICAgICogRWR3YXJkIEhlcnZleQogICAgICAqIFRob21h cyBWYW5kZXIgU3RpY2hlbGUKICAgICAgKiBUaW0tUGhpbGlwcCBNw7xsbGVyCsKg --127.0.0.1.500.6078.1149960001.170.2-- From sjoeboo@sjoeboo.com Wed Jun 14 10:50:35 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CE3003B037F; Wed, 14 Jun 2006 10:50:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08478-04; Wed, 14 Jun 2006 10:50:34 -0400 (EDT) Received: from server.sjoeboo.com (unknown [64.79.192.114]) by menubar.gnome.org (Postfix) with ESMTP id D38F13B02C8; Wed, 14 Jun 2006 10:50:33 -0400 (EDT) Received: by server.sjoeboo.com (Postfix, from userid 33) id 6D37418C4F7F; Wed, 14 Jun 2006 07:50:15 -0700 (PDT) To: gnome-multimedia@gnome.org, rhythmbox-devel@gnome.org Subject: totem and goom information... MIME-Version: 1.0 Date: Wed, 14 Jun 2006 7:50:15 -0700 From: sjoeboo Organization: sjoeboo.com Message-ID: <5135b2d86e5568cedc7e8138809a3b9f@localhost> X-Sender: sjoeboo@sjoeboo.com User-Agent: RoundCube Webmail/0.1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[AWL=0.000, BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: sjoeboo@sjoeboo.com List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 14:50:36 -0000 Good "morning" everyone, So, my (and what should be everyones) favorite music player for gnome, rhythmbox, has been on a steady march of advancement for the past few months, with a whole slew of new features comming about. One thing I though of recently is visualizations, and how ncie it would be to have at least one, possibly as a plugin. I know totem uses GOOM to do this, and was wondering what I might have to do in terms of gstreamer etc to have rhythmbox use it as well. I was looking around on the Totem site for a mailing list etc, but couldn't find anything. Does anyone know where I might find more info for something like this? Thanks, and keep up the great work. -- Matthew Nicholson sjoeboo@sjoeboo.com sjoeboo.com From internalerror@gmail.com Thu Jun 22 05:25:58 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E43203B02D2 for ; Thu, 22 Jun 2006 05:25:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12537-03 for ; Thu, 22 Jun 2006 05:25:56 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.201]) by menubar.gnome.org (Postfix) with ESMTP id D48DD3B0179 for ; Thu, 22 Jun 2006 05:25:55 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so314263wxc for ; Thu, 22 Jun 2006 02:25:55 -0700 (PDT) Received: by 10.70.91.12 with SMTP id o12mr2775555wxb; Thu, 22 Jun 2006 02:25:55 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 02:25:55 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 11:25:55 +0200 From: "Milosz Derezynski" To: xdg@lists.freedesktop.org Subject: MLQ (Media Library Query) file format and mime type proposal MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3009_31371308.1150968355005" X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.255 tagged_above=-999 required=2 tests=[AWL=0.344, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.255 X-Spam-Level: Cc: gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 09:25:58 -0000 ------=_Part_3009_31371308.1150968355005 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I'm one of the main authors of BMP 2 (still being worked on), and along the way of reworking our library, i came across the idea of encoding library queries as URIs, which may look like this: "query:///?artist=Air&album=Moon%20Safari" BMP 2 has a plugin archicture which is a small VFS on it's own, and we treat certain things as "containers" (i.e. they "contain" URIs, like PLS playlists, XSPF, M3U, etc). Now i thought it might be not a bad idea to create a playlist format with these query URLs, and i've called it "MLQ" for media library query. In theory, it's not even application specific. The keys (identifiers), like artist, album, etc, are all based on GStreamer tag identifiers. (They could be maybe adapted to http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but it seems insufficient and doesn't specify certain items, like musicbrainz metadata, which GST does). So i've called this file format "MLQ", with the extension .mlq, created a mime package file for it: Media Library Query List Adding a file of this type to BMPx, or just a plain query:/// URI itself causes a library query and appending of the relevant items to the tracklist (BMP is currently mostly based on the concept of a mutable playlist to which items can be added from various sources, unlike e.g. RB which has mostly immutable "Playlists", but allows for custom queues). Another example is: query:///?artist=Air&album=Moon%20Safari&title=La%20Femme%20d'Argent query:///?artist=Air&album=Moon%20Safari&title=Sexy%20Boy query:///?artist=Air&album=Moon%20Safari&title=All%20I%20Need query:///?artist=Air&album=Moon%20Safari&title=Kelly,%20Watch%20The%20Stars! query:///?artist=Air&album=Moon%20Safari&title=Talisman query:///?artist=Air&album=Moon%20Safari&title=Remember query:///?artist=Air&album=Moon%20Safari&title=You%20Make%20It%20Easy query:///?artist=Air&album=Moon%20Safari&title=Ce%20Matin%20La query:///?artist=Air&album=Moon%20Safari&title=New%20Star%20In%20The%20Sky query:///?artist=Air&album=Moon%20Safari&title=Le%20Voyage%20De%20Penelope Or it might just be: query:///?genre=Jazz Since this is very common, and having the discussions about a common music database in mind, this seems like a useful proposal, since it is not player specific. This ships currently with BMP 2/BMPx SVN, and while i will ship this with the 0.20 release (end-July) anyway, what does everyone think of this in a broader context (common music database, etc)? -- Milosz ------=_Part_3009_31371308.1150968355005 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

I'm one of the main authors of BMP 2 (still being worked on), and along the way of reworking our library, i came across the idea of encoding library queries as URIs, which may look like this:

"query:///?artist=Air&album=Moon%20Safari"

BMP 2 has a plugin archicture which is a small VFS on it's own, and we treat certain things as "containers" (i.e. they "contain" URIs, like PLS playlists, XSPF, M3U, etc).
Now i thought it might be not a bad idea to create a playlist format with these query URLs, and i've called it "MLQ" for media library query. In theory, it's not even
application specific. The keys (identifiers), like artist, album, etc, are all based on GStreamer tag identifiers. (They could be maybe adapted to http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but it seems insufficient and doesn't specify certain items, like musicbrainz metadata, which GST does).

So i've called this file format "MLQ", with the extension .mlq, created a mime package file for it:

<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info ">
  <mime-type type="application/x-media-library-query">
         <comment xml:lang="en">Media Library Query List</comment>
         <magic priority="50">
            <match value="query:///" type="string" offset="0"/>
         </magic>
         <glob pattern="*.mlq"/>
  </mime-type>
</mime-info>

Adding a file of this type to BMPx, or just a plain query:/// URI itself causes a library query and appending of the relevant items to the tracklist (BMP is currently mostly based on the concept of a mutable playlist to which items can be added from various sources, unlike e.g. RB which has mostly immutable "Playlists", but allows for custom queues).

Another example is:

query:///?artist=Air&album=Moon%20Safari&title=La%20Femme%20d'Argent
query:///?artist=Air&album=Moon%20Safari&title=Sexy%20Boy
query:///?artist=Air&album=Moon%20Safari&title=All%20I%20Need
query:///?artist=Air&album=Moon%20Safari&title=Kelly,%20Watch%20The%20Stars!
query:///?artist=Air&album=Moon%20Safari&title=Talisman
query:///?artist=Air&album=Moon%20Safari&title=Remember
query:///?artist=Air&album=Moon%20Safari&title=You%20Make%20It%20Easy
query:///?artist=Air&album=Moon%20Safari&title=Ce%20Matin%20La
query:///?artist=Air&album=Moon%20Safari&title=New%20Star%20In%20The%20Sky
query:///?artist=Air&album=Moon%20Safari&title=Le%20Voyage%20De%20Penelope

Or it might just be:

query:///?genre=Jazz

Since this is very common, and having the discussions about a common music database in mind, this seems like a useful proposal, since it is not player specific.
This ships currently with BMP 2/BMPx SVN, and while i will ship this with the 0.20 release (end-July) anyway, what does everyone think of this in a broader context (common music database, etc)?

-- Milosz
------=_Part_3009_31371308.1150968355005-- From internalerror@gmail.com Thu Jun 22 05:32:59 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7208D3B00DE for ; Thu, 22 Jun 2006 05:32:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12916-03 for ; Thu, 22 Jun 2006 05:32:58 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.207]) by menubar.gnome.org (Postfix) with ESMTP id 6F0643B0373 for ; Thu, 22 Jun 2006 05:32:58 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so314918wxc for ; Thu, 22 Jun 2006 02:32:57 -0700 (PDT) Received: by 10.70.103.9 with SMTP id a9mr2787413wxc; Thu, 22 Jun 2006 02:32:57 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 02:32:57 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 11:32:57 +0200 From: "Milosz Derezynski" To: xdg@lists.freedesktop.org Subject: MLQ: Followup MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3081_18949182.1150968777845" X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.875 tagged_above=-999 required=2 tests=[AWL=-0.071, BAYES_00=-2.599, HTML_00_10=0.795, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -1.875 X-Spam-Level: Cc: gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 09:32:59 -0000 ------=_Part_3081_18949182.1150968777845 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline What i forgot to mention: One benefit of MLQs over 'regular' playlists at least with BMP 2 is that i've introduced a concept of keeping track of tracks across mount point changes which basically works like this: BMP stores for each file the HAL volume and device UDI, and the VRP (Volume Relative Path), that is, the path stripped off the mount point root. Whenever it seems that a file is missing, it checks whether the volume UDI of this file is still present on the system, and if so, gathers the new mount point, and adjusts the URI of this file in the library (this obiviously only works with tracks from the library only anyway since only there we can reliably store the HAL volume/device UDI and the VRP). This means practically: - Mount your music to /music - Start BMP - Add music from /music to the library - Quit BMP - Remount /music to e.g. /old_music - Start BMP - Use the library as before. Whenever BMP finds a file is missing, it will correct the URI on-the-fly as long as the volume is mounted at all on the system (and has an UDI to begin with; problem cases here are network volumes, NFS and SMBFS) So the benefit of an MLQ is that unlike a static playlist, you can be rather sure that no matter where you really move the music, BMP will always be able to find it. Downsides/doesn't-works: - There is no volume UDI available - You make a regular 'move' (mv), and not just a remount In the context of having a common music database, or something like Tracker, this seems very useful (Jamie: Hence my urge to add HAL volume/device UDI per file to the metadata). -- Milosz ------=_Part_3081_18949182.1150968777845 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline What i forgot to mention:

One benefit of MLQs over 'regular' playlists at least with BMP 2 is that i've introduced a concept of keeping track of tracks across mount point changes which basically works like this:

BMP stores for each file the HAL volume and device UDI, and the VRP (Volume Relative Path), that is, the path stripped off the mount point root.
Whenever it seems that a file is missing, it checks whether the volume UDI of this file is still present on the system, and if so, gathers the new mount point, and adjusts the URI of this
file in the library (this obiviously only works with tracks from the library only anyway since only there we can reliably store the HAL volume/device UDI and the VRP).

This means practically:

- Mount your music to /music
- Start BMP
- Add music from /music to the library
- Quit BMP
- Remount /music to e.g. /old_music
- Start BMP
- Use the library as before. Whenever BMP finds a file is missing, it will correct the URI on-the-fly as long as the volume is mounted at all on the system (and has an UDI to begin with; problem cases here are network volumes, NFS and SMBFS)

So the benefit of an MLQ is that unlike a static playlist, you can be rather sure that no matter where you really move the music, BMP will always be able to find it.

Downsides/doesn't-works:

- There is no volume UDI available
- You make a regular 'move' (mv), and not just a remount

In the context of having a common music database, or something like Tracker, this seems very useful (Jamie: Hence my urge to add HAL volume/device UDI per file to the metadata).

-- Milosz
------=_Part_3081_18949182.1150968777845-- From internalerror@gmail.com Thu Jun 22 06:23:10 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 61AE53B0403 for ; Thu, 22 Jun 2006 06:23:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15637-08 for ; Thu, 22 Jun 2006 06:23:09 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.195]) by menubar.gnome.org (Postfix) with ESMTP id 7534E3B045B for ; Thu, 22 Jun 2006 06:23:08 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so321629wxc for ; Thu, 22 Jun 2006 03:23:07 -0700 (PDT) Received: by 10.70.14.14 with SMTP id 14mr2842980wxn; Thu, 22 Jun 2006 03:23:07 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 03:23:07 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 12:23:07 +0200 From: "Milosz Derezynski" To: "Josef Spillner" Subject: Re: MLQ (Media Library Query) file format and mime type proposal In-Reply-To: <200606221139.41836.spillner@kde.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3405_33193106.1150971787566" References: <200606221139.41836.spillner@kde.org> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.443 tagged_above=-999 required=2 tests=[AWL=-0.496, BAYES_00=-2.599, HTML_10_20=1.351, HTML_MESSAGE=0.001, MIME_BASE64_NO_NAME=0.224, SPF_PASS=-0.001, TW_XD=0.077] X-Spam-Score: -1.443 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 10:23:10 -0000 ------=_Part_3405_33193106.1150971787566 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline WWVhaCB3ZWxsIGp1c3QgdG8gc3RheSB3aXRoaW4gdGhlIGZvY3VzIG9mIGEgbXVzaWMgbGlicmFy eSwgdGhlcmUgaGFzIHRvIGJlCnNvbWV0aGluZwp0aGF0IGRvZXMgdGhlIHJlc29sdXRpb24uCgpP TkUgcG9zc2libGUgb3B0aW9uIHdvdWxkIGJlIHRvIHNwZWNpZnkgYSBELUJVUyBpbnRlcmZhY2Ug bmFtZSwgYW5kIGEgaGF2ZQpzaW1wbGUgbGF1bmNoZXIuCgpBbGwgYXBwcyBzdXBwb3J0aW5nIE1M UXMgd291bGQgaGF2ZSB0byBoYXZlIGEgbWluaW1hbCBjb21tb24gc3Vic2V0Cm9mIEQtQlVTIGlu dGVyZmFjZXJ5IHRvIGFsbG93IHRoaXMga2luZCBvZiBxdWVyeSB0byBiZSBzZW50IHRvIHRoZW0g aW4gc29tZQp3YXkKKHNvbWV0aGluZyBsaWtlIGFuIEFkZFVyaSBjYWxsIG1pZ2h0IGp1c3Qgc3Vm ZmljZSksIHRoZW4gdGhlIGxhdW5jaGVyIHdvdWxkCmJhc2ljYWxseQpjb25zaXN0IG9mIHN0YXJ0 aW5nIHRoZSByZWxldmFudCBhcGxsaWNhdGlvbiB0cm91Z2ggRC1CVVMgYWN0aXZhdGlvbiwgYW5k CnRoZW4gcGFzcyBvbgp0aGUgYWN0dWFsIHF1ZXJ5IHRvIGl0LgoKKFdlIGhhdmUgYSBkdW1teSBt ZXRob2QgIlN0YXJ0dXAiIG9uIG91ciBELUJVUyBpZmFjZSB3aGljaApkb2VzIG5vdGhpbmcsIGJ1 dCBjYXVzZXMgRC1CVVMgdG8gc3RhcnQgdXAgQk1QLiBUaGUgcmVhc29uaW5nIGlzIHRoYXQgd2UK aGF2ZSBvbmUgbWFpbgpiaW5hcnkgYW5kIG9uZSAicmVtb3RlIiBiaW5hcnksIHdoaWNoIGlzIHRo b3VnaCBzZXQgc28gdGhhdCBpdCBpcyBwZXJjZWl2ZWQKYXMgYmVpbmcgdGhlIG1haW4KYmluYXJ5 LCBhcyBpbiBpdCdzIGluIC91c3IvYmluLCB3aGVyZWFzIHRoZSAtYmluIChtYWluKSBiaW5hcnkg aXMgaW4KL3Vzci9saWJleGVjLiBUaGUgcmVhc29uCmlzIHNvIHRoYXQgd2UgaGF2ZSBhIGxpZ2h0 d2VpZ2h0IHJlbW90ZSBhcHAgdGhhdCBjYW4gcGVyZm9ybSBhY3Rpb25zIG9uIHRoZQptYWluIGJp bmFyeQphbmQgZG9uJ3QgaGF2ZSB0byBoYXZlIHRoZSBtYWluIGFwcCBiZSBjYXBhYmxlIG9mIGJl aW5nIGEgY2xpZW50IHRvIGl0J3Mgb3duCnNlcnZlcgphbmQgaGF2ZSBhbGwgdGhlIHN0YXJ0dXAg c2hpenpsZSBnb2luZyBqdXN0IHRvIHBlcmZvcm0gYSBjZXJ0YWluIHJlbW90ZQpvcGVyYXRpb24p LgoKRm9yIGV4YW1wbGUgeW91J2QgaGF2ZToKcXVlcnk6Ly9vcmcuYmVlcG1lZGlhcGxheWVyLmJt cC8/YXJ0aXN0PUFpciZBbGJ1bT1Nb29uJTIwU2FmYXJpCgpUaGUgc2NyaXB0LCBvciBiZSBpdCBh IGJpbmFyeSwgbGV0J3MgY2FsbCBpdCAicGxheS1tbHEiLCB3b3VsZCBsYXVuY2ggdGhlCnBsYXll ciB3aXRoIHRoZSBzcGVjaWZpZWQgaW50ZXJmYWNlIGFuZCBwYXNzIGl0IHRoZSBhY3R1YWwgcXVl cnkuCgpfQW5vdGhlcl8gcG9zc2liaWxpdHksIGFsdGhvdWdoIHRoaXMgd291bGQgcmVxdWlyZSBw bGF5ZXJzIHRoYXQgY2FuIHdvcmsKd2l0aAptdXRhYmxlIHBsYXlsaXN0cyBsaWtlIEJNUCwgaXMg dGhhdCBpdCB3b3VsZCBwYXNzIHRoZSBxdWVyeSBvbiB0byBlLmcuCnNvbWV0aGluZwpsaWtlIFRy YWNrZXIgb3Igc29tZSBvdGhlciBpbmRleGVyLCB3aGljaCB3b3VsZCB0aGVuIGV4ZWN1dGUgdGhl IHF1ZXJ5IGFuZApfSVRfIHdvdWxkIHRoZW4gc3RhcnQgdGhlIHBsYXllciBzcGVjaWZpZWQgYnkg dGhlIGludGVyZmFjZSBhbmQgcGFzcyBpdAphbG9uZyB0aGUKcmVzdWx0aW5nIFVSSXMuCgotLSBN aWxvc3oKCk9uIDYvMjIvMDYsIEpvc2VmIFNwaWxsbmVyIDxzcGlsbG5lckBrZGUub3JnPiB3cm90 ZToKPgo+IEFsbGUgMTE6MjUsIGdpb3ZlZMOsLCAyMi4gZ2l1Z25vIDIwMDYsIE1pbG9zeiBEZXJl enluc2tpIGhhIHNjcml0dG86Cj4gPiBTaW5jZSB0aGlzIGlzIHZlcnkgY29tbW9uLCBhbmQgaGF2 aW5nIHRoZSBkaXNjdXNzaW9ucyBhYm91dCBhIGNvbW1vbgo+IG11c2ljCj4gPiBkYXRhYmFzZSBp biBtaW5kLCB0aGlzIHNlZW1zIGxpa2UgYSB1c2VmdWwgcHJvcG9zYWwsIHNpbmNlIGl0IGlzIG5v dAo+IHBsYXllcgo+ID4gc3BlY2lmaWMuCj4KPiBJdCBpcyBub3QgZXZlbiBtdXNpYyBzcGVjaWZp Yy4gSSd2ZSB1c2VkIHF1ZXJ5Oi8vIFVSSXMgZm9yIGEgbG9uZyB0aW1lCj4gd2l0aAo+IG1ldGFz ZXJ2ZXJzLCBhbHRob3VnaCBvbmx5IGluIGEgcmVhZC1vbmx5IGNvbnRleHQsIHdoZXJlYXMgZm9y IHdyaXRlCj4gYWNjZXNzCj4gdGhlIChhbHRlcm5hdGl2ZSkgZnVsbC1ibG93biBYTUwgaW50ZXJm YWNlIGlzIHVzZWQuCj4KPiBUaGUgd2F5IGl0IGlzIHVzZWQgZm9yIHRoZSBtZXRhc2VydmVyIGlz IGxpa2UgcXVlcnk6Ly90eXBlL2NhdGVnb3J5LCB3aGVyZQo+IGUuZy4gdHlwZSB3b3VsZCBiZSB0 aGUgZ2VuZXJpYyBuYW1lIGZvciBhIHNlcnZlciAoc2F5LCAnZnJlZWNpdicgb3IKPiAnY3Vwc2Qn KQo+IGFuZCBjYXRlZ29yeSB3b3VsZCBiZSAnY29ubmVjdGlvbicgKHRvIGdldCBiYWNrIGEgY29u bmVjdGlvbiBVUkkpIG9yCj4gJ21ldGEnCj4gKHRvIGdldCBiYWNrIG90aGVyIG1ldGFzZXJ2ZXIg VVJJcyBmb3IgdGhlIHNhbWUgdHlwZSkuCj4gVXNpbmcgc3VjaCBhIHNjaGVtZSBtYWtlcyBhbiBh cHBsaWNhdGlvbiByZXNpc3RhbnQgYWdhaW5zdCBob3N0IG5hbWUKPiBjaGFuZ2VzCj4gaW4gdGhl IGxvbmcgcnVuLCBpLmUuIGl0IHdpbGwgcGljayB1cCBtb3Zpbmcgc2VydmVycyBhdXRvbWF0aWNh bGx5Lgo+Cj4gVGhpcyBpcyBwcm9iYWJseSBub3QgdGhlIHNhbWUgdGhpbmcgYXMgeW91ciBxdWVy eSwgYnV0IG9idmlvdXNseSBpdCdzIGFsc28KPiB1c2VkIHRvIHF1ZXJ5IGEgZGF0YWJhc2UgYmVo aW5kIGl0ICh3aGljaCBpcyBhIFhNTCBkYXRhYmFzZSBpbiBteSBjYXNlLAo+IGJ1dAo+IGNvdWxk IGJlIFNRTCBvciBhbnl0aGluZyBlbHNlIGZvciB0aGF0IG1hdHRlcikuIFNvIG1heWJlIGl0IG1h a2VzIHNlbnNlIHRvCj4gc3RhbmRhcmRpc2UgdGhpcyBpbiBhIGJyb2FkZXIgY29udGV4dC4KPgo+ IEtERSBSYWRpbyBTdGF0aW9uIGlzIG9uZSBleGFtcGxlIHdoZXJlIHRoaXMgaXMgdXNlZCAoaGEg LSBmb3VuZCBhIHJlbGF0aW9uCj4gdG8KPiBtdXNpYyEpLCBhbmQgdGhlIEdHWiBHYW1pbmcgWm9u ZSBwcm9qZWN0IGlzIGFub3RoZXIgb25lICh3aGVyZSBpdAo+IG9yaWdpbmF0ZWQKPiBzaW5jZSBt ZXRhc2VydmVycyBhcmUgY29tbW9ucGxhY2Ugd2l0aCBnYW1lIHNlcnZlcnMpLgo+Cj4gSm9zZWYK PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IHhkZyBt YWlsaW5nIGxpc3QKPiB4ZGdAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCj4gaHR0cDovL2xpc3RzLmZy ZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hkZwo+Cg== ------=_Part_3405_33193106.1150971787566 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline WWVhaCB3ZWxsIGp1c3QgdG8gc3RheSB3aXRoaW4gdGhlIGZvY3VzIG9mIGEgbXVzaWMgbGlicmFy eSwgdGhlcmUgaGFzIHRvIGJlIHNvbWV0aGluZzxicj50aGF0IGRvZXMgdGhlIHJlc29sdXRpb24u PGJyPjxicj5PTkUgcG9zc2libGUgb3B0aW9uIHdvdWxkIGJlIHRvIHNwZWNpZnkgYSBELUJVUyBp bnRlcmZhY2UgbmFtZSwgYW5kIGEgaGF2ZSBzaW1wbGUgbGF1bmNoZXIuPGJyPjxicj5BbGwgYXBw cyBzdXBwb3J0aW5nIE1MUXMgd291bGQgaGF2ZSB0byBoYXZlIGEgbWluaW1hbCBjb21tb24gc3Vi c2V0Cjxicj5vZiBELUJVUyBpbnRlcmZhY2VyeSB0byBhbGxvdyB0aGlzIGtpbmQgb2YgcXVlcnkg dG8gYmUgc2VudCB0byB0aGVtIGluIHNvbWUgd2F5PGJyPihzb21ldGhpbmcgbGlrZSBhbiBBZGRV cmkgY2FsbCBtaWdodCBqdXN0IHN1ZmZpY2UpLCB0aGVuIHRoZSBsYXVuY2hlciB3b3VsZCBiYXNp Y2FsbHk8YnI+Y29uc2lzdCBvZiBzdGFydGluZyB0aGUgcmVsZXZhbnQgYXBsbGljYXRpb24gdHJv dWdoIEQtQlVTIGFjdGl2YXRpb24sIGFuZCB0aGVuIHBhc3Mgb24KPGJyPnRoZSBhY3R1YWwgcXVl cnkgdG8gaXQuIDxicj48YnI+KFdlIGhhdmUgYSBkdW1teSBtZXRob2QgJnF1b3Q7U3RhcnR1cCZx dW90OyBvbiBvdXIgRC1CVVMgaWZhY2Ugd2hpY2g8YnI+ZG9lcyBub3RoaW5nLCBidXQgY2F1c2Vz IEQtQlVTIHRvIHN0YXJ0IHVwIEJNUC4gVGhlIHJlYXNvbmluZyBpcyB0aGF0IHdlIGhhdmUgb25l IG1haW48YnI+YmluYXJ5IGFuZCBvbmUgJnF1b3Q7cmVtb3RlJnF1b3Q7IGJpbmFyeSwgd2hpY2gg aXMgdGhvdWdoIHNldCBzbyB0aGF0IGl0IGlzIHBlcmNlaXZlZCBhcyBiZWluZyB0aGUgbWFpbgo8 YnI+YmluYXJ5LCBhcyBpbiBpdCdzIGluIC91c3IvYmluLCB3aGVyZWFzIHRoZSAtYmluIChtYWlu KSBiaW5hcnkgaXMgaW4gL3Vzci9saWJleGVjLiBUaGUgcmVhc29uPGJyPmlzIHNvIHRoYXQgd2Ug aGF2ZSBhIGxpZ2h0d2VpZ2h0IHJlbW90ZSBhcHAgdGhhdCBjYW4gcGVyZm9ybSBhY3Rpb25zIG9u IHRoZSBtYWluIGJpbmFyeTxicj5hbmQgZG9uJ3QgaGF2ZSB0byBoYXZlIHRoZSBtYWluIGFwcCBi ZSBjYXBhYmxlIG9mIGJlaW5nIGEgY2xpZW50IHRvIGl0J3Mgb3duIHNlcnZlcgo8YnI+YW5kIGhh dmUgYWxsIHRoZSBzdGFydHVwIHNoaXp6bGUgZ29pbmcganVzdCB0byBwZXJmb3JtIGEgY2VydGFp biByZW1vdGUgb3BlcmF0aW9uKS48YnI+PGJyPkZvciBleGFtcGxlIHlvdSdkIGhhdmU6PGJyPnF1 ZXJ5Oi8vb3JnLmJlZXBtZWRpYXBsYXllci5ibXAvP2FydGlzdD1BaXImYW1wO0FsYnVtPU1vb24l MjBTYWZhcmk8YnI+PGJyPlRoZSBzY3JpcHQsIG9yIGJlIGl0IGEgYmluYXJ5LCBsZXQncyBjYWxs IGl0ICZxdW90O3BsYXktbWxxJnF1b3Q7LCB3b3VsZCBsYXVuY2ggdGhlCjxicj5wbGF5ZXIgd2l0 aCB0aGUgc3BlY2lmaWVkIGludGVyZmFjZSBhbmQgcGFzcyBpdCB0aGUgYWN0dWFsIHF1ZXJ5Ljxi cj48YnI+X0Fub3RoZXJfIHBvc3NpYmlsaXR5LCBhbHRob3VnaCB0aGlzIHdvdWxkIHJlcXVpcmUg cGxheWVycyB0aGF0IGNhbiB3b3JrIHdpdGg8YnI+bXV0YWJsZSBwbGF5bGlzdHMgbGlrZSBCTVAs IGlzIHRoYXQgaXQgd291bGQgcGFzcyB0aGUgcXVlcnkgb24gdG8gCmUuZy4gc29tZXRoaW5nPGJy Pmxpa2UgVHJhY2tlciBvciBzb21lIG90aGVyIGluZGV4ZXIsIHdoaWNoIHdvdWxkIHRoZW4gZXhl Y3V0ZSB0aGUgcXVlcnkgYW5kPGJyPl9JVF8gd291bGQgdGhlbiBzdGFydCB0aGUgcGxheWVyIHNw ZWNpZmllZCBieSB0aGUgaW50ZXJmYWNlIGFuZCBwYXNzIGl0IGFsb25nIHRoZTxicj5yZXN1bHRp bmcgVVJJcy48YnI+PGJyPi0tIE1pbG9zejxicj48YnI+CjxkaXY+PHNwYW4gY2xhc3M9ImdtYWls X3F1b3RlIj5PbiA2LzIyLzA2LCA8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+Sm9zZWYgU3Bp bGxuZXI8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86c3BpbGxuZXJAa2RlLm9yZyI+c3BpbGxuZXJA a2RlLm9yZzwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv dGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFy Z2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4KQWxsZSAxMToyNSwg Z2lvdmVkw6wsIDIyLiBnaXVnbm8gMjAwNiwgTWlsb3N6IERlcmV6eW5za2kgaGEgc2NyaXR0bzo8 YnI+Jmd0OyBTaW5jZSB0aGlzIGlzIHZlcnkgY29tbW9uLCBhbmQgaGF2aW5nIHRoZSBkaXNjdXNz aW9ucyBhYm91dCBhIGNvbW1vbiBtdXNpYzxicj4mZ3Q7IGRhdGFiYXNlIGluIG1pbmQsIHRoaXMg c2VlbXMgbGlrZSBhIHVzZWZ1bCBwcm9wb3NhbCwgc2luY2UgaXQgaXMgbm90IHBsYXllcgo8YnI+ Jmd0OyBzcGVjaWZpYy48YnI+PGJyPkl0IGlzIG5vdCBldmVuIG11c2ljIHNwZWNpZmljLiBJJ3Zl IHVzZWQgcXVlcnk6Ly8gVVJJcyBmb3IgYSBsb25nIHRpbWUgd2l0aDxicj5tZXRhc2VydmVycywg YWx0aG91Z2ggb25seSBpbiBhIHJlYWQtb25seSBjb250ZXh0LCB3aGVyZWFzIGZvciB3cml0ZSBh Y2Nlc3M8YnI+dGhlIChhbHRlcm5hdGl2ZSkgZnVsbC1ibG93biBYTUwgaW50ZXJmYWNlIGlzIHVz ZWQuCjxicj48YnI+VGhlIHdheSBpdCBpcyB1c2VkIGZvciB0aGUgbWV0YXNlcnZlciBpcyBsaWtl IHF1ZXJ5Oi8vdHlwZS9jYXRlZ29yeSwgd2hlcmU8YnI+ZS5nLiB0eXBlIHdvdWxkIGJlIHRoZSBn ZW5lcmljIG5hbWUgZm9yIGEgc2VydmVyIChzYXksICdmcmVlY2l2JyBvciAnY3Vwc2QnKTxicj5h bmQgY2F0ZWdvcnkgd291bGQgYmUgJ2Nvbm5lY3Rpb24nICh0byBnZXQgYmFjayBhIGNvbm5lY3Rp b24gVVJJKSBvciAnbWV0YScKPGJyPih0byBnZXQgYmFjayBvdGhlciBtZXRhc2VydmVyIFVSSXMg Zm9yIHRoZSBzYW1lIHR5cGUpLjxicj5Vc2luZyBzdWNoIGEgc2NoZW1lIG1ha2VzIGFuIGFwcGxp Y2F0aW9uIHJlc2lzdGFudCBhZ2FpbnN0IGhvc3QgbmFtZSBjaGFuZ2VzPGJyPmluIHRoZSBsb25n IHJ1biwgaS5lLiBpdCB3aWxsIHBpY2sgdXAgbW92aW5nIHNlcnZlcnMgYXV0b21hdGljYWxseS48 YnI+PGJyPlRoaXMgaXMgcHJvYmFibHkgbm90IHRoZSBzYW1lIHRoaW5nIGFzIHlvdXIgcXVlcnks IGJ1dCBvYnZpb3VzbHkgaXQncyBhbHNvCjxicj51c2VkIHRvIHF1ZXJ5IGEgZGF0YWJhc2UgYmVo aW5kIGl0ICh3aGljaCBpcyBhIFhNTCBkYXRhYmFzZSBpbiBteSBjYXNlLCBidXQ8YnI+Y291bGQg YmUgU1FMIG9yIGFueXRoaW5nIGVsc2UgZm9yIHRoYXQgbWF0dGVyKS4gU28gbWF5YmUgaXQgbWFr ZXMgc2Vuc2UgdG88YnI+c3RhbmRhcmRpc2UgdGhpcyBpbiBhIGJyb2FkZXIgY29udGV4dC48YnI+ PGJyPktERSBSYWRpbyBTdGF0aW9uIGlzIG9uZSBleGFtcGxlIHdoZXJlIHRoaXMgaXMgdXNlZCAo aGEgLSBmb3VuZCBhIHJlbGF0aW9uIHRvCjxicj5tdXNpYyEpLCBhbmQgdGhlIEdHWiBHYW1pbmcg Wm9uZSBwcm9qZWN0IGlzIGFub3RoZXIgb25lICh3aGVyZSBpdCBvcmlnaW5hdGVkPGJyPnNpbmNl IG1ldGFzZXJ2ZXJzIGFyZSBjb21tb25wbGFjZSB3aXRoIGdhbWUgc2VydmVycykuPGJyPjxicj5K b3NlZjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj54ZGcgbWFpbGluZyBsaXN0Cjxicj48YSBocmVmPSJtYWlsdG86eGRnQGxpc3RzLmZyZWVkZXNr dG9wLm9yZyI+eGRnQGxpc3RzLmZyZWVkZXNrdG9wLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cDov L2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hkZyI+aHR0cDovL2xpc3Rz LmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hkZzwvYT48YnI+PC9ibG9ja3F1b3Rl PjwvZGl2Pjxicj4K ------=_Part_3405_33193106.1150971787566-- From jamiemcc@blueyonder.co.uk Thu Jun 22 06:41:17 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 687D03B0251 for ; Thu, 22 Jun 2006 06:41:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17075-06 for ; Thu, 22 Jun 2006 06:41:15 -0400 (EDT) Received: from smtp-out5.blueyonder.co.uk (smtp-out5.blueyonder.co.uk [195.188.213.8]) by menubar.gnome.org (Postfix) with ESMTP id 74F7B3B021B for ; Thu, 22 Jun 2006 06:41:15 -0400 (EDT) Received: from [172.23.170.145] (helo=anti-virus03-08) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1FtMca-0004xo-T2; Thu, 22 Jun 2006 11:41:12 +0100 Received: from [62.30.198.187] (helo=[62.30.198.187]) by asmtp-out2.blueyonder.co.uk with esmtpa (Exim 4.52) id 1FtMcZ-0001pP-Rp; Thu, 22 Jun 2006 11:41:11 +0100 Message-ID: <449A73D1.6030401@blueyonder.co.uk> Date: Thu, 22 Jun 2006 11:41:21 +0100 From: Jamie McCracken User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Milosz Derezynski Subject: Re: MLQ: Followup References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.459 tagged_above=-999 required=2 tests=[AWL=0.141, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.459 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 10:41:17 -0000 Milosz Derezynski wrote: > What i forgot to mention: > > One benefit of MLQs over 'regular' playlists at least with BMP 2 is that > i've introduced a concept of keeping track of tracks across mount point > changes which basically works like this: > > BMP stores for each file the HAL volume and device UDI, and the VRP > (Volume Relative Path), that is, the path stripped off the mount point root. > Whenever it seems that a file is missing, it checks whether the volume > UDI of this file is still present on the system, and if so, gathers the > new mount point, and adjusts the URI of this > file in the library (this obiviously only works with tracks from the > library only anyway since only there we can reliably store the HAL > volume/device UDI and the VRP). > > This means practically: > > - Mount your music to /music > - Start BMP > - Add music from /music to the library > - Quit BMP > - Remount /music to e.g. /old_music > - Start BMP > - Use the library as before. Whenever BMP finds a file is missing, it > will correct the URI on-the-fly as long as the volume is mounted at all > on the system (and has an UDI to begin with; problem cases here are > network volumes, NFS and SMBFS) > > So the benefit of an MLQ is that unlike a static playlist, you can be > rather sure that no matter where you really move the music, BMP will > always be able to find it. > > Downsides/doesn't-works: > > - There is no volume UDI available > - You make a regular 'move' (mv), and not just a remount > > In the context of having a common music database, or something like > Tracker, this seems very useful (Jamie: Hence my urge to add HAL > volume/device UDI per file to the metadata). Im quite happy to add this as metadata to tracker and even get tracker to hide stuff based on it (using hal) but it still needs to be part of the uri for a music file (otherwise we wont be able to uniquely identify the files) -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ From jamiemcc@blueyonder.co.uk Thu Jun 22 06:52:34 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 93DEE3B031A for ; Thu, 22 Jun 2006 06:52:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17877-10 for ; Thu, 22 Jun 2006 06:52:32 -0400 (EDT) Received: from smtp-out5.blueyonder.co.uk (smtp-out5.blueyonder.co.uk [195.188.213.8]) by menubar.gnome.org (Postfix) with ESMTP id 66C8B3B0262 for ; Thu, 22 Jun 2006 06:52:32 -0400 (EDT) Received: from [172.23.170.140] (helo=anti-virus02-07) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1FtMnX-0007Tp-4T; Thu, 22 Jun 2006 11:52:31 +0100 Received: from [62.30.198.187] (helo=[62.30.198.187]) by asmtp-out1.blueyonder.co.uk with esmtpa (Exim 4.52) id 1FtMnU-0001TX-7r; Thu, 22 Jun 2006 11:52:28 +0100 Message-ID: <449A7676.6060309@blueyonder.co.uk> Date: Thu, 22 Jun 2006 11:52:38 +0100 From: Jamie McCracken User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Milosz Derezynski Subject: Re: MLQ (Media Library Query) file format and mime type proposal References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.422 tagged_above=-999 required=2 tests=[AWL=0.101, BAYES_00=-2.599, SPF_PASS=-0.001, TW_RQ=0.077] X-Spam-Score: -2.422 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 10:52:34 -0000 Milosz Derezynski wrote: > Hi, > > I'm one of the main authors of BMP 2 (still being worked on), and along > the way of reworking our library, i came across the idea of encoding > library queries as URIs, which may look like this: > > "query:///?artist=Air&album=Moon%20Safari" > > BMP 2 has a plugin archicture which is a small VFS on it's own, and we > treat certain things as "containers" (i.e. they "contain" URIs, like PLS > playlists, XSPF, M3U, etc). > Now i thought it might be not a bad idea to create a playlist format > with these query URLs, and i've called it "MLQ" for media library query. > In theory, it's not even > application specific. The keys (identifiers), like artist, album, etc, > are all based on GStreamer tag identifiers. (They could be maybe adapted > to http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , > but it seems insufficient and doesn't specify certain items, like > musicbrainz metadata, which GST does). Tracker's metadata spec does (http://freedesktop.org/wiki/Standards/shared-filemetadata-spec) > > So i've called this file format "MLQ", with the extension .mlq, created > a mime package file for it: > > > > > Media Library Query List > > > > > > > > Adding a file of this type to BMPx, or just a plain query:/// URI itself > causes a library query and appending of the relevant items to the > tracklist (BMP is currently mostly based on the concept of a mutable > playlist to which items can be added from various sources, unlike e.g. > RB which has mostly immutable "Playlists", but allows for custom queues). > > Another example is: > > query:///?artist=Air&album=Moon%20Safari&title=La%20Femme%20d'Argent > query:///?artist=Air&album=Moon%20Safari&title=Sexy%20Boy > query:///?artist=Air&album=Moon%20Safari&title=All%20I%20Need > query:///?artist=Air&album=Moon%20Safari&title=Kelly,%20Watch%20The%20Stars! > query:///?artist=Air&album=Moon%20Safari&title=Talisman > query:///?artist=Air&album=Moon%20Safari&title=Remember > query:///?artist=Air&album=Moon%20Safari&title=You%20Make%20It%20Easy > query:///?artist=Air&album=Moon%20Safari&title=Ce%20Matin%20La > query:///?artist=Air&album=Moon%20Safari&title=New%20Star%20In%20The%20Sky > query:///?artist=Air&album=Moon%20Safari&title=Le%20Voyage%20De%20Penelope > > Or it might just be: > > query:///?genre=Jazz > > Since this is very common, and having the discussions about a common > music database in mind, this seems like a useful proposal, since it is > not player specific. > This ships currently with BMP 2/BMPx SVN, and while i will ship this > with the 0.20 release (end-July) anyway, what does everyone think of > this in a broader context (common music database, etc)? Could be interesting as an alternative to rdf query that tracker uses but rdf query is a *standard* and is the WC3's recommended means of querying metadata. A more compact version of the xml based rdf query language is sparql (http://www.w3.org/TR/rdf-sparql-query/) and is also a candidate for standardisation. I guess its going to be fun deciding which to use (I will go with the flow) -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ From doclivingston@gmail.com Thu Jun 22 07:00:08 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 966243B038B for ; Thu, 22 Jun 2006 07:00:08 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18372-10 for ; Thu, 22 Jun 2006 07:00:05 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by menubar.gnome.org (Postfix) with ESMTP id 2DC8B3B00ED for ; Thu, 22 Jun 2006 07:00:05 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id f25so276546pyf for ; Thu, 22 Jun 2006 04:00:04 -0700 (PDT) Received: by 10.35.91.15 with SMTP id t15mr948347pyl; Thu, 22 Jun 2006 04:00:04 -0700 (PDT) Received: from alyrion.local ( [144.139.19.209]) by mx.gmail.com with ESMTP id w28sm110735pyc.2006.06.22.04.00.02; Thu, 22 Jun 2006 04:00:04 -0700 (PDT) Subject: Re: MLQ: Followup From: "James \"Doc\" Livingston" To: gnome-multimedia@gnome.org In-Reply-To: References: Content-Type: text/plain Date: Thu, 22 Jun 2006 20:59:59 +1000 Message-Id: <1150973999.5186.17.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.317 tagged_above=-999 required=2 tests=[AWL=0.283, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.317 X-Spam-Level: X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: doclivingston@gmail.com List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 11:00:08 -0000 On Thu, 2006-06-22 at 11:32 +0200, Milosz Derezynski wrote: > One benefit of MLQs over 'regular' playlists at least with BMP 2 is > that i've introduced a concept of keeping track of tracks across mount > point changes which basically works like this: > So the benefit of an MLQ is that unlike a static playlist, you can be > rather sure that no matter where you really move the music, BMP will > always be able to find it. I'm a bit confused about how "HAL UDI + partial path" is related to the MLQ idea. To me they seem fairly orthogonal. However using HAL UDIs is a good idea. Most apps currently use the URI as it's unique identifier and the method of finding the actual file, we could decide that the common db would use a as the unique id/location method. > Downsides/doesn't-works: > - There is no volume UDI available If this is a permanent thing, e.g. a non-HAL system or a http:// resource, then we could say that a null UDI and the full uri would be used instead. If it's temporary, e.g. HAL isn't running, or isn't detecting the device properly, then it's probably more complicated. Dealing with the fact that the users music is stored as and we don't know the URI would be funky. Perhaps we could say all db entries have the field, and a "last known"/non-HAL location field. > - You make a regular 'move' (mv), and not just a remount That is different again, and is probably best solved with audio fingerprinting, and/or embedding unique metadata in the file. Cheers. James "Doc" Livingston -- If USENET is anarchy, IRC is a paranoid schizophrenic after 6 days on speed. -- Chris "Saundo" Saunderson in asr. From doclivingston@gmail.com Thu Jun 22 07:04:28 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CFF783B0254 for ; Thu, 22 Jun 2006 07:04:28 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18854-05 for ; Thu, 22 Jun 2006 07:04:27 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by menubar.gnome.org (Postfix) with ESMTP id 0309C3B05B2 for ; Thu, 22 Jun 2006 07:04:26 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id f28so267516pyf for ; Thu, 22 Jun 2006 04:04:26 -0700 (PDT) Received: by 10.35.82.15 with SMTP id j15mr949278pyl; Thu, 22 Jun 2006 04:04:26 -0700 (PDT) Received: from alyrion.local ( [144.139.19.209]) by mx.gmail.com with ESMTP id w66sm860753pyw.2006.06.22.04.04.24; Thu, 22 Jun 2006 04:04:26 -0700 (PDT) Subject: Re: MLQ (Media Library Query) file format and mime type proposal From: "James \"Doc\" Livingston" To: gnome-multimedia@gnome.org In-Reply-To: References: Content-Type: text/plain Date: Thu, 22 Jun 2006 21:04:21 +1000 Message-Id: <1150974261.5186.22.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.319 tagged_above=-999 required=2 tests=[AWL=0.281, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.319 X-Spam-Level: X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: doclivingston@gmail.com List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 11:04:29 -0000 On Thu, 2006-06-22 at 11:25 +0200, Milosz Derezynski wrote: > I'm one of the main authors of BMP 2 (still being worked on), and > along the way of reworking our library, i came across the idea of > encoding library queries as URIs, which may look like this: > > "query:///?artist=Air&album=Moon%20Safari" > Adding a file of this type to BMPx, or just a plain query:/// URI > itself causes a library query and appending of the relevant items to > the tracklist (BMP is currently mostly based on the concept of a > mutable playlist to which items can be added from various sources, > unlike e.g. RB which has mostly immutable "Playlists", but allows for > custom queues). I'm a bit confused as to what this is actually for. Is it meant for saving "smart playlist"-type (or other db queries) things to disk? If so, it's probably better to use one of the existing query formats. If we want to use XML, then RDF (which is what Tracker uses for all it's queries) is probably as good as anything. James "Doc" Livingston -- "The Web brings people together because no matter what kind of a twisted sexual mutant you happen to be, you've got millions of pals out there. Type in 'Find people that have sex with goats that are on fire' and the computer will ask, 'Specify type of goat.'" -- Rich Jeni From internalerror@gmail.com Thu Jun 22 07:35:27 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BBE833B064F for ; Thu, 22 Jun 2006 07:35:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20711-02 for ; Thu, 22 Jun 2006 07:35:26 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.197]) by menubar.gnome.org (Postfix) with ESMTP id 1F4E83B0528 for ; Thu, 22 Jun 2006 07:35:26 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so334141wxc for ; Thu, 22 Jun 2006 04:35:26 -0700 (PDT) Received: by 10.70.65.10 with SMTP id n10mr2935604wxa; Thu, 22 Jun 2006 04:35:25 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 04:35:25 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 13:35:25 +0200 From: "Milosz Derezynski" To: doclivingston@gmail.com Subject: Re: MLQ: Followup In-Reply-To: <1150973999.5186.17.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3961_29338319.1150976125920" References: <1150973999.5186.17.camel@localhost.localdomain> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.246 tagged_above=-999 required=2 tests=[AWL=0.353, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.246 X-Spam-Level: Cc: gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 11:35:27 -0000 ------=_Part_3961_29338319.1150976125920 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/22/06, James Doc Livingston wrote: If it's temporary, e.g. HAL isn't running, or isn't detecting the device > properly, then it's probably more complicated. Dealing with the fact > that the users music is stored as and we don't know the URI > would be funky. Perhaps we could say all db entries have the > field, and a "last known"/non-HAL location field. > That's what i'm currently doing, i store the full URI, but also the UDI and the partial path, and in case HAL is not avaiable there is still the full URI present as a current resort. The ideal situation would be that HAL would be always available, would have UDIs for all volumes, and would run on all systems we need to run this to (Including let's say Solaris, etc), in which case it would be exactly what you said, one would need to only store the volume UDI and the partial path. Well anyway, repeating myself, just wanted to add that we also already store the full URI as a backup. ------=_Part_3961_29338319.1150976125920 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 6/22/06, James Doc Livingston <doclivingston@gmail.com> wrote:

If it's temporary, e.g. HAL isn't running, or isn't detecting the device
properly, then it's probably more complicated. Dealing with the fact
that the users music is stored as <UDI, path> and we don't know the URI
would be funky. Perhaps we could say all db entries have the <UDI, path>
field, and a "last known"/non-HAL location field.


That's what i'm currently doing, i store the full URI, but also the UDI and the partial path,
and in case HAL is not avaiable there is still the full URI present as a current resort.

The ideal situation would be that HAL would be always available, would have UDIs for all
volumes, and would run on all systems we need to run this to (Including let's say Solaris,
etc), in which case it would be exactly what you said, one would need to only store the volume
UDI and the partial path. Well anyway, repeating myself, just wanted to add that we also
already store the full URI as a backup.
------=_Part_3961_29338319.1150976125920-- From internalerror@gmail.com Thu Jun 22 12:04:05 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 802573B0830 for ; Thu, 22 Jun 2006 12:04:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07916-06 for ; Thu, 22 Jun 2006 12:04:01 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.201]) by menubar.gnome.org (Postfix) with ESMTP id 35C833B083F for ; Thu, 22 Jun 2006 12:01:33 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so373874wxc for ; Thu, 22 Jun 2006 09:01:32 -0700 (PDT) Received: by 10.70.83.20 with SMTP id g20mr3337015wxb; Thu, 22 Jun 2006 09:01:32 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 09:01:32 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 18:01:32 +0200 From: "Milosz Derezynski" To: "Frans Englich" Subject: Re: MLQ (Media Library Query) file format and mime type proposal In-Reply-To: <200606221419.00204.frans.englich@telia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7583_10781705.1150992092417" References: <200606221419.00204.frans.englich@telia.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.073 tagged_above=-999 required=2 tests=[AWL=0.152, BAYES_00=-2.599, HTML_30_40=0.374, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.073 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 16:04:05 -0000 ------=_Part_7583_10781705.1150992092417 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/22/06, Frans Englich wrote: > > On Thursday 22 June 2006 09:25, Milosz Derezynski wrote: > > Hi, > > > > I'm one of the main authors of BMP 2 (still being worked on), and along > the > > way of reworking our library, i came across the idea of encoding library > > queries as URIs, which may look like this: > > > > "query:///?artist=Air&album=Moon%20Safari" > > (Is that at all a valid URI? I'm not sure.) I think it is valid yes. First of all, one can't simply invent ones own URI scheme, because it causes > trouble. Especially, for such a generic name as "query". This document > discusses this further: > > http://developer.kde.org/policies/uri-guidelines.xhtml > > How is interoperability for "query" ensured? Is it specified? Not at all yet but because of that i'm asking on those 2 lists here now (xdg and gnome-multimedia), and furthermore i made some interoperability proposals, just 2 totally off my head but not totally out of place either. > BMP 2 has a plugin archicture which is a small VFS on it's own, and we > > treat certain things as "containers" (i.e. they "contain" URIs, like PLS > > playlists, XSPF, M3U, etc). > > Now i thought it might be not a bad idea to create a playlist format > with > > these query URLs, and i've called it "MLQ" for media library query. In > > theory, it's not even > > application specific. The keys (identifiers), like artist, album, etc, > are > > all based on GStreamer tag identifiers. (They could be maybe adapted to > > http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , > but > > it seems insufficient and doesn't specify certain items, like > musicbrainz > > metadata, which GST does). > > > > So i've called this file format "MLQ", with the extension .mlq, created > a > > mime package file for it: > > I think this highlights possible trouble. Anyone else who decides to > invent "query" will get detected as "Media Library Query List". All that's > needed to fix this is to use URIs properly. Yeah well that is problematic for them haha :P > However, I wouldn't invent a new URI scheme for this, it's too context > dependent. Music players & hardware(ipods, music players, music sharing > sites, and so on) is quite popular in western societies right now, but > next > year it's something different. Technologies, such as a URI scheme, > shouldn't > be hard coded on a specific use, it should be generic. > > Re-use existing technologies. There's plenty of work and research on meta > data > and querying data. Here's my suggestions: > > Express the format in XML. This has nothing to do with XML files("text"), > unless one wants to. It means the format is conceptually, on an "abstract" > level, described in XML which in turn opens up the door for all methods > XML > has. > > For example, one could use an XPointer fragment with an XPath scheme: > > file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album > = 'Safari')) > > If "music collections" cannot be located as files, invent a scheme which > can > identify them on this "abstract level." That is actually a very good idea (to use an XPath), but then again i would be abusing the file:/// scheme. What should it point to? Even if it would point to the physical location of the database file, in my specific case this would be ~/.local/share/bmpx/library.mlib, so file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz and @album='Safari')), then i would be basically still "making something up", as you cannot pass THIS uri to, say, a filemanager, and it would recognize it and do the correct thing. Now of course it won't recognize query:/// either, but i made 2 proposals which would spec query:/// in this way system wide. What i'm up to is that while your proposal with file seems more sane (and XPath/XPointer is certainly better than using a GET string, i might really consider changing the query:/// URI to use that), it actually is no different. Those kinds of file:/// URIs would need special treatment as well, and in fact, would cause even more headache possibly, as file:/// _IS_ already a known scheme which is already specced etc, etd. However, I would first assess RDF as suggested in this thread, since it is > designed exactly for things like this. Well RDF possibly, but i think i will never in my life use SPARQL. I took a look at it and i want these things if not neccessarily, then at least possibly, human editable, buit SPARQL is just way beyond the comprehension of taking a quick glance at the file and making some corrections. > > Cheers, > > Frans > -- Milosz ------=_Part_7583_10781705.1150992092417 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 6/22/06, Frans Englich <frans.englich@telia.com> wrote:
On Thursday 22 June 2006 09:25, Milosz Derezynski wrote:
> Hi,
>
> I'm one of the main authors of BMP 2 (still being worked on), and along the
> way of reworking our library, i came across the idea of encoding library
> queries as URIs, which may look like this:
>
> "query:///?artist=Air&album=Moon%20Safari"

(Is that at all a valid URI? I'm not sure.)

I think it is valid yes.

First of all, one can't simply invent ones own URI scheme, because it causes
trouble. Especially, for such a generic name as "query". This document
discusses this further:

http://developer.kde.org/policies/uri-guidelines.xhtml

How is interoperability for "query" ensured? Is it specified?

Not at all yet but  because of that i'm asking on those 2 lists here now (xdg
and gnome-multimedia), and furthermore i made some interoperability
proposals, just 2 totally off my head but not totally out of place either.
 

> BMP 2 has a plugin archicture which is a small VFS on it's own, and we
> treat certain things as "containers" (i.e. they "contain" URIs, like PLS
> playlists, XSPF, M3U, etc).
> Now i thought it might be not a bad idea to create a playlist format with
> these query URLs, and i've called it "MLQ" for media library query. In
> theory, it's not even
> application specific. The keys (identifiers), like artist, album, etc, are
> all based on GStreamer tag identifiers. (They could be maybe adapted to
> http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but
> it seems insufficient and doesn't specify certain items, like musicbrainz
> metadata, which GST does).
>
> So i've called this file format "MLQ", with the extension .mlq, created a
> mime package file for it:

I think this highlights possible trouble. Anyone else who decides to
invent "query" will get detected as "Media Library Query List". All that's
needed to fix this is to use URIs properly.

Yeah well that is problematic for them haha :P
 
However, I wouldn't invent a new URI scheme for this, it's too context
dependent. Music players & hardware(ipods, music players, music sharing
sites, and so on) is quite popular in western societies right now, but next
year it's something different. Technologies, such as a URI scheme, shouldn't
be hard coded on a specific use, it should be generic.

Re-use existing technologies. There's plenty of work and research on meta data
and querying data. Here's my suggestions:

Express the format in XML. This has nothing to do with XML files("text"),
unless one wants to. It means the format is conceptually, on an "abstract"
level, described in XML which in turn opens up the door for all methods XML
has.

For example, one could use an XPointer fragment with an XPath scheme:

file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album
= 'Safari'))

If "music collections" cannot be located as files, invent a scheme which can
identify them on this "abstract level."


That is actually a very good idea (to use an XPath), but then again i would be abusing
the file:/// scheme. What should it point to? Even if it would point to the physical location
of the database file, in my specific case this would be ~/.local/share/bmpx/library.mlib,
so file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz
and @album='Safari')), then i would be basically still "making something up", as you cannot
pass THIS uri to, say, a filemanager, and it would recognize it and do the correct thing.

Now of course it won't recognize query:/// either, but i made 2 proposals which would spec
query:/// in this way system wide.

What i'm up to is that while your proposal with file seems
more sane (and XPath/XPointer is certainly better than using a GET string, i might really
consider changing the query:/// URI to use that), it actually is no different. Those kinds of
file:/// URIs would need special treatment as well, and in fact, would cause even more headache
possibly, as file:/// _IS_ already a known scheme which is already specced etc, etd.
 

However, I would first assess RDF as suggested in this thread, since it is
designed exactly for things like this.

Well RDF possibly, but i think i will never in  my life use SPARQL. I took a look at it
and i want these things if not neccessarily, then at least possibly, human editable,
buit SPARQL is just way beyond the comprehension of taking a quick glance at the
file and making some corrections.
 

Cheers,

                Frans


-- Milosz
------=_Part_7583_10781705.1150992092417-- From internalerror@gmail.com Thu Jun 22 12:13:45 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5FD223B0389 for ; Thu, 22 Jun 2006 12:13:45 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08581-05 for ; Thu, 22 Jun 2006 12:13:43 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.205]) by menubar.gnome.org (Postfix) with ESMTP id B81413B01D2 for ; Thu, 22 Jun 2006 12:13:42 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so375754wxc for ; Thu, 22 Jun 2006 09:13:42 -0700 (PDT) Received: by 10.70.18.10 with SMTP id 10mr3379733wxr; Thu, 22 Jun 2006 09:13:42 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 09:13:41 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 18:13:41 +0200 From: "Milosz Derezynski" To: "Frans Englich" Subject: Re: MLQ (Media Library Query) file format and mime type proposal In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7734_19670285.1150992821952" References: <200606221419.00204.frans.englich@telia.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.079 tagged_above=-999 required=2 tests=[AWL=0.146, BAYES_00=-2.599, HTML_30_40=0.374, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.079 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 16:13:45 -0000 ------=_Part_7734_19670285.1150992821952 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I didn't know about tag URIs though, i'm taking a look at it now, thanks. On 6/22/06, Milosz Derezynski wrote: > > > > On 6/22/06, Frans Englich wrote: > > > > On Thursday 22 June 2006 09:25, Milosz Derezynski wrote: > > > Hi, > > > > > > I'm one of the main authors of BMP 2 (still being worked on), and > > along the > > > way of reworking our library, i came across the idea of encoding > > library > > > queries as URIs, which may look like this: > > > > > > "query:///?artist=Air&album=Moon%20Safari" > > > > (Is that at all a valid URI? I'm not sure.) > > > I think it is valid yes. > > First of all, one can't simply invent ones own URI scheme, because it > > causes > > trouble. Especially, for such a generic name as "query". This document > > discusses this further: > > > > http://developer.kde.org/policies/uri-guidelines.xhtml > > > > How is interoperability for "query" ensured? Is it specified? > > > Not at all yet but because of that i'm asking on those 2 lists here now > (xdg > and gnome-multimedia), and furthermore i made some interoperability > proposals, just 2 totally off my head but not totally out of place either. > > > > BMP 2 has a plugin archicture which is a small VFS on it's own, and we > > > treat certain things as "containers" (i.e. they "contain" URIs, like > > PLS > > > playlists, XSPF, M3U, etc). > > > Now i thought it might be not a bad idea to create a playlist format > > with > > > these query URLs, and i've called it "MLQ" for media library query. In > > > theory, it's not even > > > application specific. The keys (identifiers), like artist, album, etc, > > are > > > all based on GStreamer tag identifiers. (They could be maybe adapted > > to > > > http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , > > but > > > it seems insufficient and doesn't specify certain items, like > > musicbrainz > > > metadata, which GST does). > > > > > > So i've called this file format "MLQ", with the extension .mlq, > > created a > > > mime package file for it: > > > > I think this highlights possible trouble. Anyone else who decides to > > invent "query" will get detected as "Media Library Query List". All > > that's > > needed to fix this is to use URIs properly. > > > Yeah well that is problematic for them haha :P > > > > However, I wouldn't invent a new URI scheme for this, it's too context > > dependent. Music players & hardware(ipods, music players, music sharing > > sites, and so on) is quite popular in western societies right now, but > > next > > year it's something different. Technologies, such as a URI scheme, > > shouldn't > > be hard coded on a specific use, it should be generic. > > > > Re-use existing technologies. There's plenty of work and research on > > meta data > > and querying data. Here's my suggestions: > > > > Express the format in XML. This has nothing to do with XML > > files("text"), > > unless one wants to. It means the format is conceptually, on an > > "abstract" > > level, described in XML which in turn opens up the door for all methods > > XML > > has. > > > > For example, one could use an XPointer fragment with an XPath scheme: > > > > file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album > > = 'Safari')) > > > > If "music collections" cannot be located as files, invent a scheme which > > can > > identify them on this "abstract level." > > > > That is actually a very good idea (to use an XPath), but then again i > would be abusing > the file:/// scheme. What should it point to? Even if it would point to > the physical location > of the database file, in my specific case this would be > ~/.local/share/bmpx/library.mlib, > so file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz > > and @album='Safari')), then i would be basically still "making something > up", as you cannot > pass THIS uri to, say, a filemanager, and it would recognize it and do the > correct thing. > > Now of course it won't recognize query:/// either, but i made 2 proposals > which would spec > query:/// in this way system wide. > > What i'm up to is that while your proposal with file seems > more sane (and XPath/XPointer is certainly better than using a GET string, > i might really > consider changing the query:/// URI to use that), it actually is no > different. Those kinds of > file:/// URIs would need special treatment as well, and in fact, would > cause even more headache > possibly, as file:/// _IS_ already a known scheme which is already specced > etc, etd. > > > However, I would first assess RDF as suggested in this thread, since it is > > designed exactly for things like this. > > > Well RDF possibly, but i think i will never in my life use SPARQL. I took > a look at it > and i want these things if not neccessarily, then at least possibly, human > editable, > buit SPARQL is just way beyond the comprehension of taking a quick glance > at the > file and making some corrections. > > > > > > Cheers, > > > > Frans > > > > > -- Milosz > ------=_Part_7734_19670285.1150992821952 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I didn't know about tag URIs though, i'm taking a look at it now, thanks.

On 6/22/06, Milosz Derezynski <internalerror@gmail.com > wrote:


On 6/22/06, Frans Englich <frans.englich@telia.com> wrote:
On Thursday 22 June 2006 09:25, Milosz Derezynski wrote:
> Hi,
>
> I'm one of the main authors of BMP 2 (still being worked on), and along the
> way of reworking our library, i came across the idea of encoding library
> queries as URIs, which may look like this:
>
> "query:///?artist=Air&album=Moon%20Safari"

(Is that at all a valid URI? I'm not sure.)

I think it is valid yes.

First of all, one can't simply invent ones own URI scheme, because it causes
trouble. Especially, for such a generic name as "query". This document
discusses this further:

http://developer.kde.org/policies/uri-guidelines.xhtml

How is interoperability for "query" ensured? Is it specified?

Not at all yet but  because of that i'm asking on those 2 lists here now (xdg
and gnome-multimedia), and furthermore i made some interoperability
proposals, just 2 totally off my head but not totally out of place either.
 

> BMP 2 has a plugin archicture which is a small VFS on it's own, and we
> treat certain things as "containers" (i.e. they "contain" URIs, like PLS
> playlists, XSPF, M3U, etc).
> Now i thought it might be not a bad idea to create a playlist format with
> these query URLs, and i've called it "MLQ" for media library query. In
> theory, it's not even
> application specific. The keys (identifiers), like artist, album, etc, are
> all based on GStreamer tag identifiers. (They could be maybe adapted to
> http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but
> it seems insufficient and doesn't specify certain items, like musicbrainz
> metadata, which GST does).
>
> So i've called this file format "MLQ", with the extension .mlq, created a
> mime package file for it:

I think this highlights possible trouble. Anyone else who decides to
invent "query" will get detected as "Media Library Query List". All that's
needed to fix this is to use URIs properly.

Yeah well that is problematic for them haha :P
 
However, I wouldn't invent a new URI scheme for this, it's too context
dependent. Music players & hardware(ipods, music players, music sharing
sites, and so on) is quite popular in western societies right now, but next
year it's something different. Technologies, such as a URI scheme, shouldn't
be hard coded on a specific use, it should be generic.

Re-use existing technologies. There's plenty of work and research on meta data
and querying data. Here's my suggestions:

Express the format in XML. This has nothing to do with XML files("text"),
unless one wants to. It means the format is conceptually, on an "abstract"
level, described in XML which in turn opens up the door for all methods XML
has.

For example, one could use an XPointer fragment with an XPath scheme:

file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album
= 'Safari'))

If "music collections" cannot be located as files, invent a scheme which can
identify them on this "abstract level."


That is actually a very good idea (to use an XPath), but then again i would be abusing
the file:/// scheme. What should it point to? Even if it would point to the physical location
of the database file, in my specific case this would be ~/.local/share/bmpx/library.mlib,
so file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz
and @album='Safari')), then i would be basically still "making something up", as you cannot
pass THIS uri to, say, a filemanager, and it would recognize it and do the correct thing.

Now of course it won't recognize query:/// either, but i made 2 proposals which would spec
query:/// in this way system wide.

What i'm up to is that while your proposal with file seems
more sane (and XPath/XPointer is certainly better than using a GET string, i might really
consider changing the query:/// URI to use that), it actually is no different. Those kinds of
file:/// URIs would need special treatment as well, and in fact, would cause even more headache
possibly, as file:/// _IS_ already a known scheme which is already specced etc, etd.
 

However, I would first assess RDF as suggested in this thread, since it is
designed exactly for things like this.

Well RDF possibly, but i think i will never in  my life use SPARQL. I took a look at it
and i want these things if not neccessarily, then at least possibly, human editable,
buit SPARQL is just way beyond the comprehension of taking a quick glance at the
file and making some corrections.
 

Cheers,

                Frans


-- Milosz

------=_Part_7734_19670285.1150992821952-- From frans.englich@telia.com Thu Jun 22 10:05:56 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 164263B085B for ; Thu, 22 Jun 2006 10:05:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00797-01 for ; Thu, 22 Jun 2006 10:05:48 -0400 (EDT) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by menubar.gnome.org (Postfix) with ESMTP id 4FFD63B081B for ; Thu, 22 Jun 2006 10:05:38 -0400 (EDT) X-T2-Posting-ID: 2yF4ydxc0UI9xI7FHZPfog== X-Cloudmark-Score: 0.000000 [] Received: from 83.72.134.122.ip.tele2adsl.dk ([83.72.134.122] verified) by mailfe08.swip.net (CommuniGate Pro SMTP 5.0.8) with ESMTP id 217821068; Thu, 22 Jun 2006 16:05:36 +0200 From: Frans Englich To: xdg@lists.freedesktop.org Subject: Re: MLQ (Media Library Query) file format and mime type proposal Date: Thu, 22 Jun 2006 14:18:59 +0000 User-Agent: KMail/1.8.50 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606221419.00204.frans.englich@telia.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.051 tagged_above=-999 required=2 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_NUMERIC_HELO=1.5] X-Spam-Score: -1.051 X-Spam-Level: X-Mailman-Approved-At: Thu, 22 Jun 2006 12:45:56 -0400 Cc: gnome-multimedia@gnome.org, Milosz Derezynski X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 14:05:56 -0000 On Thursday 22 June 2006 09:25, Milosz Derezynski wrote: > Hi, > > I'm one of the main authors of BMP 2 (still being worked on), and along the > way of reworking our library, i came across the idea of encoding library > queries as URIs, which may look like this: > > "query:///?artist=Air&album=Moon%20Safari" (Is that at all a valid URI? I'm not sure.) First of all, one can't simply invent ones own URI scheme, because it causes trouble. Especially, for such a generic name as "query". This document discusses this further: http://developer.kde.org/policies/uri-guidelines.xhtml How is interoperability for "query" ensured? Is it specified? > BMP 2 has a plugin archicture which is a small VFS on it's own, and we > treat certain things as "containers" (i.e. they "contain" URIs, like PLS > playlists, XSPF, M3U, etc). > Now i thought it might be not a bad idea to create a playlist format with > these query URLs, and i've called it "MLQ" for media library query. In > theory, it's not even > application specific. The keys (identifiers), like artist, album, etc, are > all based on GStreamer tag identifiers. (They could be maybe adapted to > http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but > it seems insufficient and doesn't specify certain items, like musicbrainz > metadata, which GST does). > > So i've called this file format "MLQ", with the extension .mlq, created a > mime package file for it: I think this highlights possible trouble. Anyone else who decides to invent "query" will get detected as "Media Library Query List". All that's needed to fix this is to use URIs properly. However, I wouldn't invent a new URI scheme for this, it's too context dependent. Music players & hardware(ipods, music players, music sharing sites, and so on) is quite popular in western societies right now, but next year it's something different. Technologies, such as a URI scheme, shouldn't be hard coded on a specific use, it should be generic. Re-use existing technologies. There's plenty of work and research on meta data and querying data. Here's my suggestions: Express the format in XML. This has nothing to do with XML files("text"), unless one wants to. It means the format is conceptually, on an "abstract" level, described in XML which in turn opens up the door for all methods XML has. For example, one could use an XPointer fragment with an XPath scheme: file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album = 'Safari')) If "music collections" cannot be located as files, invent a scheme which can identify them on this "abstract level." However, I would first assess RDF as suggested in this thread, since it is designed exactly for things like this. In this way one doesn't have to invent a whole query language for music files. That's like inventing C++ for writing games, C++ for fixing bugs in word processors, C++ for writing editors, and so on. Cheers, Frans From internalerror@gmail.com Thu Jun 22 13:17:35 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 614C33B0693 for ; Thu, 22 Jun 2006 13:17:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12677-02 for ; Thu, 22 Jun 2006 13:17:34 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.201]) by menubar.gnome.org (Postfix) with ESMTP id 0CBD83B06C8 for ; Thu, 22 Jun 2006 13:17:33 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so385228wxc for ; Thu, 22 Jun 2006 10:17:33 -0700 (PDT) Received: by 10.70.110.18 with SMTP id i18mr3484207wxc; Thu, 22 Jun 2006 10:17:33 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 10:17:33 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 19:17:33 +0200 From: "Milosz Derezynski" To: "Frans Englich" Subject: Re: MLQ (Media Library Query) file format and mime type proposal In-Reply-To: <200606221419.00204.frans.englich@telia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8538_10618378.1150996653355" References: <200606221419.00204.frans.englich@telia.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.272 tagged_above=-999 required=2 tests=[AWL=0.327, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.272 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 17:17:35 -0000 ------=_Part_8538_10618378.1150996653355 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/22/06, Frans Englich wrote: > > On Thursday 22 June 2006 09:25, Milosz Derezynski wrote: > > I think this highlights possible trouble. Anyone else who decides to > invent "query" will get detected as "Media Library Query List". All that's > needed to fix this is to use URIs properly. > I've changed the file magic so that the first line has to be "#MLQ", and our MLQ exporter writes them like that and recognizes them only like that, and i've updated the mime XML spec to recognize them this way. This is no better or worse than "#EXTM3U" for .m3u playlists, so i don't think there is any problem here now. As for the URIs themselves, i wasn't yet speaking of "open" use of them (outside of .mlq files), but only within them, so this change of the file magic should prevent problems with anything else that might use a query:/// URI in their file formats. -- Milosz ------=_Part_8538_10618378.1150996653355 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 6/22/06, Frans Englich <frans.englich@telia.com> wrote:
On Thursday 22 June 2006 09:25, Milosz Derezynski wrote:

I think this highlights possible trouble. Anyone else who decides to
invent "query" will get detected as "Media Library Query List". All that's
needed to fix this is to use URIs properly.

I've changed the file magic so that the first line has to be "#MLQ", and our
MLQ exporter writes them like that and recognizes them only like that, and i've
updated the mime XML spec to recognize them this way.  This is no better or worse than
"#EXTM3U" for .m3u playlists, so i don't think there is any problem here now.
As for the URIs themselves, i wasn't yet speaking of "open" use of them (outside of .mlq files),
but only within them, so this change of the file magic should prevent problems with
anything else that might use a query:/// URI in their file formats.

-- Milosz
------=_Part_8538_10618378.1150996653355-- From doclivingston@gmail.com Wed Jun 7 10:49:16 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6DFBE3B0CC1 for ; Wed, 7 Jun 2006 10:49:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21939-01 for ; Wed, 7 Jun 2006 10:49:15 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.229]) by menubar.gnome.org (Postfix) with ESMTP id D14723B03C1 for ; Wed, 7 Jun 2006 10:49:14 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id 50so195010wri for ; Wed, 07 Jun 2006 07:49:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:reply-to:to:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=D3/oYUbzoxrxaC8A9PmKhslTLvhndfLfj1yY1UbjWdxPLOVTGGtYcu0ciGotAkdC9rpqkdcPnVZMxJ6dpbOroKn3+pabYkPihqGfxJAljTjii14F9PbbIilMLHmiNyw9SX693UyHiryeZOKfQoct7i10NaO3a8zimwOM5qcjmis= Received: by 10.65.232.13 with SMTP id j13mr502626qbr; Wed, 07 Jun 2006 07:49:14 -0700 (PDT) Received: from alyrion.local ( [144.139.19.99]) by mx.gmail.com with ESMTP id e14sm242982qba.2006.06.07.07.49.12; Wed, 07 Jun 2006 07:49:14 -0700 (PDT) From: "James \"Doc\" Livingston" To: gnome-multimedia@gnome.org Content-Type: text/plain Date: Thu, 08 Jun 2006 00:49:05 +1000 Message-Id: <1149691745.5417.19.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.309 tagged_above=-999 required=2 tests=[AWL=0.291, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.309 X-Spam-Level: Subject: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: doclivingston@gmail.com List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 14:49:16 -0000 G'day everyone, Currently various multi-media application behave differently when the "scrolling" (up/down arrow, page up/down mouse wheel) actions are performed on their seek slider. There have been bugs (at least 164351 and 330570) filed against several applications asking that they behave like others, and it would be good to have consistent behaviour. Essentially the questions is what should happen when the user performs these actions? Should the "up" actions seek forward in time, seek back in time, or do nothing? Currently Totem and Gnome Sound Recorder map "up" to seek forwards in time, Sound-Juicer and Rhythmbox map "up" to seek back in time, and Banshee and Muine don't seek when the user does this. Which is correct is a matter of debate, and when I started a discussion about this on #gnome-hackers (which obviously isn't filled with "average users") a while back, people seemed to be split roughly equally between the options. Some of the point for up=forwards are: * people associate up with increasing the time from the start Some of the point for up=backwards are: * people associate up with increasing the time remaining (only applicable if it's shown to the user) * people associate up with "going towards the start", like for documents/web pages Some of the point for taking no action: * these are "vertical" scroll events and the slider is horizontal, so should do nothing Regardless of which is generally considered "best", I think having it consistent between application is important. Cheers, James "Doc" Livingston -- [Request for the names of the kings who became Nazgul] Dashur, Daensir, Prantsur, Vicksinn, Comuet, Cupuid, Dondor, Blitsun, and Rodulf, Witch-King of Angmar. -- Joseph Michael Bay From hadess@hadess.net Wed Jun 7 10:58:17 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 067753B0272 for ; Wed, 7 Jun 2006 10:58:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22613-04 for ; Wed, 7 Jun 2006 10:58:16 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id EA5A23B03C4 for ; Wed, 7 Jun 2006 10:58:15 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57EwBfm003839; Wed, 7 Jun 2006 10:58:11 -0400 Received: from pobox.surrey.redhat.com (pobox.surrey.redhat.com [172.16.10.17]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57EwASg001552; Wed, 7 Jun 2006 10:58:10 -0400 Received: from bnocera.surrey.redhat.com (bnocera.surrey.redhat.com [172.16.10.53]) by pobox.surrey.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57Ew9om000601; Wed, 7 Jun 2006 15:58:09 +0100 From: Bastien Nocera To: doclivingston@gmail.com In-Reply-To: <1149691745.5417.19.camel@localhost.localdomain> References: <1149691745.5417.19.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8 Date: Wed, 07 Jun 2006 15:58:09 +0100 Message-Id: <1149692289.14668.24.camel@bnocera.surrey.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-27) Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.954 tagged_above=-999 required=2 tests=[AWL=-0.496, BAYES_00=-2.599, SPF_FAIL=1.142, SPF_HELO_PASS=-0.001] X-Spam-Score: -1.954 X-Spam-Level: Cc: gnome-multimedia@gnome.org Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 14:58:17 -0000 On Thu, 2006-06-08 at 00:49 +1000, James "Doc" Livingston wrote: > G'day everyone, > Essentially the questions is what should happen when the user performs > these actions? Should the "up" actions seek forward in time, seek back > in time, or do nothing? Same problem for the volume sliders by default. Obviously, I think that apps should seek forward in time with up, and backwards with down. And I also think that when scrolling down, the step should be shorter than when moving forward (because it makes it easier to find precise points in the timeline). Maybe we need to move things like the volume widget, and some "seek sliders" to a library like gnome-media? -- Bastien Nocera If I'm not challenged, I can do nothing. Maybe my next film will be in Japanese. -- Alejandro González Iñárittu From abockover@novell.com Wed Jun 7 11:08:04 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C6EB33B022D for ; Wed, 7 Jun 2006 11:08:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23164-09 for ; Wed, 7 Jun 2006 11:08:04 -0400 (EDT) Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.25.9.101]) by menubar.gnome.org (Postfix) with ESMTP id B3F5E3B0127 for ; Wed, 7 Jun 2006 11:08:03 -0400 (EDT) Received: from [192.168.0.101] (cpe-024-162-230-116.nc.res.rr.com [24.162.230.116]) by ms-smtp-02.southeast.rr.com (8.13.6/8.13.6) with ESMTP id k57F7xLC012187; Wed, 7 Jun 2006 11:07:59 -0400 (EDT) From: Aaron Bockover To: doclivingston@gmail.com In-Reply-To: <1149691745.5417.19.camel@localhost.localdomain> References: <1149691745.5417.19.camel@localhost.localdomain> Content-Type: text/plain Date: Wed, 07 Jun 2006 11:04:47 -0400 Message-Id: <1149692687.14205.10.camel@sledipus.rex> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.472 tagged_above=-999 required=2 tests=[AWL=-0.073, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2] X-Spam-Score: -2.472 X-Spam-Level: Cc: gnome-multimedia@gnome.org Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 15:08:05 -0000 On Thu, 2006-06-08 at 00:49 +1000, James "Doc" Livingston wrote: > Currently various multi-media application behave differently when the > "scrolling" (up/down arrow, page up/down mouse wheel) actions are > performed on their seek slider. There have been bugs (at least 164351 > and 330570) filed against several applications asking that they behave > like others, and it would be good to have consistent behaviour. Agreed. > Currently Totem and Gnome Sound Recorder map "up" to seek forwards in > time, Sound-Juicer and Rhythmbox map "up" to seek back in time, and > Banshee and Muine don't seek when the user does this. Banshee (and Muine?) seeks on CTRL+Left/Right. > Some of the point for up=forwards are: > * people associate up with increasing the time from the start > Time is usually displayed on the X axis... sliders for seeking are usually horizontal... so Up/Down keys for this mess with my mind > Some of the point for up=backwards are: > * people associate up with increasing the time remaining (only > applicable if it's shown to the user) > * people associate up with "going towards the start", like for > documents/web pages Again, for me it's more literal connection with visual objects... if I press the right arrow, I am scrolling my time graph "into the future." Volume is my Y axis. > Some of the point for taking no action: > * these are "vertical" scroll events and the slider is horizontal, so > should do nothing I don't think this is should be a no-action case. I think representations just should be "on-axis" (of course feelings are going to differ, this are just how I interpret position) >From a more technical (and possibly usability) standpoint, my objection to up/down is that it's used by and is more important to other widgets (our track views in Banshee/RB), meaning the slider needs focus for the keys to actually seek. In Banshee you can press CTRL+Left/Right anywhere and it seeks. Cheers, Aaron From rbultje@ronald.bitfreak.net Wed Jun 7 11:46:19 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3D92F3B04A2 for ; Wed, 7 Jun 2006 11:46:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26037-06 for ; Wed, 7 Jun 2006 11:46:15 -0400 (EDT) Received: from ms-smtp-01.rdc-nyc.rr.com (ms-smtp-01.rdc-nyc.rr.com [24.29.109.5]) by menubar.gnome.org (Postfix) with ESMTP id 8B1693B022D for ; Wed, 7 Jun 2006 11:46:15 -0400 (EDT) Received: from [192.168.0.103] (cpe-66-65-0-167.nyc.res.rr.com [66.65.0.167]) by ms-smtp-01.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id k57Fk2jY021579; Wed, 7 Jun 2006 11:46:13 -0400 (EDT) From: "Ronald S. Bultje" To: Bastien Nocera In-Reply-To: <1149692289.14668.24.camel@bnocera.surrey.redhat.com> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> Content-Type: text/plain Date: Wed, 07 Jun 2006 11:44:22 -0400 Message-Id: <1149695062.2855.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.561 tagged_above=-999 required=2 tests=[AWL=0.038, BAYES_00=-2.599] X-Spam-Score: -2.561 X-Spam-Level: Cc: gnome-multimedia@gnome.org Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 15:46:19 -0000 On Wed, 2006-06-07 at 15:58 +0100, Bastien Nocera wrote: > Maybe we need to move things like the volume widget, and some "seek > sliders" to a library like gnome-media? I would personally prefer libegg (or bacon, where the volume widget resides). I've never really seen gnome-media as a widget-library, but more like a bunch of applications and utilities. I totally don't mind each app making their own copy if such widgets, as long as they update their copy reasonably often. Cheers, Ronald From abockover@novell.com Wed Jun 7 11:58:56 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D43973B0411 for ; Wed, 7 Jun 2006 11:58:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26954-08 for ; Wed, 7 Jun 2006 11:58:56 -0400 (EDT) Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.25.9.101]) by menubar.gnome.org (Postfix) with ESMTP id 120B23B0D4B for ; Wed, 7 Jun 2006 11:58:56 -0400 (EDT) Received: from [192.168.0.101] (cpe-024-162-230-116.nc.res.rr.com [24.162.230.116]) by ms-smtp-02.southeast.rr.com (8.13.6/8.13.6) with ESMTP id k57FwrFL000910; Wed, 7 Jun 2006 11:58:54 -0400 (EDT) From: Aaron Bockover To: "Ronald S. Bultje" In-Reply-To: <1149695062.2855.2.camel@localhost.localdomain> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> <1149695062.2855.2.camel@localhost.localdomain> Content-Type: text/plain Date: Wed, 07 Jun 2006 11:55:41 -0400 Message-Id: <1149695742.15592.1.camel@sledipus.rex> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.473 tagged_above=-999 required=2 tests=[AWL=-0.074, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2] X-Spam-Score: -2.473 X-Spam-Level: Cc: gnome-multimedia@gnome.org, Bastien Nocera Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 15:58:57 -0000 On Wed, 2006-06-07 at 11:44 -0400, Ronald S. Bultje wrote: > On Wed, 2006-06-07 at 15:58 +0100, Bastien Nocera wrote: > > Maybe we need to move things like the volume widget, and some "seek > > sliders" to a library like gnome-media? > > I would personally prefer libegg (or bacon, where the volume widget > resides). I've never really seen gnome-media as a widget-library, but > more like a bunch of applications and utilities. > > I totally don't mind each app making their own copy if such widgets, as > long as they update their copy reasonably often. I agree here; bacon would probably be best if it were to be in a library, but I think applications providing copies is fine too. I wouldn't want to depend on bacon (or gnome-media) for a widget. --Aaron From hadess@hadess.net Wed Jun 7 12:02:02 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 001A03B0DF9 for ; Wed, 7 Jun 2006 12:02:02 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27399-05 for ; Wed, 7 Jun 2006 12:01:59 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 9822B3B0E10 for ; Wed, 7 Jun 2006 12:00:49 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57G0nE9001971; Wed, 7 Jun 2006 12:00:49 -0400 Received: from pobox.surrey.redhat.com (pobox.surrey.redhat.com [172.16.10.17]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57G0mZE021228; Wed, 7 Jun 2006 12:00:48 -0400 Received: from bnocera.surrey.redhat.com (bnocera.surrey.redhat.com [172.16.10.53]) by pobox.surrey.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57G0lTo006172; Wed, 7 Jun 2006 17:00:47 +0100 From: Bastien Nocera To: Aaron Bockover In-Reply-To: <1149695742.15592.1.camel@sledipus.rex> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> <1149695062.2855.2.camel@localhost.localdomain> <1149695742.15592.1.camel@sledipus.rex> Content-Type: text/plain Date: Wed, 07 Jun 2006 17:00:47 +0100 Message-Id: <1149696047.14668.35.camel@bnocera.surrey.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-27) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.953 tagged_above=-999 required=2 tests=[AWL=-0.495, BAYES_00=-2.599, SPF_FAIL=1.142, SPF_HELO_PASS=-0.001] X-Spam-Score: -1.953 X-Spam-Level: Cc: "Ronald S. Bultje" , gnome-multimedia@gnome.org Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 16:02:02 -0000 On Wed, 2006-06-07 at 11:55 -0400, Aaron Bockover wrote: > On Wed, 2006-06-07 at 11:44 -0400, Ronald S. Bultje wrote: > > On Wed, 2006-06-07 at 15:58 +0100, Bastien Nocera wrote: > > > Maybe we need to move things like the volume widget, and some "seek > > > sliders" to a library like gnome-media? > > > > I would personally prefer libegg (or bacon, where the volume widget > > resides). I've never really seen gnome-media as a widget-library, but > > more like a bunch of applications and utilities. > > > > I totally don't mind each app making their own copy if such widgets, as > > long as they update their copy reasonably often. > > I agree here; bacon would probably be best if it were to be in a > library, but I think applications providing copies is fine too. I > wouldn't want to depend on bacon (or gnome-media) for a widget. libbacon is a cut'n'paste library like libegg, so not a problem. -- Bastien Nocera Lucas has made a vacuous, boring, pretentious, retroactively destructive sequel. He has lost the plot. The man is a fool. -- Simon Pegg (on the Phantom Menace) From uraeus@linuxrising.org Fri Jun 9 10:13:15 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 91BCF3B01D8 for ; Fri, 9 Jun 2006 10:13:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29942-03 for ; Fri, 9 Jun 2006 10:13:14 -0400 (EDT) Received: from mx1.es6.egwn.net (server02.es6.egwn.net [195.10.6.12]) by menubar.gnome.org (Postfix) with ESMTP id E0C263B01BE for ; Fri, 9 Jun 2006 10:13:13 -0400 (EDT) Received: from [192.168.1.235] (core.fluendo.com [195.10.6.237]) by mx1.es6.egwn.net (Postfix) with ESMTP id 9E4AC4F81BC; Fri, 9 Jun 2006 16:13:11 +0200 (CEST) From: Christian Fredrik Kalager Schaller To: Bastien Nocera In-Reply-To: <1149696047.14668.35.camel@bnocera.surrey.redhat.com> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> <1149695062.2855.2.camel@localhost.localdomain> <1149695742.15592.1.camel@sledipus.rex> <1149696047.14668.35.camel@bnocera.surrey.redhat.com> Content-Type: text/plain Date: Fri, 09 Jun 2006 16:11:58 +0200 Message-Id: <1149862318.2356.36.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.397 tagged_above=-999 required=2 tests=[AWL=1.202, BAYES_00=-2.599] X-Spam-Score: -1.397 X-Spam-Level: Cc: "Ronald S. Bultje" , gnome-multimedia@gnome.org Subject: a general multimedia library - Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 14:13:15 -0000 Well the topic of having a multimedia widget library has been discussed multiple times and maybe now is the time to move on it? Currently there are multiple things I see that would be natural to put into such a library: a) the gconf schemas in gnome-media b) the playlist parser library in totem c) the seek sliders widgets mentioned here d) a simple to use GStreamer GTK+ video widget e) others things? Basically this library would/could contain things which are higher level our not directly in the scope of GStreamer. Or which is very GTK+/GNOME related. Christian On Wed, 2006-06-07 at 17:00 +0100, Bastien Nocera wrote: > On Wed, 2006-06-07 at 11:55 -0400, Aaron Bockover wrote: > > On Wed, 2006-06-07 at 11:44 -0400, Ronald S. Bultje wrote: > > > On Wed, 2006-06-07 at 15:58 +0100, Bastien Nocera wrote: > > > > Maybe we need to move things like the volume widget, and some "seek > > > > sliders" to a library like gnome-media? > > > > > > I would personally prefer libegg (or bacon, where the volume widget > > > resides). I've never really seen gnome-media as a widget-library, but > > > more like a bunch of applications and utilities. > > > > > > I totally don't mind each app making their own copy if such widgets, as > > > long as they update their copy reasonably often. > > > > I agree here; bacon would probably be best if it were to be in a > > library, but I think applications providing copies is fine too. I > > wouldn't want to depend on bacon (or gnome-media) for a widget. > > libbacon is a cut'n'paste library like libegg, so not a problem. > From rbultje@ronald.bitfreak.net Fri Jun 9 10:47:45 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B71663B0413 for ; Fri, 9 Jun 2006 10:47:45 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32342-10 for ; Fri, 9 Jun 2006 10:47:42 -0400 (EDT) Received: from ms-smtp-03.rdc-nyc.rr.com (ms-smtp-03.rdc-nyc.rr.com [24.29.109.7]) by menubar.gnome.org (Postfix) with ESMTP id 215673B0FF1 for ; Fri, 9 Jun 2006 10:47:42 -0400 (EDT) Received: from [192.168.0.103] (cpe-66-65-0-167.nyc.res.rr.com [66.65.0.167]) by ms-smtp-03.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id k59Eld9O019647; Fri, 9 Jun 2006 10:47:40 -0400 (EDT) From: "Ronald S. Bultje" To: Christian Fredrik Kalager Schaller In-Reply-To: <1149862318.2356.36.camel@localhost.localdomain> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> <1149695062.2855.2.camel@localhost.localdomain> <1149695742.15592.1.camel@sledipus.rex> <1149696047.14668.35.camel@bnocera.surrey.redhat.com> <1149862318.2356.36.camel@localhost.localdomain> Content-Type: text/plain Date: Fri, 09 Jun 2006 10:46:01 -0400 Message-Id: <1149864361.2869.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.563 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599] X-Spam-Score: -2.563 X-Spam-Level: Cc: gnome-multimedia@gnome.org, Bastien Nocera Subject: Re: a general multimedia library - Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 14:47:45 -0000 Hi, On Fri, 2006-06-09 at 16:11 +0200, Christian Fredrik Kalager Schaller wrote: > Well the topic of having a multimedia widget library has been discussed > multiple times and maybe now is the time to move on it? If someone believes that this would be useful and should be done, then that person should go ahead and do it. Ronald From thomas@apestaart.org Fri Jun 9 15:11:02 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 78FFA3B00E9 for ; Fri, 9 Jun 2006 15:11:02 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15077-08 for ; Fri, 9 Jun 2006 15:11:01 -0400 (EDT) Received: from mx1.es6.egwn.net (server02.es6.egwn.net [195.10.6.12]) by menubar.gnome.org (Postfix) with ESMTP id E94F03B0149 for ; Fri, 9 Jun 2006 15:11:00 -0400 (EDT) Received: from mx1.fr4.egwn.net (server07.fr4.egwn.net [62.39.85.77]) by mx1.es6.egwn.net (Postfix) with ESMTP id 0FC914F822C; Fri, 9 Jun 2006 21:10:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mx1.fr4.egwn.net (spiffy mail daemon) with ESMTP id CB4CC83BFD; Fri, 9 Jun 2006 21:10:47 +0200 (CEST) Received: from mx1.fr4.egwn.net ([127.0.0.1]) by localhost (server07.fr4.egwn.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22095-43; Fri, 9 Jun 2006 21:10:47 +0200 (CEST) Received: from thread.fluendo.lan (core.fluendo.com [195.10.6.237]) by mx1.fr4.egwn.net (spiffy mail daemon) with ESMTP id D8A3283BF8; Fri, 9 Jun 2006 21:10:46 +0200 (CEST) Received: from otto.amantes (thomas.fluendo.lan [192.168.1.10]) by thread.fluendo.lan (Postfix) with ESMTP id 8DDD1FE93; Fri, 9 Jun 2006 21:10:57 +0200 (CEST) Received: from otto.amantes (otto.amantes [127.0.0.1]) by otto.amantes (Postfix) with ESMTP id 9B95DEFC0D; Fri, 9 Jun 2006 21:11:00 +0200 (CEST) Content-Type: multipart/mixed; boundary="127.0.0.1.500.4863.1149880260.533.2" MIME-Version: 1.0 To: gstreamer-devel@lists.sourceforge.net, gstreamer-announce@lists.sourceforge.net, kde-multimedia@kde.org, gnome-multimedia@gnome.org Message-Id: <20060609191100.9B95DEFC0D@otto.amantes> Date: Fri, 9 Jun 2006 21:11:00 +0200 (CEST) From: thomas@apestaart.org X-Scanned: By amavis at egwn.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: Yes, score=2.06 tagged_above=-999 required=2 tests=[AWL=-1.482, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, MIME_BASE64_TEXT=1.885, NO_REAL_NAME=0.961, RCVD_IN_SBL=3.16] X-Spam-Score: 2.06 X-Spam-Level: ** X-Spam-Flag: YES Cc: Subject: RELEASE: GStreamer 0.10.7 'Soepeke, ik zie ou' X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 19:11:02 -0000 --127.0.0.1.500.4863.1149880260.533.2 Content-Type: text/plain This mail announces the release of GStreamer 0.10.7 'Soepeke, ik zie ou'. GStreamer is a streaming media framework that allows the construction of graphs of elements which operate on media data. Applications using this library can do anything from real-time sound processing over playing video to capturing audio, video, and even other types of media data. Its architecture allows for adding new data types or processing capabilities simply by installing new plug-ins. GStreamer is the core module, containing libraries, headers, the basic object hierarchy, and a set of media-agnostic core elements. For more information, see [http://gstreamer.freedesktop.org/modules/gstreamer.html] To file bugs, go to [http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer&component=gstreamer+%28core%29] --127.0.0.1.500.4863.1149880260.533.2 Content-Type: text/plain; name=RELEASE Content-Transfer-Encoding: base64 ClJlbGVhc2Ugbm90ZXMgZm9yIEdTdHJlYW1lcsKgMC4xMC43ICJTb2VwZWtlLCBpayB6aWUgb3Ui CiAgICAgICAgCgoKVGhlIEdTdHJlYW1lciB0ZWFtIGlzIHByb3VkIHRvIGFubm91bmNlIGEgbmV3 IHJlbGVhc2UKaW4gdGhlIDAuMTAueCBzdGFibGUgc2VyaWVzIG9mIHRoZQpjb3JlIG9mIHRoZSBH U3RyZWFtZXIgc3RyZWFtaW5nIG1lZGlhIGZyYW1ld29yay4KCgpUaGUgMC4xMC54IHNlcmllcyBp cyBhIHN0YWJsZSBzZXJpZXMgdGFyZ2V0ZWQgYXQgZW5kIHVzZXJzLgpJdCBpcyBub3QgQVBJIG9y IEFCSSBjb21wYXRpYmxlIHdpdGggdGhlIHN0YWJsZSAwLjgueCBzZXJpZXMuCkl0IGlzLCBob3dl dmVyLCBwYXJhbGxlbCBpbnN0YWxsYWJsZSB3aXRoIHRoZSAwLjgueCBzZXJpZXMuCgoKVGhlIDAu MTAueCBzZXJpZXMgaGFzIGJlZW4gcmV3b3JrZWQgZm9yIHRocmVhZHNhZmV0eS4gIEl0IGFsc28g ZmVhdHVyZXMKdmFyaW91cyBmZWF0dXJlIGFkZGl0aW9ucyBhbmQgZW5jaGFuY2VtZW50cy4KCgpU aGlzIG1vZHVsZSwgZ3N0cmVhbWVyLCBvbmx5IGNvbnRhaW5zIGNvcmUgZnVuY3Rpb25hbGl0eS4K Rm9yIGFjdHVhbCBtZWRpYSBwbGF5YmFjaywgeW91IHdpbGwgbmVlZCBvdGhlciBtb2R1bGVzLgoK Z3N0LXBsdWdpbnMtYmFzZQpjb250YWlucyBhIGJhc2ljIHNldCBvZiB3ZWxsLXN1cHBvcnRlZCBw bHVnLWlucwpnc3QtcGx1Z2lucy1nb29kCmNvbnRhaW5zIGEgc2V0IG9mIHdlbGwtc3VwcG9ydGVk IHBsdWctaW5zIHVuZGVyIG91ciBwcmVmZXJyZWQgbGljZW5zZQpnc3QtcGx1Z2lucy11Z2x5CmNv bnRhaW5zIGEgc2V0IG9mIHdlbGwtc3VwcG9ydGVkIHBsdWctaW5zLCBidXQgbWlnaHQgcG9zZSBw cm9ibGVtcyBmb3IKICAgIGRpc3RyaWJ1dG9ycwpnc3QtcGx1Z2lucy1iYWQKY29udGFpbnMgYSBz ZXQgb2YgbGVzcyBzdXBwb3J0ZWQgcGx1Zy1pbnMgdGhhdCBoYXZlbid0IHBhc3NlZCB0aGUKICAg IHJpZ29yb3VzIHF1YWxpdHkgdGVzdGluZyB3ZSBleHBlY3QKCgoKICAKRmVhdHVyZXMgb2YgdGhp cyByZWxlYXNlCiAgICAKICAgICAgKiBQYXJhbGxlbCBpbnN0YWxsYWJpbGl0eSB3aXRoIDAuOC54 IHNlcmllcwogICAgICAqIFRocmVhZHNhZmUgZGVzaWduIGFuZCBBUEkKICAgICAgKiBSZWdpc3Ry eSBjYWNoZSB1cGRhdGluZyBpcyBub3cgZG9uZSBpbiBhIGZvcmssIHNvIG5vIHBsdWdpbnMgYXJl IGxlZnQgb3BlbmVkCiAgICAgICogTmV3IHZlcnNpb24gb2YgZGF0YSBwcm90b2NvbCBub3cgc2Vy aWFsaXplcyBldmVudHMKICAgICAgKiBxdWV1ZSBmaXhlcwogICAgICAqIHdpbjMyIGZpeGVzCgpC dWdzIGZpeGVkIGluIHRoaXMgcmVsZWFzZQogICAgCiAgICAgICogMzM4MzM1IDogW3BhdGNoXSBt ZW1sZWFrIGluIGdzdC11dGlscy5jIChsZWFrIHBhZHMgZnJvbSBpdGVyYXRvcikKICAgICAgKiAz NDM1OTggOiB1bmRlZmluZWQgc3ltYm9sIGluIGNvcmVpbmRleGVycyB3aGVuIHVzaW5nIC0tZGlz YWJsZS1sb2EuLi4KICAgICAgKiAzMzY5MjkgOiBHc3RDb2xsZWN0UGFkcyBkb2VzIG5vdCBjbGVh ci9yZXNldCBzZWdtZW50IGluZm8gYWZ0ZXIgZmwuLi4KICAgICAgKiAzMzcxMDAgOiBbZmFrZXNp bmtdIGFkZCAiIHByZXJvbGwtaGFuZG9mZiAiIHNpZ25hbAogICAgICAqIDMzOTkxOCA6IEdzdFRh Z1NldHRlciBtZXJnZS1tb2RlIGRlc2NyaXB0aW9uIHVuY2xlYXIsIGFuZCBpbXBsZW1lbi4uLgog ICAgICAqIDM0MDUwMSA6IFtmaWxlc3JjXSBnaXZlIHByaW1hcnkgcmFuawogICAgICAqIDM0MTY2 MiA6IGdzdC1sYXVuY2ggcHJpbnRfdGFncygpIGZpeAogICAgICAqIDM0MjIzOCA6IEFQSTogZ3N0 X2VsZW1lbnRfc2Vla19zaW1wbGUKICAgICAgKiAzNDIzMjEgOiBHU1RfUVVFUllfUE9TSVRJT04g ZmFpbHMgaWYgR3N0QmFzZVNyYyBpbiBnZXRfcmFuZ2UgbW9kZQogICAgICAqIDM0Mjc3NyA6IHJl YnVpbGRpbmcgdGhlIHJlZ2lzdHJ5IGxlYXZlcyBhbGwgcGx1Z2lucyBpbiBtZW1vcnkKICAgICAg KiAzNDI4MjAgOiBnc3RuZXRjbGllbnRjbG9jay5jKDQ1Myk6IHNlcnZhZGRyIHVzZWQgYmVmb3Jl IHNldAogICAgICAqIDM0MzA1NyA6IGdzdC1sYXVuY2gtMC4xMCBzZWdmYXVsdHMgd2hlbiBwYXNz ZWQgZ3N0LXBsdWdpbi1wYXRoIGFuZC4uLgogICAgICAqIDM0MzM0MSA6IFtBUEldIGFkZCBHU1Rf VEFHX1BSRVZJRVdfSU1BR0UKICAgICAgKiAzNDM4MjcgOiBsZWFrIGluIGdzdF9pbmRleF9ndHlw ZV9yZXNvbHZlcgogICAgICAqIDM0MzkyOSA6IFVzZSBvZiAvLyBpbiBwdWJsaWMgaGVhZGVyCiAg ICAgICogMzQzOTg4IDogZGF0YSBwcm90b2NvbCBuZWVkcyBleHRlbmRpbmcgdG8gaGFuZGxlIGV2 ZW50cyBiZXR0ZXIKICAgICAgKiAzNDE0NzkgOiBUb28gbWFueSBwbHVnaW5zIGxvYWRlZCBldmVu IGZvciB1cC10by1kYXRlIHJlZ2lzdHJ5CiAgICAgICogMzQzMzM0IDogR3N0Q29sbGVjdFBhZHMg dGVzdHN1aXRlIGFuZCBmaXhlcwogICAgICAqIDM0MzUzOCA6IEdzdENvbGxlY3RQYWRzIGRvZXNu J3QgcmVzZXQgRU9TIGZpZWxkcyB3aGVuIHN0b3BwZWQKCkFQSSBjaGFuZ2VkIGluIHRoaXMgcmVs ZWFzZQogICAgIAoKLSBBUEkgYWRkaXRpb25zOgogICAgCiogZ3N0X2VsZW1lbnRfc2Vla19zaW1w bGUoKQoqIEdTVF9GTE9XX0NVU1RPTV9TVUNDRVNTCiogR1NUX0ZMT1dfQ1VTVE9NX0VSUk9SCiog R1NUX0ZMT1dfSVNfU1VDQ0VTUwoqIGdzdF9jb2xsZWN0X3BhZHNfc2V0X2ZsdXNoaW5nKCkKKiBH U1RfVEFHX1BSRVZJRVdfSU1BR0UKKiBnc3RfZHBfY3JjKCkKKiBHc3REUFBhY2tldGl6ZXIKKiBH c3REUFZlcnNpb24KKiBHc3RGYWtlU2luazo6cHJlcm9sbC1oYW5kb2ZmCiogR3N0RmFrZVNpbms6 OnVzZS1tbWFwCgpEb3dubG9hZAoKWW91IGNhbiBmaW5kIHNvdXJjZSByZWxlYXNlcyBvZiBnc3Ry ZWFtZXIgaW4gdGhlIGRvd25sb2FkIGRpcmVjdG9yeToKaHR0cDovL2dzdHJlYW1lci5mcmVlZGVz a3RvcC5vcmcvc3JjL2dzdHJlYW1lci8KCkdTdHJlYW1lciBIb21lcGFnZQoKTW9yZSBkZXRhaWxz IGNhbiBiZSBmb3VuZCBvbiB0aGUgcHJvamVjdCdzIHdlYnNpdGU6Cmh0dHA6Ly9nc3RyZWFtZXIu ZnJlZWRlc2t0b3Aub3JnLwoKU3VwcG9ydCBhbmQgQnVncwoKV2UgdXNlIEdOT01FJ3MgYnVnemls bGEgZm9yIGJ1ZyByZXBvcnRzIGFuZCBmZWF0dXJlIHJlcXVlc3RzOgpodHRwOi8vYnVnemlsbGEu Z25vbWUub3JnL2VudGVyX2J1Zy5jZ2k/cHJvZHVjdD1HU3RyZWFtZXIKCkRldmVsb3BlcnMKCkNW UyBpcyBob3N0ZWQgb24gY3ZzLmZyZWVkZXNrdG9wLm9yZy4KQWxsIGNvZGUgaXMgaW4gQ1ZTIGFu ZCBjYW4gYmUgY2hlY2tlZCBvdXQgZnJvbSB0aGVyZS4KSW50ZXJlc3RlZCBkZXZlbG9wZXJzIG9m IHRoZSBjb3JlIGxpYnJhcnksIHBsdWctaW5zLCBhbmQgYXBwbGljYXRpb25zIHNob3VsZApzdWJz Y3JpYmUgdG8gdGhlIGdzdHJlYW1lci1kZXZlbCBsaXN0LiBJZiB0aGVyZSBpcyBzdWZmaWNpZW50 IGludGVyZXN0IHdlCndpbGwgY3JlYXRlIG1vcmUgbGlzdHMgYXMgbmVjZXNzYXJ5LgoKICAgICAg ICAKQXBwbGljYXRpb25zCgpBcHBsaWNhdGlvbnMgcG9ydGVkIHRvIEdTdHJlYW1lciAwLjEwIGlu Y2x1ZGUgVG90ZW0sIFJoeXRobUJveCwgU291bmQtSnVpY2VyLApHbm9tZSBNZWRpYSwgRmx1bW90 aW9uLCBBbWFyb2ssIEphbWJvcmVlLCBQaXRpdmksIElzdGFuYnVsLCBBbm5vQW1wLCBFbGlzYSwg YW5kIG90aGVycy4KTGV0IHVzIGtub3cgaWYgeW91IHdhbnQgdG8gYmUgYWRkZWQgdG8gdGhpcyBs aXN0LgoKICAKQ29udHJpYnV0b3JzIHRvIHRoaXMgcmVsZWFzZQogICAgCiAgICAgICogQWxlc3Nh bmRybyBEZWNpbmEKICAgICAgKiBFZHdhcmQgSGVydmV5CiAgICAgICogSmFuIFNjaG1pZHQKICAg ICAgKiBKdWxpZW4gTW91dHRlCiAgICAgICogTHV0eiBNdWVsbGVyCiAgICAgICogTWFyayBOYXV3 ZWxhZXJ0cwogICAgICAqIE1pY2hhZWwgU21pdGgKICAgICAgKiBTZWJhc3RpZW4gTW91dHRlCiAg ICAgICogU3RlZmFuIEtvc3QKICAgICAgKiBUaG9tYXMgVmFuZGVyIFN0aWNoZWxlCiAgICAgICog VGltLVBoaWxpcHAgTcO8bGxlcgogICAgICAqIFdpbSBUYXltYW5zCiAgICAgICogWmFoZWVyIEFi YmFzIE1lcmFsaQrCoA== --127.0.0.1.500.4863.1149880260.533.2-- From thomas@apestaart.org Fri Jun 9 15:11:49 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5C75C3B00E9 for ; Fri, 9 Jun 2006 15:11:49 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15136-05 for ; Fri, 9 Jun 2006 15:11:48 -0400 (EDT) Received: from mx1.es6.egwn.net (server02.es6.egwn.net [195.10.6.12]) by menubar.gnome.org (Postfix) with ESMTP id 0A9E03B0149 for ; Fri, 9 Jun 2006 15:11:47 -0400 (EDT) Received: from mx1.fr4.egwn.net (server07.fr4.egwn.net [62.39.85.77]) by mx1.es6.egwn.net (Postfix) with ESMTP id 5C5134F822C; Fri, 9 Jun 2006 21:11:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mx1.fr4.egwn.net (spiffy mail daemon) with ESMTP id 20D9883BFD; Fri, 9 Jun 2006 21:11:35 +0200 (CEST) Received: from mx1.fr4.egwn.net ([127.0.0.1]) by localhost (server07.fr4.egwn.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23574-43; Fri, 9 Jun 2006 21:11:34 +0200 (CEST) Received: from thread.fluendo.lan (core.fluendo.com [195.10.6.237]) by mx1.fr4.egwn.net (spiffy mail daemon) with ESMTP id 33DE383BF8; Fri, 9 Jun 2006 21:11:34 +0200 (CEST) Received: from otto.amantes (thomas.fluendo.lan [192.168.1.10]) by thread.fluendo.lan (Postfix) with ESMTP id 071AFFE93; Fri, 9 Jun 2006 21:11:45 +0200 (CEST) Received: from otto.amantes (otto.amantes [127.0.0.1]) by otto.amantes (Postfix) with ESMTP id 35F55EFC0D; Fri, 9 Jun 2006 21:11:48 +0200 (CEST) Content-Type: multipart/mixed; boundary="127.0.0.1.500.5548.1149880308.216.2" MIME-Version: 1.0 To: gstreamer-devel@lists.sourceforge.net, gstreamer-announce@lists.sourceforge.net, kde-multimedia@kde.org, gnome-multimedia@gnome.org Message-Id: <20060609191148.35F55EFC0D@otto.amantes> Date: Fri, 9 Jun 2006 21:11:48 +0200 (CEST) From: thomas@apestaart.org X-Scanned: By amavis at egwn.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: Yes, score=2.198 tagged_above=-999 required=2 tests=[AWL=-1.575, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, MIME_BASE64_TEXT=1.885, NO_REAL_NAME=0.961, RCVD_IN_SBL=3.16, TW_EG=0.077, TW_EV=0.077, TW_FD=0.077] X-Spam-Score: 2.198 X-Spam-Level: ** X-Spam-Flag: YES Cc: Subject: RELEASE: GStreamer Base Plug-ins 0.10.8 'Moar gij zie mij nie' X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 19:11:49 -0000 --127.0.0.1.500.5548.1149880308.216.2 Content-Type: text/plain This mail announces the release of GStreamer Base Plug-ins 0.10.8 'Moar gij zie mij nie'. GStreamer Base Plug-ins is a well-groomed and well-maintained collection of GStreamer plug-ins and elements, spanning the range of possible types of elements one would want to write for GStreamer. It also contains helper libraries and base classes useful for writing elements. A wide range of video and audio decoders, encoders, and filters are included. For more information, see [http://gstreamer.freedesktop.org/modules/gst-plugins-base.html] To file bugs, go to [http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer&component=gst-plugins-base] --127.0.0.1.500.5548.1149880308.216.2 Content-Type: text/plain; name=RELEASE Content-Transfer-Encoding: base64 ClJlbGVhc2Ugbm90ZXMgZm9yIEdTdHJlYW1lciBCYXNlIFBsdWctaW5zwqAwLjEwLjggIk1vYXIg Z2lqIHppZXQgbWlqIG5pZSIKICAgICAgICAKCgpUaGUgR1N0cmVhbWVyIHRlYW0gaXMgcHJvdWQg dG8gYW5ub3VuY2UgYSBuZXcgcmVsZWFzZQppbiB0aGUgMC4xMC54IHN0YWJsZSBzZXJpZXMgb2Yg dGhlCkdTdHJlYW1lciBCYXNlIFBsdWctaW5zLgoKClRoZSAwLjEwLnggc2VyaWVzIGlzIGEgc3Rh YmxlIHNlcmllcyB0YXJnZXRlZCBhdCBlbmQgdXNlcnMuCkl0IGlzIG5vdCBBUEkgb3IgQUJJIGNv bXBhdGlibGUgd2l0aCB0aGUgc3RhYmxlIDAuOC54IHNlcmllcy4KSXQgaXMsIGhvd2V2ZXIsIHBh cmFsbGVsIGluc3RhbGxhYmxlIHdpdGggdGhlIDAuOC54IHNlcmllcy4KCgoKVGhpcyBtb2R1bGUg Y29udGFpbnMgYSBzZXQgb2YgcmVmZXJlbmNlIHBsdWdpbnMsIGJhc2UgY2xhc3NlcyBmb3Igb3Ro ZXIKcGx1Z2lucywgYW5kIGhlbHBlciBsaWJyYXJpZXMuCgpUaGlzIG1vZHVsZSBpcyBrZXB0IHVw LXRvLWRhdGUgdG9nZXRoZXIgd2l0aCB0aGUgY29yZSBkZXZlbG9wbWVudHMuICBFbGVtZW50Cndy aXRlcnMgc2hvdWxkIGxvb2sgYXQgdGhlIGVsZW1lbnRzIGluIHRoaXMgbW9kdWxlIGFzIGEgcmVm ZXJlbmNlIGZvcgp0aGVpciBkZXZlbG9wbWVudC4KClRoaXMgbW9kdWxlIGNvbnRhaW5zIGVsZW1l bnRzIGZvciwgYW1vbmcgb3RoZXJzOgoKICBkZXZpY2UgcGx1Z2luczogeCh2KWltYWdlc2luaywg YWxzYSwgdjRsc3JjLCBjZHBhcmFub2lhCiAgY29udGFpbmVyczogb2dnCiAgY29kZWNzOiB2b3Ji aXMsIHRoZW9yYQogIHRleHQ6IHRleHRvdmVybGF5LCBzdWJwYXJzZQogIHNvdXJjZXM6IGF1ZGlv dGVzdHNyYywgdmlkZW90ZXN0c3JjLCBnbm9tZXZmc3NyYwogIG5ldHdvcms6IHRjcAogIHR5cGVm aW5kCiAgYXVkaW8gcHJvY2Vzc2luZzogYXVkaW9jb252ZXJ0LCBhZGRlciwgYXVkaW9yYXRlLCBh dWRpb3NjYWxlLCB2b2x1bWUKICB2aXN1YWxpc2F0aW9uOiBsaWJ2aXN1YWwKICB2aWRlbyBwcm9j ZXNzaW5nOiBmZm1wZWdjb2xvcnNwYWNlCiAgYWdncmVnYXRlIGVsZW1lbnRzOiBkZWNvZGViaW4s IHBsYXliaW4KCgpPdGhlciBtb2R1bGVzIGNvbnRhaW5pbmcgcGx1Zy1pbnMgYXJlOgoKCmdzdC1w bHVnaW5zLWdvb2QKY29udGFpbnMgYSBzZXQgb2Ygd2VsbC1zdXBwb3J0ZWQgcGx1Zy1pbnMgdW5k ZXIgb3VyIHByZWZlcnJlZCBsaWNlbnNlCmdzdC1wbHVnaW5zLXVnbHkKY29udGFpbnMgYSBzZXQg b2Ygd2VsbC1zdXBwb3J0ZWQgcGx1Zy1pbnMsIGJ1dCBtaWdodCBwb3NlIHByb2JsZW1zIGZvcgog ICAgZGlzdHJpYnV0b3JzCmdzdC1wbHVnaW5zLWJhZApjb250YWlucyBhIHNldCBvZiBsZXNzIHN1 cHBvcnRlZCBwbHVnLWlucyB0aGF0IGhhdmVuJ3QgcGFzc2VkIHRoZQogICAgcmlnb3JvdXMgcXVh bGl0eSB0ZXN0aW5nIHdlIGV4cGVjdAoKCgogIApGZWF0dXJlcyBvZiB0aGlzIHJlbGVhc2UKICAg IAogICAgICAqIFBhcmFsbGVsIGluc3RhbGxhYmlsaXR5IHdpdGggMC44Lnggc2VyaWVzCiAgICAg ICogVGhyZWFkc2FmZSBkZXNpZ24gYW5kIEFQSQogICAgICAqIGFsc2FzaW5rIHByb2JpbmcgZml4 ZXMKICAgICAgKiB4dmltYWdlc2luayBlcnJvciByZXBvcnRpbmcgZml4ZXMKICAgICAgKiBzdWJ0 aXRsZSBmaXhlcwogICAgICAqIGFkZGVyIGZpeGVzCiAgICAgICogdm9yYmlzIG11bHRpY2hhbm5l bCBmaXhlcwogICAgICAqIG11bHRpZmRzaW5rIHN0cmVhbWhlYWRlciBmaXhlcwoKQnVncyBmaXhl ZCBpbiB0aGlzIHJlbGVhc2UKICAgIAogICAgICAqIDE2OTkzNiA6IFtzdWJwYXJzZV0gc3VwcG9y dCBmb3IgU0FNSSBzdWJ0aXRsZXMKICAgICAgKiAzMTUzMTIgOiBHc3RyZWFtZXIgWHYgdXNlcyBS R0IgaW5zdGVhZCBvZiBZVVYuCiAgICAgICogMzM0MDAyIDogdmlkZW80bGludXggc2hvdWxkbid0 IGRlcGVuZCBvbiBYIGluIGNvbmZpZ3VyZSBzY3JpcHQKICAgICAgKiAzMzY4ODEgOiBbbGlidmlz dWFsXSBhZGRpdGlvbmFsIHN1cHBvcnQgZm9yIGxpYnZpc3VhbC0wLjQKICAgICAgKiAzMzc1NDQg OiBbeHZpbWFnZXNpbmtdIEludGVybmFsIEVycm9yIHdoZW4gaW1hZ2UgaXMgdG9vIGxhcmdlCiAg ICAgICogMzM5NTIwIDogW3N1YnBhcnNlXSBhZGQgIiBlbmNvZGluZyAiIHByb3BlcnR5CiAgICAg ICogMzQwOTA5IDogW2Fsc2FzaW5rXSBjYW4ndCBlbmFibGUgc3BkaWYgb3V0cHV0CiAgICAgICog MzQxNTQyIDogc29tZSB1c2VycyBoYXZlIGFuIGFzc2VydGlvbiBmYWlsZWQ6IChHU1RfVklERU9f U0lOS19XSURULi4uCiAgICAgICogMzQxNTYyIDogYXVkaW9jb252ZXJ0IGRvZXNuJ3QgbGlzdCBm b3JtYXRzIGluIG9yZGVyIG9mIHByZWZlcmVuY2UKICAgICAgKiAzNDE2OTYgOiBhdWRpb2NvbnZl cnQgY3Jhc2hlcyBpZiBjb252ZXJ0aW5nIGZyb20gYSBmb3JtYXQgd2l0aCBubyAuLi4KICAgICAg KiAzNDE3MTkgOiBiaXNlY3Rpb24gYWxnb3JpdGhtIGluIG9nZyBkb2Vzbid0IGJpc2VjdCBpbiBz b21lIGNhc2VzCiAgICAgICogMzQxNzMyIDogW2Fsc2FzaW5rXSBkb2Vzbid0IHF1ZXJ5IHN1cHBv cnRlZCBzYW1wbGUgcmF0ZXMKICAgICAgKiAzNDE4NzMgOiBbYWxzYXNpbmtdIG1pbm9yIG1lbW9y eSBsZWFrLCB1c2VzIHVucHJvdGVjdGVkIHN0YXRpYyB2YXIuLi4KICAgICAgKiAzNDIxNDMgOiBb c3VicGFyc2VdIHNhbWkgcGFyc2VyIG5lZWRzIHRvIGVzY2FwZSBjaGFyYWN0ZXJzCiAgICAgICog MzQyMTgxIDogW2Fsc2FdIGFkZCBwcm9wZXJ0eSBwcm9iZSBpbnRlcmZhY2UgdG8gYWxzYXNpbmsg YW5kIGFsc2FzcmMKICAgICAgKiAzNDIyNjggOiBbcGxheWJpbl0gYWRkICdzdWJ0aXRsZS1lbmNv ZGluZycgcHJvcGVydHkKICAgICAgKiAzNDIzNDUgOiBbcmlmZl0gRWxlcGhhbnQncyBEcmVhbSBB VkkgZG9lcyBub3QgcGxheSwgSlVOSyBjaHVuayBiZWYuLi4KICAgICAgKiAzNDI1NjYgOiBCdWls ZGluZyB3aXRob3V0IEdUSysgZmFpbHMKICAgICAgKiAzNDMzOTcgOiBILjI2NC9BQUMgbW92aWUg ZGVhZGxvY2tzIHdpdGggdG90ZW0gaW4gZ3N0cmVhbWVyIGNvZGUsIHAuLi4KICAgICAgKiAzMzk5 MzUgOiBbYWRkZXJdIGRlYWQtbG9ja3Mgd2hlbiBhZGRpbmcgc2luayBwYWRzIGluIFBBVVNFRCBz dGF0ZQoKRG93bmxvYWQKCllvdSBjYW4gZmluZCBzb3VyY2UgcmVsZWFzZXMgb2YgZ3N0LXBsdWdp bnMtYmFzZSBpbiB0aGUgZG93bmxvYWQgZGlyZWN0b3J5OgpodHRwOi8vZ3N0cmVhbWVyLmZyZWVk ZXNrdG9wLm9yZy9zcmMvZ3N0LXBsdWdpbnMtYmFzZS8KCkdTdHJlYW1lciBIb21lcGFnZQoKTW9y ZSBkZXRhaWxzIGNhbiBiZSBmb3VuZCBvbiB0aGUgcHJvamVjdCdzIHdlYnNpdGU6Cmh0dHA6Ly9n c3RyZWFtZXIuZnJlZWRlc2t0b3Aub3JnLwoKU3VwcG9ydCBhbmQgQnVncwoKV2UgdXNlIEdOT01F J3MgYnVnemlsbGEgZm9yIGJ1ZyByZXBvcnRzIGFuZCBmZWF0dXJlIHJlcXVlc3RzOgpodHRwOi8v YnVnemlsbGEuZ25vbWUub3JnL2VudGVyX2J1Zy5jZ2k/cHJvZHVjdD1HU3RyZWFtZXIKCkRldmVs b3BlcnMKCkNWUyBpcyBob3N0ZWQgb24gY3ZzLmZyZWVkZXNrdG9wLm9yZy4KQWxsIGNvZGUgaXMg aW4gQ1ZTIGFuZCBjYW4gYmUgY2hlY2tlZCBvdXQgZnJvbSB0aGVyZS4KSW50ZXJlc3RlZCBkZXZl bG9wZXJzIG9mIHRoZSBjb3JlIGxpYnJhcnksIHBsdWctaW5zLCBhbmQgYXBwbGljYXRpb25zIHNo b3VsZApzdWJzY3JpYmUgdG8gdGhlIGdzdHJlYW1lci1kZXZlbCBsaXN0LiBJZiB0aGVyZSBpcyBz dWZmaWNpZW50IGludGVyZXN0IHdlCndpbGwgY3JlYXRlIG1vcmUgbGlzdHMgYXMgbmVjZXNzYXJ5 LgoKICAgICAgICAKQXBwbGljYXRpb25zCiAgCkNvbnRyaWJ1dG9ycyB0byB0aGlzIHJlbGVhc2UK ICAgIAogICAgICAqIEVkd2FyZCBIZXJ2ZXkKICAgICAgKiBKYW4gU2NobWlkdAogICAgICAqIEp1 bGllbiBNb3V0dGUKICAgICAgKiBNYXJ0aW4gU3p1bGVja2kKICAgICAgKiBNaWNoYWVsIFNtaXRo CiAgICAgICogUGV0ZXIgS2plbGxlcnN0ZWR0CiAgICAgICogU2ViYXN0aWVuIE1vdXR0ZQogICAg ICAqIFN0ZWZhbiBLb3N0CiAgICAgICogVGhvbWFzIFZhbmRlciBTdGljaGVsZQogICAgICAqIFRp bS1QaGlsaXBwIE3DvGxsZXIKICAgICAgKiBXaW0gVGF5bWFucwogICAgICAqIFlvdW5nLUhvIENo YQogICAgICAqIFphaGVlciBBYmJhcyBNZXJhbGkKwqA= --127.0.0.1.500.5548.1149880308.216.2-- From thomas@apestaart.org Sat Jun 10 13:20:04 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 77ABD3B0280 for ; Sat, 10 Jun 2006 13:20:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16793-02 for ; Sat, 10 Jun 2006 13:20:03 -0400 (EDT) Received: from core.fluendo.com (core.fluendo.com [195.10.6.237]) by menubar.gnome.org (Postfix) with ESMTP id E5DCC3B01B8 for ; Sat, 10 Jun 2006 13:20:02 -0400 (EDT) Received: from onzenbak.amantes (70.Red-81-38-184.dynamicIP.rima-tde.net [81.38.184.70]) by core.fluendo.com (Postfix) with ESMTP id 205F71DC; Sat, 10 Jun 2006 19:20:01 +0200 (CEST) Received: from otto.amantes (otto.amantes [192.168.1.10]) by onzenbak.amantes (Postfix) with ESMTP id 4680720476; Sat, 10 Jun 2006 19:19:58 +0200 (CEST) Received: from otto.amantes (otto.amantes [127.0.0.1]) by otto.amantes (Postfix) with ESMTP id 3B641EFC0D; Sat, 10 Jun 2006 19:20:01 +0200 (CEST) Content-Type: multipart/mixed; boundary="127.0.0.1.500.6078.1149960001.170.2" MIME-Version: 1.0 To: gstreamer-devel@lists.sourceforge.net, gstreamer-announce@lists.sourceforge.net, kde-multimedia@kde.org, gnome-multimedia@gnome.org Message-Id: <20060610172001.3B641EFC0D@otto.amantes> Date: Sat, 10 Jun 2006 19:20:01 +0200 (CEST) From: thomas@apestaart.org X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.991 tagged_above=-999 required=2 tests=[AWL=-1.373, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, MIME_BASE64_TEXT=1.885, NO_REAL_NAME=0.961] X-Spam-Score: -0.991 X-Spam-Level: Cc: Subject: RELEASE: GStreamer 0.10.8 'Soepeke, ik zie ou nog altijd nie' X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 17:20:04 -0000 --127.0.0.1.500.6078.1149960001.170.2 Content-Type: text/plain This mail announces the release of GStreamer 0.10.8 'Soepeke, ik zie ou nog altijd nie'. GStreamer is a streaming media framework that allows the construction of graphs of elements which operate on media data. Applications using this library can do anything from real-time sound processing over playing video to capturing audio, video, and even other types of media data. Its architecture allows for adding new data types or processing capabilities simply by installing new plug-ins. GStreamer is the core module, containing libraries, headers, the basic object hierarchy, and a set of media-agnostic core elements. For more information, see [http://gstreamer.freedesktop.org/modules/gstreamer.html] To file bugs, go to [http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer&component=gstreamer+%28core%29] --127.0.0.1.500.6078.1149960001.170.2 Content-Type: text/plain; name=RELEASE Content-Transfer-Encoding: base64 ClJlbGVhc2Ugbm90ZXMgZm9yIEdTdHJlYW1lcsKgMC4xMC44ICJTb2VwZWtlLCBpayB6aWUgb3Ug bm9nIGFsdGlqZCBuaWUiCiAgICAgICAgCgoKVGhlIEdTdHJlYW1lciB0ZWFtIGlzIHByb3VkIHRv IGFubm91bmNlIGEgbmV3IHJlbGVhc2UKaW4gdGhlIDAuMTAueCBzdGFibGUgc2VyaWVzIG9mIHRo ZQpjb3JlIG9mIHRoZSBHU3RyZWFtZXIgc3RyZWFtaW5nIG1lZGlhIGZyYW1ld29yay4KCgpUaGUg MC4xMC54IHNlcmllcyBpcyBhIHN0YWJsZSBzZXJpZXMgdGFyZ2V0ZWQgYXQgZW5kIHVzZXJzLgpJ dCBpcyBub3QgQVBJIG9yIEFCSSBjb21wYXRpYmxlIHdpdGggdGhlIHN0YWJsZSAwLjgueCBzZXJp ZXMuCkl0IGlzLCBob3dldmVyLCBwYXJhbGxlbCBpbnN0YWxsYWJsZSB3aXRoIHRoZSAwLjgueCBz ZXJpZXMuCgoKVGhlIDAuMTAueCBzZXJpZXMgaGFzIGJlZW4gcmV3b3JrZWQgZm9yIHRocmVhZHNh ZmV0eS4gIEl0IGFsc28gZmVhdHVyZXMKdmFyaW91cyBmZWF0dXJlIGFkZGl0aW9ucyBhbmQgZW5j aGFuY2VtZW50cy4KCgpUaGlzIG1vZHVsZSwgZ3N0cmVhbWVyLCBvbmx5IGNvbnRhaW5zIGNvcmUg ZnVuY3Rpb25hbGl0eS4KRm9yIGFjdHVhbCBtZWRpYSBwbGF5YmFjaywgeW91IHdpbGwgbmVlZCBv dGhlciBtb2R1bGVzLgoKZ3N0LXBsdWdpbnMtYmFzZQpjb250YWlucyBhIGJhc2ljIHNldCBvZiB3 ZWxsLXN1cHBvcnRlZCBwbHVnLWlucwpnc3QtcGx1Z2lucy1nb29kCmNvbnRhaW5zIGEgc2V0IG9m IHdlbGwtc3VwcG9ydGVkIHBsdWctaW5zIHVuZGVyIG91ciBwcmVmZXJyZWQgbGljZW5zZQpnc3Qt cGx1Z2lucy11Z2x5CmNvbnRhaW5zIGEgc2V0IG9mIHdlbGwtc3VwcG9ydGVkIHBsdWctaW5zLCBi dXQgbWlnaHQgcG9zZSBwcm9ibGVtcyBmb3IKICAgIGRpc3RyaWJ1dG9ycwpnc3QtcGx1Z2lucy1i YWQKY29udGFpbnMgYSBzZXQgb2YgbGVzcyBzdXBwb3J0ZWQgcGx1Zy1pbnMgdGhhdCBoYXZlbid0 IHBhc3NlZCB0aGUKICAgIHJpZ29yb3VzIHF1YWxpdHkgdGVzdGluZyB3ZSBleHBlY3QKCgoKICAK RmVhdHVyZXMgb2YgdGhpcyByZWxlYXNlCiAgICAKICAgICAgKiBQYXJhbGxlbCBpbnN0YWxsYWJp bGl0eSB3aXRoIDAuOC54IHNlcmllcwogICAgICAqIFRocmVhZHNhZmUgZGVzaWduIGFuZCBBUEkK ICAgICAgKiBJbXBvcnRhbnQgZml4IGZvciByZWdpc3RyeSB1cGRhdGUgY2F1c2luZyBhcHBsZXRz IG5vdCB0byBsb2FkCgpCdWdzIGZpeGVkIGluIHRoaXMgcmVsZWFzZQogICAgCiAgICAgICogMzQ0 NDc0IDogR25vbWUgTWl4ZXIgQXBwbGV0IGRvZXNuJ3Qgd2FudCB0byBsb2FkCgpEb3dubG9hZAoK WW91IGNhbiBmaW5kIHNvdXJjZSByZWxlYXNlcyBvZiBnc3RyZWFtZXIgaW4gdGhlIGRvd25sb2Fk IGRpcmVjdG9yeToKaHR0cDovL2dzdHJlYW1lci5mcmVlZGVza3RvcC5vcmcvc3JjL2dzdHJlYW1l ci8KCkdTdHJlYW1lciBIb21lcGFnZQoKTW9yZSBkZXRhaWxzIGNhbiBiZSBmb3VuZCBvbiB0aGUg cHJvamVjdCdzIHdlYnNpdGU6Cmh0dHA6Ly9nc3RyZWFtZXIuZnJlZWRlc2t0b3Aub3JnLwoKU3Vw cG9ydCBhbmQgQnVncwoKV2UgdXNlIEdOT01FJ3MgYnVnemlsbGEgZm9yIGJ1ZyByZXBvcnRzIGFu ZCBmZWF0dXJlIHJlcXVlc3RzOgpodHRwOi8vYnVnemlsbGEuZ25vbWUub3JnL2VudGVyX2J1Zy5j Z2k/cHJvZHVjdD1HU3RyZWFtZXIKCkRldmVsb3BlcnMKCkNWUyBpcyBob3N0ZWQgb24gY3ZzLmZy ZWVkZXNrdG9wLm9yZy4KQWxsIGNvZGUgaXMgaW4gQ1ZTIGFuZCBjYW4gYmUgY2hlY2tlZCBvdXQg ZnJvbSB0aGVyZS4KSW50ZXJlc3RlZCBkZXZlbG9wZXJzIG9mIHRoZSBjb3JlIGxpYnJhcnksIHBs dWctaW5zLCBhbmQgYXBwbGljYXRpb25zIHNob3VsZApzdWJzY3JpYmUgdG8gdGhlIGdzdHJlYW1l ci1kZXZlbCBsaXN0LiBJZiB0aGVyZSBpcyBzdWZmaWNpZW50IGludGVyZXN0IHdlCndpbGwgY3Jl YXRlIG1vcmUgbGlzdHMgYXMgbmVjZXNzYXJ5LgoKICAgICAgICAKQXBwbGljYXRpb25zCgpBcHBs aWNhdGlvbnMgcG9ydGVkIHRvIEdTdHJlYW1lciAwLjEwIGluY2x1ZGUgVG90ZW0sIFJoeXRobUJv eCwgU291bmQtSnVpY2VyLApHbm9tZSBNZWRpYSwgRmx1bW90aW9uLCBBbWFyb2ssIEphbWJvcmVl LCBQaXRpdmksIElzdGFuYnVsLCBBbm5vQW1wLCBFbGlzYSwgYW5kIG90aGVycy4KTGV0IHVzIGtu b3cgaWYgeW91IHdhbnQgdG8gYmUgYWRkZWQgdG8gdGhpcyBsaXN0LgoKICAKQ29udHJpYnV0b3Jz IHRvIHRoaXMgcmVsZWFzZQogICAgCiAgICAgICogRWR3YXJkIEhlcnZleQogICAgICAqIFRob21h cyBWYW5kZXIgU3RpY2hlbGUKICAgICAgKiBUaW0tUGhpbGlwcCBNw7xsbGVyCsKg --127.0.0.1.500.6078.1149960001.170.2-- From sjoeboo@sjoeboo.com Wed Jun 14 10:50:35 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CE3003B037F; Wed, 14 Jun 2006 10:50:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08478-04; Wed, 14 Jun 2006 10:50:34 -0400 (EDT) Received: from server.sjoeboo.com (unknown [64.79.192.114]) by menubar.gnome.org (Postfix) with ESMTP id D38F13B02C8; Wed, 14 Jun 2006 10:50:33 -0400 (EDT) Received: by server.sjoeboo.com (Postfix, from userid 33) id 6D37418C4F7F; Wed, 14 Jun 2006 07:50:15 -0700 (PDT) To: gnome-multimedia@gnome.org, rhythmbox-devel@gnome.org Subject: totem and goom information... MIME-Version: 1.0 Date: Wed, 14 Jun 2006 7:50:15 -0700 From: sjoeboo Organization: sjoeboo.com Message-ID: <5135b2d86e5568cedc7e8138809a3b9f@localhost> X-Sender: sjoeboo@sjoeboo.com User-Agent: RoundCube Webmail/0.1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[AWL=0.000, BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: sjoeboo@sjoeboo.com List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 14:50:36 -0000 Good "morning" everyone, So, my (and what should be everyones) favorite music player for gnome, rhythmbox, has been on a steady march of advancement for the past few months, with a whole slew of new features comming about. One thing I though of recently is visualizations, and how ncie it would be to have at least one, possibly as a plugin. I know totem uses GOOM to do this, and was wondering what I might have to do in terms of gstreamer etc to have rhythmbox use it as well. I was looking around on the Totem site for a mailing list etc, but couldn't find anything. Does anyone know where I might find more info for something like this? Thanks, and keep up the great work. -- Matthew Nicholson sjoeboo@sjoeboo.com sjoeboo.com From internalerror@gmail.com Thu Jun 22 05:25:58 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E43203B02D2 for ; Thu, 22 Jun 2006 05:25:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12537-03 for ; Thu, 22 Jun 2006 05:25:56 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.201]) by menubar.gnome.org (Postfix) with ESMTP id D48DD3B0179 for ; Thu, 22 Jun 2006 05:25:55 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so314263wxc for ; Thu, 22 Jun 2006 02:25:55 -0700 (PDT) Received: by 10.70.91.12 with SMTP id o12mr2775555wxb; Thu, 22 Jun 2006 02:25:55 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 02:25:55 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 11:25:55 +0200 From: "Milosz Derezynski" To: xdg@lists.freedesktop.org Subject: MLQ (Media Library Query) file format and mime type proposal MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3009_31371308.1150968355005" X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.255 tagged_above=-999 required=2 tests=[AWL=0.344, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.255 X-Spam-Level: Cc: gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 09:25:58 -0000 ------=_Part_3009_31371308.1150968355005 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I'm one of the main authors of BMP 2 (still being worked on), and along the way of reworking our library, i came across the idea of encoding library queries as URIs, which may look like this: "query:///?artist=Air&album=Moon%20Safari" BMP 2 has a plugin archicture which is a small VFS on it's own, and we treat certain things as "containers" (i.e. they "contain" URIs, like PLS playlists, XSPF, M3U, etc). Now i thought it might be not a bad idea to create a playlist format with these query URLs, and i've called it "MLQ" for media library query. In theory, it's not even application specific. The keys (identifiers), like artist, album, etc, are all based on GStreamer tag identifiers. (They could be maybe adapted to http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but it seems insufficient and doesn't specify certain items, like musicbrainz metadata, which GST does). So i've called this file format "MLQ", with the extension .mlq, created a mime package file for it: Media Library Query List Adding a file of this type to BMPx, or just a plain query:/// URI itself causes a library query and appending of the relevant items to the tracklist (BMP is currently mostly based on the concept of a mutable playlist to which items can be added from various sources, unlike e.g. RB which has mostly immutable "Playlists", but allows for custom queues). Another example is: query:///?artist=Air&album=Moon%20Safari&title=La%20Femme%20d'Argent query:///?artist=Air&album=Moon%20Safari&title=Sexy%20Boy query:///?artist=Air&album=Moon%20Safari&title=All%20I%20Need query:///?artist=Air&album=Moon%20Safari&title=Kelly,%20Watch%20The%20Stars! query:///?artist=Air&album=Moon%20Safari&title=Talisman query:///?artist=Air&album=Moon%20Safari&title=Remember query:///?artist=Air&album=Moon%20Safari&title=You%20Make%20It%20Easy query:///?artist=Air&album=Moon%20Safari&title=Ce%20Matin%20La query:///?artist=Air&album=Moon%20Safari&title=New%20Star%20In%20The%20Sky query:///?artist=Air&album=Moon%20Safari&title=Le%20Voyage%20De%20Penelope Or it might just be: query:///?genre=Jazz Since this is very common, and having the discussions about a common music database in mind, this seems like a useful proposal, since it is not player specific. This ships currently with BMP 2/BMPx SVN, and while i will ship this with the 0.20 release (end-July) anyway, what does everyone think of this in a broader context (common music database, etc)? -- Milosz ------=_Part_3009_31371308.1150968355005 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

I'm one of the main authors of BMP 2 (still being worked on), and along the way of reworking our library, i came across the idea of encoding library queries as URIs, which may look like this:

"query:///?artist=Air&album=Moon%20Safari"

BMP 2 has a plugin archicture which is a small VFS on it's own, and we treat certain things as "containers" (i.e. they "contain" URIs, like PLS playlists, XSPF, M3U, etc).
Now i thought it might be not a bad idea to create a playlist format with these query URLs, and i've called it "MLQ" for media library query. In theory, it's not even
application specific. The keys (identifiers), like artist, album, etc, are all based on GStreamer tag identifiers. (They could be maybe adapted to http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but it seems insufficient and doesn't specify certain items, like musicbrainz metadata, which GST does).

So i've called this file format "MLQ", with the extension .mlq, created a mime package file for it:

<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info ">
  <mime-type type="application/x-media-library-query">
         <comment xml:lang="en">Media Library Query List</comment>
         <magic priority="50">
            <match value="query:///" type="string" offset="0"/>
         </magic>
         <glob pattern="*.mlq"/>
  </mime-type>
</mime-info>

Adding a file of this type to BMPx, or just a plain query:/// URI itself causes a library query and appending of the relevant items to the tracklist (BMP is currently mostly based on the concept of a mutable playlist to which items can be added from various sources, unlike e.g. RB which has mostly immutable "Playlists", but allows for custom queues).

Another example is:

query:///?artist=Air&album=Moon%20Safari&title=La%20Femme%20d'Argent
query:///?artist=Air&album=Moon%20Safari&title=Sexy%20Boy
query:///?artist=Air&album=Moon%20Safari&title=All%20I%20Need
query:///?artist=Air&album=Moon%20Safari&title=Kelly,%20Watch%20The%20Stars!
query:///?artist=Air&album=Moon%20Safari&title=Talisman
query:///?artist=Air&album=Moon%20Safari&title=Remember
query:///?artist=Air&album=Moon%20Safari&title=You%20Make%20It%20Easy
query:///?artist=Air&album=Moon%20Safari&title=Ce%20Matin%20La
query:///?artist=Air&album=Moon%20Safari&title=New%20Star%20In%20The%20Sky
query:///?artist=Air&album=Moon%20Safari&title=Le%20Voyage%20De%20Penelope

Or it might just be:

query:///?genre=Jazz

Since this is very common, and having the discussions about a common music database in mind, this seems like a useful proposal, since it is not player specific.
This ships currently with BMP 2/BMPx SVN, and while i will ship this with the 0.20 release (end-July) anyway, what does everyone think of this in a broader context (common music database, etc)?

-- Milosz
------=_Part_3009_31371308.1150968355005-- From internalerror@gmail.com Thu Jun 22 05:32:59 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7208D3B00DE for ; Thu, 22 Jun 2006 05:32:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12916-03 for ; Thu, 22 Jun 2006 05:32:58 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.207]) by menubar.gnome.org (Postfix) with ESMTP id 6F0643B0373 for ; Thu, 22 Jun 2006 05:32:58 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so314918wxc for ; Thu, 22 Jun 2006 02:32:57 -0700 (PDT) Received: by 10.70.103.9 with SMTP id a9mr2787413wxc; Thu, 22 Jun 2006 02:32:57 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 02:32:57 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 11:32:57 +0200 From: "Milosz Derezynski" To: xdg@lists.freedesktop.org Subject: MLQ: Followup MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3081_18949182.1150968777845" X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.875 tagged_above=-999 required=2 tests=[AWL=-0.071, BAYES_00=-2.599, HTML_00_10=0.795, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -1.875 X-Spam-Level: Cc: gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 09:32:59 -0000 ------=_Part_3081_18949182.1150968777845 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline What i forgot to mention: One benefit of MLQs over 'regular' playlists at least with BMP 2 is that i've introduced a concept of keeping track of tracks across mount point changes which basically works like this: BMP stores for each file the HAL volume and device UDI, and the VRP (Volume Relative Path), that is, the path stripped off the mount point root. Whenever it seems that a file is missing, it checks whether the volume UDI of this file is still present on the system, and if so, gathers the new mount point, and adjusts the URI of this file in the library (this obiviously only works with tracks from the library only anyway since only there we can reliably store the HAL volume/device UDI and the VRP). This means practically: - Mount your music to /music - Start BMP - Add music from /music to the library - Quit BMP - Remount /music to e.g. /old_music - Start BMP - Use the library as before. Whenever BMP finds a file is missing, it will correct the URI on-the-fly as long as the volume is mounted at all on the system (and has an UDI to begin with; problem cases here are network volumes, NFS and SMBFS) So the benefit of an MLQ is that unlike a static playlist, you can be rather sure that no matter where you really move the music, BMP will always be able to find it. Downsides/doesn't-works: - There is no volume UDI available - You make a regular 'move' (mv), and not just a remount In the context of having a common music database, or something like Tracker, this seems very useful (Jamie: Hence my urge to add HAL volume/device UDI per file to the metadata). -- Milosz ------=_Part_3081_18949182.1150968777845 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline What i forgot to mention:

One benefit of MLQs over 'regular' playlists at least with BMP 2 is that i've introduced a concept of keeping track of tracks across mount point changes which basically works like this:

BMP stores for each file the HAL volume and device UDI, and the VRP (Volume Relative Path), that is, the path stripped off the mount point root.
Whenever it seems that a file is missing, it checks whether the volume UDI of this file is still present on the system, and if so, gathers the new mount point, and adjusts the URI of this
file in the library (this obiviously only works with tracks from the library only anyway since only there we can reliably store the HAL volume/device UDI and the VRP).

This means practically:

- Mount your music to /music
- Start BMP
- Add music from /music to the library
- Quit BMP
- Remount /music to e.g. /old_music
- Start BMP
- Use the library as before. Whenever BMP finds a file is missing, it will correct the URI on-the-fly as long as the volume is mounted at all on the system (and has an UDI to begin with; problem cases here are network volumes, NFS and SMBFS)

So the benefit of an MLQ is that unlike a static playlist, you can be rather sure that no matter where you really move the music, BMP will always be able to find it.

Downsides/doesn't-works:

- There is no volume UDI available
- You make a regular 'move' (mv), and not just a remount

In the context of having a common music database, or something like Tracker, this seems very useful (Jamie: Hence my urge to add HAL volume/device UDI per file to the metadata).

-- Milosz
------=_Part_3081_18949182.1150968777845-- From internalerror@gmail.com Thu Jun 22 06:23:10 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 61AE53B0403 for ; Thu, 22 Jun 2006 06:23:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15637-08 for ; Thu, 22 Jun 2006 06:23:09 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.195]) by menubar.gnome.org (Postfix) with ESMTP id 7534E3B045B for ; Thu, 22 Jun 2006 06:23:08 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so321629wxc for ; Thu, 22 Jun 2006 03:23:07 -0700 (PDT) Received: by 10.70.14.14 with SMTP id 14mr2842980wxn; Thu, 22 Jun 2006 03:23:07 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 03:23:07 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 12:23:07 +0200 From: "Milosz Derezynski" To: "Josef Spillner" Subject: Re: MLQ (Media Library Query) file format and mime type proposal In-Reply-To: <200606221139.41836.spillner@kde.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3405_33193106.1150971787566" References: <200606221139.41836.spillner@kde.org> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.443 tagged_above=-999 required=2 tests=[AWL=-0.496, BAYES_00=-2.599, HTML_10_20=1.351, HTML_MESSAGE=0.001, MIME_BASE64_NO_NAME=0.224, SPF_PASS=-0.001, TW_XD=0.077] X-Spam-Score: -1.443 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 10:23:10 -0000 ------=_Part_3405_33193106.1150971787566 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline WWVhaCB3ZWxsIGp1c3QgdG8gc3RheSB3aXRoaW4gdGhlIGZvY3VzIG9mIGEgbXVzaWMgbGlicmFy eSwgdGhlcmUgaGFzIHRvIGJlCnNvbWV0aGluZwp0aGF0IGRvZXMgdGhlIHJlc29sdXRpb24uCgpP TkUgcG9zc2libGUgb3B0aW9uIHdvdWxkIGJlIHRvIHNwZWNpZnkgYSBELUJVUyBpbnRlcmZhY2Ug bmFtZSwgYW5kIGEgaGF2ZQpzaW1wbGUgbGF1bmNoZXIuCgpBbGwgYXBwcyBzdXBwb3J0aW5nIE1M UXMgd291bGQgaGF2ZSB0byBoYXZlIGEgbWluaW1hbCBjb21tb24gc3Vic2V0Cm9mIEQtQlVTIGlu dGVyZmFjZXJ5IHRvIGFsbG93IHRoaXMga2luZCBvZiBxdWVyeSB0byBiZSBzZW50IHRvIHRoZW0g aW4gc29tZQp3YXkKKHNvbWV0aGluZyBsaWtlIGFuIEFkZFVyaSBjYWxsIG1pZ2h0IGp1c3Qgc3Vm ZmljZSksIHRoZW4gdGhlIGxhdW5jaGVyIHdvdWxkCmJhc2ljYWxseQpjb25zaXN0IG9mIHN0YXJ0 aW5nIHRoZSByZWxldmFudCBhcGxsaWNhdGlvbiB0cm91Z2ggRC1CVVMgYWN0aXZhdGlvbiwgYW5k CnRoZW4gcGFzcyBvbgp0aGUgYWN0dWFsIHF1ZXJ5IHRvIGl0LgoKKFdlIGhhdmUgYSBkdW1teSBt ZXRob2QgIlN0YXJ0dXAiIG9uIG91ciBELUJVUyBpZmFjZSB3aGljaApkb2VzIG5vdGhpbmcsIGJ1 dCBjYXVzZXMgRC1CVVMgdG8gc3RhcnQgdXAgQk1QLiBUaGUgcmVhc29uaW5nIGlzIHRoYXQgd2UK aGF2ZSBvbmUgbWFpbgpiaW5hcnkgYW5kIG9uZSAicmVtb3RlIiBiaW5hcnksIHdoaWNoIGlzIHRo b3VnaCBzZXQgc28gdGhhdCBpdCBpcyBwZXJjZWl2ZWQKYXMgYmVpbmcgdGhlIG1haW4KYmluYXJ5 LCBhcyBpbiBpdCdzIGluIC91c3IvYmluLCB3aGVyZWFzIHRoZSAtYmluIChtYWluKSBiaW5hcnkg aXMgaW4KL3Vzci9saWJleGVjLiBUaGUgcmVhc29uCmlzIHNvIHRoYXQgd2UgaGF2ZSBhIGxpZ2h0 d2VpZ2h0IHJlbW90ZSBhcHAgdGhhdCBjYW4gcGVyZm9ybSBhY3Rpb25zIG9uIHRoZQptYWluIGJp bmFyeQphbmQgZG9uJ3QgaGF2ZSB0byBoYXZlIHRoZSBtYWluIGFwcCBiZSBjYXBhYmxlIG9mIGJl aW5nIGEgY2xpZW50IHRvIGl0J3Mgb3duCnNlcnZlcgphbmQgaGF2ZSBhbGwgdGhlIHN0YXJ0dXAg c2hpenpsZSBnb2luZyBqdXN0IHRvIHBlcmZvcm0gYSBjZXJ0YWluIHJlbW90ZQpvcGVyYXRpb24p LgoKRm9yIGV4YW1wbGUgeW91J2QgaGF2ZToKcXVlcnk6Ly9vcmcuYmVlcG1lZGlhcGxheWVyLmJt cC8/YXJ0aXN0PUFpciZBbGJ1bT1Nb29uJTIwU2FmYXJpCgpUaGUgc2NyaXB0LCBvciBiZSBpdCBh IGJpbmFyeSwgbGV0J3MgY2FsbCBpdCAicGxheS1tbHEiLCB3b3VsZCBsYXVuY2ggdGhlCnBsYXll ciB3aXRoIHRoZSBzcGVjaWZpZWQgaW50ZXJmYWNlIGFuZCBwYXNzIGl0IHRoZSBhY3R1YWwgcXVl cnkuCgpfQW5vdGhlcl8gcG9zc2liaWxpdHksIGFsdGhvdWdoIHRoaXMgd291bGQgcmVxdWlyZSBw bGF5ZXJzIHRoYXQgY2FuIHdvcmsKd2l0aAptdXRhYmxlIHBsYXlsaXN0cyBsaWtlIEJNUCwgaXMg dGhhdCBpdCB3b3VsZCBwYXNzIHRoZSBxdWVyeSBvbiB0byBlLmcuCnNvbWV0aGluZwpsaWtlIFRy YWNrZXIgb3Igc29tZSBvdGhlciBpbmRleGVyLCB3aGljaCB3b3VsZCB0aGVuIGV4ZWN1dGUgdGhl IHF1ZXJ5IGFuZApfSVRfIHdvdWxkIHRoZW4gc3RhcnQgdGhlIHBsYXllciBzcGVjaWZpZWQgYnkg dGhlIGludGVyZmFjZSBhbmQgcGFzcyBpdAphbG9uZyB0aGUKcmVzdWx0aW5nIFVSSXMuCgotLSBN aWxvc3oKCk9uIDYvMjIvMDYsIEpvc2VmIFNwaWxsbmVyIDxzcGlsbG5lckBrZGUub3JnPiB3cm90 ZToKPgo+IEFsbGUgMTE6MjUsIGdpb3ZlZMOsLCAyMi4gZ2l1Z25vIDIwMDYsIE1pbG9zeiBEZXJl enluc2tpIGhhIHNjcml0dG86Cj4gPiBTaW5jZSB0aGlzIGlzIHZlcnkgY29tbW9uLCBhbmQgaGF2 aW5nIHRoZSBkaXNjdXNzaW9ucyBhYm91dCBhIGNvbW1vbgo+IG11c2ljCj4gPiBkYXRhYmFzZSBp biBtaW5kLCB0aGlzIHNlZW1zIGxpa2UgYSB1c2VmdWwgcHJvcG9zYWwsIHNpbmNlIGl0IGlzIG5v dAo+IHBsYXllcgo+ID4gc3BlY2lmaWMuCj4KPiBJdCBpcyBub3QgZXZlbiBtdXNpYyBzcGVjaWZp Yy4gSSd2ZSB1c2VkIHF1ZXJ5Oi8vIFVSSXMgZm9yIGEgbG9uZyB0aW1lCj4gd2l0aAo+IG1ldGFz ZXJ2ZXJzLCBhbHRob3VnaCBvbmx5IGluIGEgcmVhZC1vbmx5IGNvbnRleHQsIHdoZXJlYXMgZm9y IHdyaXRlCj4gYWNjZXNzCj4gdGhlIChhbHRlcm5hdGl2ZSkgZnVsbC1ibG93biBYTUwgaW50ZXJm YWNlIGlzIHVzZWQuCj4KPiBUaGUgd2F5IGl0IGlzIHVzZWQgZm9yIHRoZSBtZXRhc2VydmVyIGlz IGxpa2UgcXVlcnk6Ly90eXBlL2NhdGVnb3J5LCB3aGVyZQo+IGUuZy4gdHlwZSB3b3VsZCBiZSB0 aGUgZ2VuZXJpYyBuYW1lIGZvciBhIHNlcnZlciAoc2F5LCAnZnJlZWNpdicgb3IKPiAnY3Vwc2Qn KQo+IGFuZCBjYXRlZ29yeSB3b3VsZCBiZSAnY29ubmVjdGlvbicgKHRvIGdldCBiYWNrIGEgY29u bmVjdGlvbiBVUkkpIG9yCj4gJ21ldGEnCj4gKHRvIGdldCBiYWNrIG90aGVyIG1ldGFzZXJ2ZXIg VVJJcyBmb3IgdGhlIHNhbWUgdHlwZSkuCj4gVXNpbmcgc3VjaCBhIHNjaGVtZSBtYWtlcyBhbiBh cHBsaWNhdGlvbiByZXNpc3RhbnQgYWdhaW5zdCBob3N0IG5hbWUKPiBjaGFuZ2VzCj4gaW4gdGhl IGxvbmcgcnVuLCBpLmUuIGl0IHdpbGwgcGljayB1cCBtb3Zpbmcgc2VydmVycyBhdXRvbWF0aWNh bGx5Lgo+Cj4gVGhpcyBpcyBwcm9iYWJseSBub3QgdGhlIHNhbWUgdGhpbmcgYXMgeW91ciBxdWVy eSwgYnV0IG9idmlvdXNseSBpdCdzIGFsc28KPiB1c2VkIHRvIHF1ZXJ5IGEgZGF0YWJhc2UgYmVo aW5kIGl0ICh3aGljaCBpcyBhIFhNTCBkYXRhYmFzZSBpbiBteSBjYXNlLAo+IGJ1dAo+IGNvdWxk IGJlIFNRTCBvciBhbnl0aGluZyBlbHNlIGZvciB0aGF0IG1hdHRlcikuIFNvIG1heWJlIGl0IG1h a2VzIHNlbnNlIHRvCj4gc3RhbmRhcmRpc2UgdGhpcyBpbiBhIGJyb2FkZXIgY29udGV4dC4KPgo+ IEtERSBSYWRpbyBTdGF0aW9uIGlzIG9uZSBleGFtcGxlIHdoZXJlIHRoaXMgaXMgdXNlZCAoaGEg LSBmb3VuZCBhIHJlbGF0aW9uCj4gdG8KPiBtdXNpYyEpLCBhbmQgdGhlIEdHWiBHYW1pbmcgWm9u ZSBwcm9qZWN0IGlzIGFub3RoZXIgb25lICh3aGVyZSBpdAo+IG9yaWdpbmF0ZWQKPiBzaW5jZSBt ZXRhc2VydmVycyBhcmUgY29tbW9ucGxhY2Ugd2l0aCBnYW1lIHNlcnZlcnMpLgo+Cj4gSm9zZWYK PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IHhkZyBt YWlsaW5nIGxpc3QKPiB4ZGdAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCj4gaHR0cDovL2xpc3RzLmZy ZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hkZwo+Cg== ------=_Part_3405_33193106.1150971787566 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline WWVhaCB3ZWxsIGp1c3QgdG8gc3RheSB3aXRoaW4gdGhlIGZvY3VzIG9mIGEgbXVzaWMgbGlicmFy eSwgdGhlcmUgaGFzIHRvIGJlIHNvbWV0aGluZzxicj50aGF0IGRvZXMgdGhlIHJlc29sdXRpb24u PGJyPjxicj5PTkUgcG9zc2libGUgb3B0aW9uIHdvdWxkIGJlIHRvIHNwZWNpZnkgYSBELUJVUyBp bnRlcmZhY2UgbmFtZSwgYW5kIGEgaGF2ZSBzaW1wbGUgbGF1bmNoZXIuPGJyPjxicj5BbGwgYXBw cyBzdXBwb3J0aW5nIE1MUXMgd291bGQgaGF2ZSB0byBoYXZlIGEgbWluaW1hbCBjb21tb24gc3Vi c2V0Cjxicj5vZiBELUJVUyBpbnRlcmZhY2VyeSB0byBhbGxvdyB0aGlzIGtpbmQgb2YgcXVlcnkg dG8gYmUgc2VudCB0byB0aGVtIGluIHNvbWUgd2F5PGJyPihzb21ldGhpbmcgbGlrZSBhbiBBZGRV cmkgY2FsbCBtaWdodCBqdXN0IHN1ZmZpY2UpLCB0aGVuIHRoZSBsYXVuY2hlciB3b3VsZCBiYXNp Y2FsbHk8YnI+Y29uc2lzdCBvZiBzdGFydGluZyB0aGUgcmVsZXZhbnQgYXBsbGljYXRpb24gdHJv dWdoIEQtQlVTIGFjdGl2YXRpb24sIGFuZCB0aGVuIHBhc3Mgb24KPGJyPnRoZSBhY3R1YWwgcXVl cnkgdG8gaXQuIDxicj48YnI+KFdlIGhhdmUgYSBkdW1teSBtZXRob2QgJnF1b3Q7U3RhcnR1cCZx dW90OyBvbiBvdXIgRC1CVVMgaWZhY2Ugd2hpY2g8YnI+ZG9lcyBub3RoaW5nLCBidXQgY2F1c2Vz IEQtQlVTIHRvIHN0YXJ0IHVwIEJNUC4gVGhlIHJlYXNvbmluZyBpcyB0aGF0IHdlIGhhdmUgb25l IG1haW48YnI+YmluYXJ5IGFuZCBvbmUgJnF1b3Q7cmVtb3RlJnF1b3Q7IGJpbmFyeSwgd2hpY2gg aXMgdGhvdWdoIHNldCBzbyB0aGF0IGl0IGlzIHBlcmNlaXZlZCBhcyBiZWluZyB0aGUgbWFpbgo8 YnI+YmluYXJ5LCBhcyBpbiBpdCdzIGluIC91c3IvYmluLCB3aGVyZWFzIHRoZSAtYmluIChtYWlu KSBiaW5hcnkgaXMgaW4gL3Vzci9saWJleGVjLiBUaGUgcmVhc29uPGJyPmlzIHNvIHRoYXQgd2Ug aGF2ZSBhIGxpZ2h0d2VpZ2h0IHJlbW90ZSBhcHAgdGhhdCBjYW4gcGVyZm9ybSBhY3Rpb25zIG9u IHRoZSBtYWluIGJpbmFyeTxicj5hbmQgZG9uJ3QgaGF2ZSB0byBoYXZlIHRoZSBtYWluIGFwcCBi ZSBjYXBhYmxlIG9mIGJlaW5nIGEgY2xpZW50IHRvIGl0J3Mgb3duIHNlcnZlcgo8YnI+YW5kIGhh dmUgYWxsIHRoZSBzdGFydHVwIHNoaXp6bGUgZ29pbmcganVzdCB0byBwZXJmb3JtIGEgY2VydGFp biByZW1vdGUgb3BlcmF0aW9uKS48YnI+PGJyPkZvciBleGFtcGxlIHlvdSdkIGhhdmU6PGJyPnF1 ZXJ5Oi8vb3JnLmJlZXBtZWRpYXBsYXllci5ibXAvP2FydGlzdD1BaXImYW1wO0FsYnVtPU1vb24l MjBTYWZhcmk8YnI+PGJyPlRoZSBzY3JpcHQsIG9yIGJlIGl0IGEgYmluYXJ5LCBsZXQncyBjYWxs IGl0ICZxdW90O3BsYXktbWxxJnF1b3Q7LCB3b3VsZCBsYXVuY2ggdGhlCjxicj5wbGF5ZXIgd2l0 aCB0aGUgc3BlY2lmaWVkIGludGVyZmFjZSBhbmQgcGFzcyBpdCB0aGUgYWN0dWFsIHF1ZXJ5Ljxi cj48YnI+X0Fub3RoZXJfIHBvc3NpYmlsaXR5LCBhbHRob3VnaCB0aGlzIHdvdWxkIHJlcXVpcmUg cGxheWVycyB0aGF0IGNhbiB3b3JrIHdpdGg8YnI+bXV0YWJsZSBwbGF5bGlzdHMgbGlrZSBCTVAs IGlzIHRoYXQgaXQgd291bGQgcGFzcyB0aGUgcXVlcnkgb24gdG8gCmUuZy4gc29tZXRoaW5nPGJy Pmxpa2UgVHJhY2tlciBvciBzb21lIG90aGVyIGluZGV4ZXIsIHdoaWNoIHdvdWxkIHRoZW4gZXhl Y3V0ZSB0aGUgcXVlcnkgYW5kPGJyPl9JVF8gd291bGQgdGhlbiBzdGFydCB0aGUgcGxheWVyIHNw ZWNpZmllZCBieSB0aGUgaW50ZXJmYWNlIGFuZCBwYXNzIGl0IGFsb25nIHRoZTxicj5yZXN1bHRp bmcgVVJJcy48YnI+PGJyPi0tIE1pbG9zejxicj48YnI+CjxkaXY+PHNwYW4gY2xhc3M9ImdtYWls X3F1b3RlIj5PbiA2LzIyLzA2LCA8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+Sm9zZWYgU3Bp bGxuZXI8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86c3BpbGxuZXJAa2RlLm9yZyI+c3BpbGxuZXJA a2RlLm9yZzwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv dGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFy Z2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4KQWxsZSAxMToyNSwg Z2lvdmVkw6wsIDIyLiBnaXVnbm8gMjAwNiwgTWlsb3N6IERlcmV6eW5za2kgaGEgc2NyaXR0bzo8 YnI+Jmd0OyBTaW5jZSB0aGlzIGlzIHZlcnkgY29tbW9uLCBhbmQgaGF2aW5nIHRoZSBkaXNjdXNz aW9ucyBhYm91dCBhIGNvbW1vbiBtdXNpYzxicj4mZ3Q7IGRhdGFiYXNlIGluIG1pbmQsIHRoaXMg c2VlbXMgbGlrZSBhIHVzZWZ1bCBwcm9wb3NhbCwgc2luY2UgaXQgaXMgbm90IHBsYXllcgo8YnI+ Jmd0OyBzcGVjaWZpYy48YnI+PGJyPkl0IGlzIG5vdCBldmVuIG11c2ljIHNwZWNpZmljLiBJJ3Zl IHVzZWQgcXVlcnk6Ly8gVVJJcyBmb3IgYSBsb25nIHRpbWUgd2l0aDxicj5tZXRhc2VydmVycywg YWx0aG91Z2ggb25seSBpbiBhIHJlYWQtb25seSBjb250ZXh0LCB3aGVyZWFzIGZvciB3cml0ZSBh Y2Nlc3M8YnI+dGhlIChhbHRlcm5hdGl2ZSkgZnVsbC1ibG93biBYTUwgaW50ZXJmYWNlIGlzIHVz ZWQuCjxicj48YnI+VGhlIHdheSBpdCBpcyB1c2VkIGZvciB0aGUgbWV0YXNlcnZlciBpcyBsaWtl IHF1ZXJ5Oi8vdHlwZS9jYXRlZ29yeSwgd2hlcmU8YnI+ZS5nLiB0eXBlIHdvdWxkIGJlIHRoZSBn ZW5lcmljIG5hbWUgZm9yIGEgc2VydmVyIChzYXksICdmcmVlY2l2JyBvciAnY3Vwc2QnKTxicj5h bmQgY2F0ZWdvcnkgd291bGQgYmUgJ2Nvbm5lY3Rpb24nICh0byBnZXQgYmFjayBhIGNvbm5lY3Rp b24gVVJJKSBvciAnbWV0YScKPGJyPih0byBnZXQgYmFjayBvdGhlciBtZXRhc2VydmVyIFVSSXMg Zm9yIHRoZSBzYW1lIHR5cGUpLjxicj5Vc2luZyBzdWNoIGEgc2NoZW1lIG1ha2VzIGFuIGFwcGxp Y2F0aW9uIHJlc2lzdGFudCBhZ2FpbnN0IGhvc3QgbmFtZSBjaGFuZ2VzPGJyPmluIHRoZSBsb25n IHJ1biwgaS5lLiBpdCB3aWxsIHBpY2sgdXAgbW92aW5nIHNlcnZlcnMgYXV0b21hdGljYWxseS48 YnI+PGJyPlRoaXMgaXMgcHJvYmFibHkgbm90IHRoZSBzYW1lIHRoaW5nIGFzIHlvdXIgcXVlcnks IGJ1dCBvYnZpb3VzbHkgaXQncyBhbHNvCjxicj51c2VkIHRvIHF1ZXJ5IGEgZGF0YWJhc2UgYmVo aW5kIGl0ICh3aGljaCBpcyBhIFhNTCBkYXRhYmFzZSBpbiBteSBjYXNlLCBidXQ8YnI+Y291bGQg YmUgU1FMIG9yIGFueXRoaW5nIGVsc2UgZm9yIHRoYXQgbWF0dGVyKS4gU28gbWF5YmUgaXQgbWFr ZXMgc2Vuc2UgdG88YnI+c3RhbmRhcmRpc2UgdGhpcyBpbiBhIGJyb2FkZXIgY29udGV4dC48YnI+ PGJyPktERSBSYWRpbyBTdGF0aW9uIGlzIG9uZSBleGFtcGxlIHdoZXJlIHRoaXMgaXMgdXNlZCAo aGEgLSBmb3VuZCBhIHJlbGF0aW9uIHRvCjxicj5tdXNpYyEpLCBhbmQgdGhlIEdHWiBHYW1pbmcg Wm9uZSBwcm9qZWN0IGlzIGFub3RoZXIgb25lICh3aGVyZSBpdCBvcmlnaW5hdGVkPGJyPnNpbmNl IG1ldGFzZXJ2ZXJzIGFyZSBjb21tb25wbGFjZSB3aXRoIGdhbWUgc2VydmVycykuPGJyPjxicj5K b3NlZjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj54ZGcgbWFpbGluZyBsaXN0Cjxicj48YSBocmVmPSJtYWlsdG86eGRnQGxpc3RzLmZyZWVkZXNr dG9wLm9yZyI+eGRnQGxpc3RzLmZyZWVkZXNrdG9wLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cDov L2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hkZyI+aHR0cDovL2xpc3Rz LmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hkZzwvYT48YnI+PC9ibG9ja3F1b3Rl PjwvZGl2Pjxicj4K ------=_Part_3405_33193106.1150971787566-- From jamiemcc@blueyonder.co.uk Thu Jun 22 06:41:17 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 687D03B0251 for ; Thu, 22 Jun 2006 06:41:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17075-06 for ; Thu, 22 Jun 2006 06:41:15 -0400 (EDT) Received: from smtp-out5.blueyonder.co.uk (smtp-out5.blueyonder.co.uk [195.188.213.8]) by menubar.gnome.org (Postfix) with ESMTP id 74F7B3B021B for ; Thu, 22 Jun 2006 06:41:15 -0400 (EDT) Received: from [172.23.170.145] (helo=anti-virus03-08) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1FtMca-0004xo-T2; Thu, 22 Jun 2006 11:41:12 +0100 Received: from [62.30.198.187] (helo=[62.30.198.187]) by asmtp-out2.blueyonder.co.uk with esmtpa (Exim 4.52) id 1FtMcZ-0001pP-Rp; Thu, 22 Jun 2006 11:41:11 +0100 Message-ID: <449A73D1.6030401@blueyonder.co.uk> Date: Thu, 22 Jun 2006 11:41:21 +0100 From: Jamie McCracken User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Milosz Derezynski Subject: Re: MLQ: Followup References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.459 tagged_above=-999 required=2 tests=[AWL=0.141, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.459 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 10:41:17 -0000 Milosz Derezynski wrote: > What i forgot to mention: > > One benefit of MLQs over 'regular' playlists at least with BMP 2 is that > i've introduced a concept of keeping track of tracks across mount point > changes which basically works like this: > > BMP stores for each file the HAL volume and device UDI, and the VRP > (Volume Relative Path), that is, the path stripped off the mount point root. > Whenever it seems that a file is missing, it checks whether the volume > UDI of this file is still present on the system, and if so, gathers the > new mount point, and adjusts the URI of this > file in the library (this obiviously only works with tracks from the > library only anyway since only there we can reliably store the HAL > volume/device UDI and the VRP). > > This means practically: > > - Mount your music to /music > - Start BMP > - Add music from /music to the library > - Quit BMP > - Remount /music to e.g. /old_music > - Start BMP > - Use the library as before. Whenever BMP finds a file is missing, it > will correct the URI on-the-fly as long as the volume is mounted at all > on the system (and has an UDI to begin with; problem cases here are > network volumes, NFS and SMBFS) > > So the benefit of an MLQ is that unlike a static playlist, you can be > rather sure that no matter where you really move the music, BMP will > always be able to find it. > > Downsides/doesn't-works: > > - There is no volume UDI available > - You make a regular 'move' (mv), and not just a remount > > In the context of having a common music database, or something like > Tracker, this seems very useful (Jamie: Hence my urge to add HAL > volume/device UDI per file to the metadata). Im quite happy to add this as metadata to tracker and even get tracker to hide stuff based on it (using hal) but it still needs to be part of the uri for a music file (otherwise we wont be able to uniquely identify the files) -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ From jamiemcc@blueyonder.co.uk Thu Jun 22 06:52:34 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 93DEE3B031A for ; Thu, 22 Jun 2006 06:52:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17877-10 for ; Thu, 22 Jun 2006 06:52:32 -0400 (EDT) Received: from smtp-out5.blueyonder.co.uk (smtp-out5.blueyonder.co.uk [195.188.213.8]) by menubar.gnome.org (Postfix) with ESMTP id 66C8B3B0262 for ; Thu, 22 Jun 2006 06:52:32 -0400 (EDT) Received: from [172.23.170.140] (helo=anti-virus02-07) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1FtMnX-0007Tp-4T; Thu, 22 Jun 2006 11:52:31 +0100 Received: from [62.30.198.187] (helo=[62.30.198.187]) by asmtp-out1.blueyonder.co.uk with esmtpa (Exim 4.52) id 1FtMnU-0001TX-7r; Thu, 22 Jun 2006 11:52:28 +0100 Message-ID: <449A7676.6060309@blueyonder.co.uk> Date: Thu, 22 Jun 2006 11:52:38 +0100 From: Jamie McCracken User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Milosz Derezynski Subject: Re: MLQ (Media Library Query) file format and mime type proposal References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.422 tagged_above=-999 required=2 tests=[AWL=0.101, BAYES_00=-2.599, SPF_PASS=-0.001, TW_RQ=0.077] X-Spam-Score: -2.422 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 10:52:34 -0000 Milosz Derezynski wrote: > Hi, > > I'm one of the main authors of BMP 2 (still being worked on), and along > the way of reworking our library, i came across the idea of encoding > library queries as URIs, which may look like this: > > "query:///?artist=Air&album=Moon%20Safari" > > BMP 2 has a plugin archicture which is a small VFS on it's own, and we > treat certain things as "containers" (i.e. they "contain" URIs, like PLS > playlists, XSPF, M3U, etc). > Now i thought it might be not a bad idea to create a playlist format > with these query URLs, and i've called it "MLQ" for media library query. > In theory, it's not even > application specific. The keys (identifiers), like artist, album, etc, > are all based on GStreamer tag identifiers. (They could be maybe adapted > to http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , > but it seems insufficient and doesn't specify certain items, like > musicbrainz metadata, which GST does). Tracker's metadata spec does (http://freedesktop.org/wiki/Standards/shared-filemetadata-spec) > > So i've called this file format "MLQ", with the extension .mlq, created > a mime package file for it: > > > > > Media Library Query List > > > > > > > > Adding a file of this type to BMPx, or just a plain query:/// URI itself > causes a library query and appending of the relevant items to the > tracklist (BMP is currently mostly based on the concept of a mutable > playlist to which items can be added from various sources, unlike e.g. > RB which has mostly immutable "Playlists", but allows for custom queues). > > Another example is: > > query:///?artist=Air&album=Moon%20Safari&title=La%20Femme%20d'Argent > query:///?artist=Air&album=Moon%20Safari&title=Sexy%20Boy > query:///?artist=Air&album=Moon%20Safari&title=All%20I%20Need > query:///?artist=Air&album=Moon%20Safari&title=Kelly,%20Watch%20The%20Stars! > query:///?artist=Air&album=Moon%20Safari&title=Talisman > query:///?artist=Air&album=Moon%20Safari&title=Remember > query:///?artist=Air&album=Moon%20Safari&title=You%20Make%20It%20Easy > query:///?artist=Air&album=Moon%20Safari&title=Ce%20Matin%20La > query:///?artist=Air&album=Moon%20Safari&title=New%20Star%20In%20The%20Sky > query:///?artist=Air&album=Moon%20Safari&title=Le%20Voyage%20De%20Penelope > > Or it might just be: > > query:///?genre=Jazz > > Since this is very common, and having the discussions about a common > music database in mind, this seems like a useful proposal, since it is > not player specific. > This ships currently with BMP 2/BMPx SVN, and while i will ship this > with the 0.20 release (end-July) anyway, what does everyone think of > this in a broader context (common music database, etc)? Could be interesting as an alternative to rdf query that tracker uses but rdf query is a *standard* and is the WC3's recommended means of querying metadata. A more compact version of the xml based rdf query language is sparql (http://www.w3.org/TR/rdf-sparql-query/) and is also a candidate for standardisation. I guess its going to be fun deciding which to use (I will go with the flow) -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ From doclivingston@gmail.com Thu Jun 22 07:00:08 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 966243B038B for ; Thu, 22 Jun 2006 07:00:08 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18372-10 for ; Thu, 22 Jun 2006 07:00:05 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by menubar.gnome.org (Postfix) with ESMTP id 2DC8B3B00ED for ; Thu, 22 Jun 2006 07:00:05 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id f25so276546pyf for ; Thu, 22 Jun 2006 04:00:04 -0700 (PDT) Received: by 10.35.91.15 with SMTP id t15mr948347pyl; Thu, 22 Jun 2006 04:00:04 -0700 (PDT) Received: from alyrion.local ( [144.139.19.209]) by mx.gmail.com with ESMTP id w28sm110735pyc.2006.06.22.04.00.02; Thu, 22 Jun 2006 04:00:04 -0700 (PDT) Subject: Re: MLQ: Followup From: "James \"Doc\" Livingston" To: gnome-multimedia@gnome.org In-Reply-To: References: Content-Type: text/plain Date: Thu, 22 Jun 2006 20:59:59 +1000 Message-Id: <1150973999.5186.17.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.317 tagged_above=-999 required=2 tests=[AWL=0.283, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.317 X-Spam-Level: X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: doclivingston@gmail.com List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 11:00:08 -0000 On Thu, 2006-06-22 at 11:32 +0200, Milosz Derezynski wrote: > One benefit of MLQs over 'regular' playlists at least with BMP 2 is > that i've introduced a concept of keeping track of tracks across mount > point changes which basically works like this: > So the benefit of an MLQ is that unlike a static playlist, you can be > rather sure that no matter where you really move the music, BMP will > always be able to find it. I'm a bit confused about how "HAL UDI + partial path" is related to the MLQ idea. To me they seem fairly orthogonal. However using HAL UDIs is a good idea. Most apps currently use the URI as it's unique identifier and the method of finding the actual file, we could decide that the common db would use a as the unique id/location method. > Downsides/doesn't-works: > - There is no volume UDI available If this is a permanent thing, e.g. a non-HAL system or a http:// resource, then we could say that a null UDI and the full uri would be used instead. If it's temporary, e.g. HAL isn't running, or isn't detecting the device properly, then it's probably more complicated. Dealing with the fact that the users music is stored as and we don't know the URI would be funky. Perhaps we could say all db entries have the field, and a "last known"/non-HAL location field. > - You make a regular 'move' (mv), and not just a remount That is different again, and is probably best solved with audio fingerprinting, and/or embedding unique metadata in the file. Cheers. James "Doc" Livingston -- If USENET is anarchy, IRC is a paranoid schizophrenic after 6 days on speed. -- Chris "Saundo" Saunderson in asr. From doclivingston@gmail.com Thu Jun 22 07:04:28 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CFF783B0254 for ; Thu, 22 Jun 2006 07:04:28 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18854-05 for ; Thu, 22 Jun 2006 07:04:27 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by menubar.gnome.org (Postfix) with ESMTP id 0309C3B05B2 for ; Thu, 22 Jun 2006 07:04:26 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id f28so267516pyf for ; Thu, 22 Jun 2006 04:04:26 -0700 (PDT) Received: by 10.35.82.15 with SMTP id j15mr949278pyl; Thu, 22 Jun 2006 04:04:26 -0700 (PDT) Received: from alyrion.local ( [144.139.19.209]) by mx.gmail.com with ESMTP id w66sm860753pyw.2006.06.22.04.04.24; Thu, 22 Jun 2006 04:04:26 -0700 (PDT) Subject: Re: MLQ (Media Library Query) file format and mime type proposal From: "James \"Doc\" Livingston" To: gnome-multimedia@gnome.org In-Reply-To: References: Content-Type: text/plain Date: Thu, 22 Jun 2006 21:04:21 +1000 Message-Id: <1150974261.5186.22.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.319 tagged_above=-999 required=2 tests=[AWL=0.281, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.319 X-Spam-Level: X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: doclivingston@gmail.com List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 11:04:29 -0000 On Thu, 2006-06-22 at 11:25 +0200, Milosz Derezynski wrote: > I'm one of the main authors of BMP 2 (still being worked on), and > along the way of reworking our library, i came across the idea of > encoding library queries as URIs, which may look like this: > > "query:///?artist=Air&album=Moon%20Safari" > Adding a file of this type to BMPx, or just a plain query:/// URI > itself causes a library query and appending of the relevant items to > the tracklist (BMP is currently mostly based on the concept of a > mutable playlist to which items can be added from various sources, > unlike e.g. RB which has mostly immutable "Playlists", but allows for > custom queues). I'm a bit confused as to what this is actually for. Is it meant for saving "smart playlist"-type (or other db queries) things to disk? If so, it's probably better to use one of the existing query formats. If we want to use XML, then RDF (which is what Tracker uses for all it's queries) is probably as good as anything. James "Doc" Livingston -- "The Web brings people together because no matter what kind of a twisted sexual mutant you happen to be, you've got millions of pals out there. Type in 'Find people that have sex with goats that are on fire' and the computer will ask, 'Specify type of goat.'" -- Rich Jeni From internalerror@gmail.com Thu Jun 22 07:35:27 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BBE833B064F for ; Thu, 22 Jun 2006 07:35:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20711-02 for ; Thu, 22 Jun 2006 07:35:26 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.197]) by menubar.gnome.org (Postfix) with ESMTP id 1F4E83B0528 for ; Thu, 22 Jun 2006 07:35:26 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so334141wxc for ; Thu, 22 Jun 2006 04:35:26 -0700 (PDT) Received: by 10.70.65.10 with SMTP id n10mr2935604wxa; Thu, 22 Jun 2006 04:35:25 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 04:35:25 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 13:35:25 +0200 From: "Milosz Derezynski" To: doclivingston@gmail.com Subject: Re: MLQ: Followup In-Reply-To: <1150973999.5186.17.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3961_29338319.1150976125920" References: <1150973999.5186.17.camel@localhost.localdomain> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.246 tagged_above=-999 required=2 tests=[AWL=0.353, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.246 X-Spam-Level: Cc: gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 11:35:27 -0000 ------=_Part_3961_29338319.1150976125920 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/22/06, James Doc Livingston wrote: If it's temporary, e.g. HAL isn't running, or isn't detecting the device > properly, then it's probably more complicated. Dealing with the fact > that the users music is stored as and we don't know the URI > would be funky. Perhaps we could say all db entries have the > field, and a "last known"/non-HAL location field. > That's what i'm currently doing, i store the full URI, but also the UDI and the partial path, and in case HAL is not avaiable there is still the full URI present as a current resort. The ideal situation would be that HAL would be always available, would have UDIs for all volumes, and would run on all systems we need to run this to (Including let's say Solaris, etc), in which case it would be exactly what you said, one would need to only store the volume UDI and the partial path. Well anyway, repeating myself, just wanted to add that we also already store the full URI as a backup. ------=_Part_3961_29338319.1150976125920 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 6/22/06, James Doc Livingston <doclivingston@gmail.com> wrote:

If it's temporary, e.g. HAL isn't running, or isn't detecting the device
properly, then it's probably more complicated. Dealing with the fact
that the users music is stored as <UDI, path> and we don't know the URI
would be funky. Perhaps we could say all db entries have the <UDI, path>
field, and a "last known"/non-HAL location field.


That's what i'm currently doing, i store the full URI, but also the UDI and the partial path,
and in case HAL is not avaiable there is still the full URI present as a current resort.

The ideal situation would be that HAL would be always available, would have UDIs for all
volumes, and would run on all systems we need to run this to (Including let's say Solaris,
etc), in which case it would be exactly what you said, one would need to only store the volume
UDI and the partial path. Well anyway, repeating myself, just wanted to add that we also
already store the full URI as a backup.
------=_Part_3961_29338319.1150976125920-- From internalerror@gmail.com Thu Jun 22 12:04:05 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 802573B0830 for ; Thu, 22 Jun 2006 12:04:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07916-06 for ; Thu, 22 Jun 2006 12:04:01 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.201]) by menubar.gnome.org (Postfix) with ESMTP id 35C833B083F for ; Thu, 22 Jun 2006 12:01:33 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so373874wxc for ; Thu, 22 Jun 2006 09:01:32 -0700 (PDT) Received: by 10.70.83.20 with SMTP id g20mr3337015wxb; Thu, 22 Jun 2006 09:01:32 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 09:01:32 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 18:01:32 +0200 From: "Milosz Derezynski" To: "Frans Englich" Subject: Re: MLQ (Media Library Query) file format and mime type proposal In-Reply-To: <200606221419.00204.frans.englich@telia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7583_10781705.1150992092417" References: <200606221419.00204.frans.englich@telia.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.073 tagged_above=-999 required=2 tests=[AWL=0.152, BAYES_00=-2.599, HTML_30_40=0.374, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.073 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 16:04:05 -0000 ------=_Part_7583_10781705.1150992092417 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/22/06, Frans Englich wrote: > > On Thursday 22 June 2006 09:25, Milosz Derezynski wrote: > > Hi, > > > > I'm one of the main authors of BMP 2 (still being worked on), and along > the > > way of reworking our library, i came across the idea of encoding library > > queries as URIs, which may look like this: > > > > "query:///?artist=Air&album=Moon%20Safari" > > (Is that at all a valid URI? I'm not sure.) I think it is valid yes. First of all, one can't simply invent ones own URI scheme, because it causes > trouble. Especially, for such a generic name as "query". This document > discusses this further: > > http://developer.kde.org/policies/uri-guidelines.xhtml > > How is interoperability for "query" ensured? Is it specified? Not at all yet but because of that i'm asking on those 2 lists here now (xdg and gnome-multimedia), and furthermore i made some interoperability proposals, just 2 totally off my head but not totally out of place either. > BMP 2 has a plugin archicture which is a small VFS on it's own, and we > > treat certain things as "containers" (i.e. they "contain" URIs, like PLS > > playlists, XSPF, M3U, etc). > > Now i thought it might be not a bad idea to create a playlist format > with > > these query URLs, and i've called it "MLQ" for media library query. In > > theory, it's not even > > application specific. The keys (identifiers), like artist, album, etc, > are > > all based on GStreamer tag identifiers. (They could be maybe adapted to > > http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , > but > > it seems insufficient and doesn't specify certain items, like > musicbrainz > > metadata, which GST does). > > > > So i've called this file format "MLQ", with the extension .mlq, created > a > > mime package file for it: > > I think this highlights possible trouble. Anyone else who decides to > invent "query" will get detected as "Media Library Query List". All that's > needed to fix this is to use URIs properly. Yeah well that is problematic for them haha :P > However, I wouldn't invent a new URI scheme for this, it's too context > dependent. Music players & hardware(ipods, music players, music sharing > sites, and so on) is quite popular in western societies right now, but > next > year it's something different. Technologies, such as a URI scheme, > shouldn't > be hard coded on a specific use, it should be generic. > > Re-use existing technologies. There's plenty of work and research on meta > data > and querying data. Here's my suggestions: > > Express the format in XML. This has nothing to do with XML files("text"), > unless one wants to. It means the format is conceptually, on an "abstract" > level, described in XML which in turn opens up the door for all methods > XML > has. > > For example, one could use an XPointer fragment with an XPath scheme: > > file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album > = 'Safari')) > > If "music collections" cannot be located as files, invent a scheme which > can > identify them on this "abstract level." That is actually a very good idea (to use an XPath), but then again i would be abusing the file:/// scheme. What should it point to? Even if it would point to the physical location of the database file, in my specific case this would be ~/.local/share/bmpx/library.mlib, so file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz and @album='Safari')), then i would be basically still "making something up", as you cannot pass THIS uri to, say, a filemanager, and it would recognize it and do the correct thing. Now of course it won't recognize query:/// either, but i made 2 proposals which would spec query:/// in this way system wide. What i'm up to is that while your proposal with file seems more sane (and XPath/XPointer is certainly better than using a GET string, i might really consider changing the query:/// URI to use that), it actually is no different. Those kinds of file:/// URIs would need special treatment as well, and in fact, would cause even more headache possibly, as file:/// _IS_ already a known scheme which is already specced etc, etd. However, I would first assess RDF as suggested in this thread, since it is > designed exactly for things like this. Well RDF possibly, but i think i will never in my life use SPARQL. I took a look at it and i want these things if not neccessarily, then at least possibly, human editable, buit SPARQL is just way beyond the comprehension of taking a quick glance at the file and making some corrections. > > Cheers, > > Frans > -- Milosz ------=_Part_7583_10781705.1150992092417 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 6/22/06, Frans Englich <frans.englich@telia.com> wrote:
On Thursday 22 June 2006 09:25, Milosz Derezynski wrote:
> Hi,
>
> I'm one of the main authors of BMP 2 (still being worked on), and along the
> way of reworking our library, i came across the idea of encoding library
> queries as URIs, which may look like this:
>
> "query:///?artist=Air&album=Moon%20Safari"

(Is that at all a valid URI? I'm not sure.)

I think it is valid yes.

First of all, one can't simply invent ones own URI scheme, because it causes
trouble. Especially, for such a generic name as "query". This document
discusses this further:

http://developer.kde.org/policies/uri-guidelines.xhtml

How is interoperability for "query" ensured? Is it specified?

Not at all yet but  because of that i'm asking on those 2 lists here now (xdg
and gnome-multimedia), and furthermore i made some interoperability
proposals, just 2 totally off my head but not totally out of place either.
 

> BMP 2 has a plugin archicture which is a small VFS on it's own, and we
> treat certain things as "containers" (i.e. they "contain" URIs, like PLS
> playlists, XSPF, M3U, etc).
> Now i thought it might be not a bad idea to create a playlist format with
> these query URLs, and i've called it "MLQ" for media library query. In
> theory, it's not even
> application specific. The keys (identifiers), like artist, album, etc, are
> all based on GStreamer tag identifiers. (They could be maybe adapted to
> http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but
> it seems insufficient and doesn't specify certain items, like musicbrainz
> metadata, which GST does).
>
> So i've called this file format "MLQ", with the extension .mlq, created a
> mime package file for it:

I think this highlights possible trouble. Anyone else who decides to
invent "query" will get detected as "Media Library Query List". All that's
needed to fix this is to use URIs properly.

Yeah well that is problematic for them haha :P
 
However, I wouldn't invent a new URI scheme for this, it's too context
dependent. Music players & hardware(ipods, music players, music sharing
sites, and so on) is quite popular in western societies right now, but next
year it's something different. Technologies, such as a URI scheme, shouldn't
be hard coded on a specific use, it should be generic.

Re-use existing technologies. There's plenty of work and research on meta data
and querying data. Here's my suggestions:

Express the format in XML. This has nothing to do with XML files("text"),
unless one wants to. It means the format is conceptually, on an "abstract"
level, described in XML which in turn opens up the door for all methods XML
has.

For example, one could use an XPointer fragment with an XPath scheme:

file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album
= 'Safari'))

If "music collections" cannot be located as files, invent a scheme which can
identify them on this "abstract level."


That is actually a very good idea (to use an XPath), but then again i would be abusing
the file:/// scheme. What should it point to? Even if it would point to the physical location
of the database file, in my specific case this would be ~/.local/share/bmpx/library.mlib,
so file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz
and @album='Safari')), then i would be basically still "making something up", as you cannot
pass THIS uri to, say, a filemanager, and it would recognize it and do the correct thing.

Now of course it won't recognize query:/// either, but i made 2 proposals which would spec
query:/// in this way system wide.

What i'm up to is that while your proposal with file seems
more sane (and XPath/XPointer is certainly better than using a GET string, i might really
consider changing the query:/// URI to use that), it actually is no different. Those kinds of
file:/// URIs would need special treatment as well, and in fact, would cause even more headache
possibly, as file:/// _IS_ already a known scheme which is already specced etc, etd.
 

However, I would first assess RDF as suggested in this thread, since it is
designed exactly for things like this.

Well RDF possibly, but i think i will never in  my life use SPARQL. I took a look at it
and i want these things if not neccessarily, then at least possibly, human editable,
buit SPARQL is just way beyond the comprehension of taking a quick glance at the
file and making some corrections.
 

Cheers,

                Frans


-- Milosz
------=_Part_7583_10781705.1150992092417-- From internalerror@gmail.com Thu Jun 22 12:13:45 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5FD223B0389 for ; Thu, 22 Jun 2006 12:13:45 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08581-05 for ; Thu, 22 Jun 2006 12:13:43 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.205]) by menubar.gnome.org (Postfix) with ESMTP id B81413B01D2 for ; Thu, 22 Jun 2006 12:13:42 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so375754wxc for ; Thu, 22 Jun 2006 09:13:42 -0700 (PDT) Received: by 10.70.18.10 with SMTP id 10mr3379733wxr; Thu, 22 Jun 2006 09:13:42 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 09:13:41 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 18:13:41 +0200 From: "Milosz Derezynski" To: "Frans Englich" Subject: Re: MLQ (Media Library Query) file format and mime type proposal In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7734_19670285.1150992821952" References: <200606221419.00204.frans.englich@telia.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.079 tagged_above=-999 required=2 tests=[AWL=0.146, BAYES_00=-2.599, HTML_30_40=0.374, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.079 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 16:13:45 -0000 ------=_Part_7734_19670285.1150992821952 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I didn't know about tag URIs though, i'm taking a look at it now, thanks. On 6/22/06, Milosz Derezynski wrote: > > > > On 6/22/06, Frans Englich wrote: > > > > On Thursday 22 June 2006 09:25, Milosz Derezynski wrote: > > > Hi, > > > > > > I'm one of the main authors of BMP 2 (still being worked on), and > > along the > > > way of reworking our library, i came across the idea of encoding > > library > > > queries as URIs, which may look like this: > > > > > > "query:///?artist=Air&album=Moon%20Safari" > > > > (Is that at all a valid URI? I'm not sure.) > > > I think it is valid yes. > > First of all, one can't simply invent ones own URI scheme, because it > > causes > > trouble. Especially, for such a generic name as "query". This document > > discusses this further: > > > > http://developer.kde.org/policies/uri-guidelines.xhtml > > > > How is interoperability for "query" ensured? Is it specified? > > > Not at all yet but because of that i'm asking on those 2 lists here now > (xdg > and gnome-multimedia), and furthermore i made some interoperability > proposals, just 2 totally off my head but not totally out of place either. > > > > BMP 2 has a plugin archicture which is a small VFS on it's own, and we > > > treat certain things as "containers" (i.e. they "contain" URIs, like > > PLS > > > playlists, XSPF, M3U, etc). > > > Now i thought it might be not a bad idea to create a playlist format > > with > > > these query URLs, and i've called it "MLQ" for media library query. In > > > theory, it's not even > > > application specific. The keys (identifiers), like artist, album, etc, > > are > > > all based on GStreamer tag identifiers. (They could be maybe adapted > > to > > > http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , > > but > > > it seems insufficient and doesn't specify certain items, like > > musicbrainz > > > metadata, which GST does). > > > > > > So i've called this file format "MLQ", with the extension .mlq, > > created a > > > mime package file for it: > > > > I think this highlights possible trouble. Anyone else who decides to > > invent "query" will get detected as "Media Library Query List". All > > that's > > needed to fix this is to use URIs properly. > > > Yeah well that is problematic for them haha :P > > > > However, I wouldn't invent a new URI scheme for this, it's too context > > dependent. Music players & hardware(ipods, music players, music sharing > > sites, and so on) is quite popular in western societies right now, but > > next > > year it's something different. Technologies, such as a URI scheme, > > shouldn't > > be hard coded on a specific use, it should be generic. > > > > Re-use existing technologies. There's plenty of work and research on > > meta data > > and querying data. Here's my suggestions: > > > > Express the format in XML. This has nothing to do with XML > > files("text"), > > unless one wants to. It means the format is conceptually, on an > > "abstract" > > level, described in XML which in turn opens up the door for all methods > > XML > > has. > > > > For example, one could use an XPointer fragment with an XPath scheme: > > > > file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album > > = 'Safari')) > > > > If "music collections" cannot be located as files, invent a scheme which > > can > > identify them on this "abstract level." > > > > That is actually a very good idea (to use an XPath), but then again i > would be abusing > the file:/// scheme. What should it point to? Even if it would point to > the physical location > of the database file, in my specific case this would be > ~/.local/share/bmpx/library.mlib, > so file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz > > and @album='Safari')), then i would be basically still "making something > up", as you cannot > pass THIS uri to, say, a filemanager, and it would recognize it and do the > correct thing. > > Now of course it won't recognize query:/// either, but i made 2 proposals > which would spec > query:/// in this way system wide. > > What i'm up to is that while your proposal with file seems > more sane (and XPath/XPointer is certainly better than using a GET string, > i might really > consider changing the query:/// URI to use that), it actually is no > different. Those kinds of > file:/// URIs would need special treatment as well, and in fact, would > cause even more headache > possibly, as file:/// _IS_ already a known scheme which is already specced > etc, etd. > > > However, I would first assess RDF as suggested in this thread, since it is > > designed exactly for things like this. > > > Well RDF possibly, but i think i will never in my life use SPARQL. I took > a look at it > and i want these things if not neccessarily, then at least possibly, human > editable, > buit SPARQL is just way beyond the comprehension of taking a quick glance > at the > file and making some corrections. > > > > > > Cheers, > > > > Frans > > > > > -- Milosz > ------=_Part_7734_19670285.1150992821952 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I didn't know about tag URIs though, i'm taking a look at it now, thanks.

On 6/22/06, Milosz Derezynski <internalerror@gmail.com > wrote:


On 6/22/06, Frans Englich <frans.englich@telia.com> wrote:
On Thursday 22 June 2006 09:25, Milosz Derezynski wrote:
> Hi,
>
> I'm one of the main authors of BMP 2 (still being worked on), and along the
> way of reworking our library, i came across the idea of encoding library
> queries as URIs, which may look like this:
>
> "query:///?artist=Air&album=Moon%20Safari"

(Is that at all a valid URI? I'm not sure.)

I think it is valid yes.

First of all, one can't simply invent ones own URI scheme, because it causes
trouble. Especially, for such a generic name as "query". This document
discusses this further:

http://developer.kde.org/policies/uri-guidelines.xhtml

How is interoperability for "query" ensured? Is it specified?

Not at all yet but  because of that i'm asking on those 2 lists here now (xdg
and gnome-multimedia), and furthermore i made some interoperability
proposals, just 2 totally off my head but not totally out of place either.
 

> BMP 2 has a plugin archicture which is a small VFS on it's own, and we
> treat certain things as "containers" (i.e. they "contain" URIs, like PLS
> playlists, XSPF, M3U, etc).
> Now i thought it might be not a bad idea to create a playlist format with
> these query URLs, and i've called it "MLQ" for media library query. In
> theory, it's not even
> application specific. The keys (identifiers), like artist, album, etc, are
> all based on GStreamer tag identifiers. (They could be maybe adapted to
> http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but
> it seems insufficient and doesn't specify certain items, like musicbrainz
> metadata, which GST does).
>
> So i've called this file format "MLQ", with the extension .mlq, created a
> mime package file for it:

I think this highlights possible trouble. Anyone else who decides to
invent "query" will get detected as "Media Library Query List". All that's
needed to fix this is to use URIs properly.

Yeah well that is problematic for them haha :P
 
However, I wouldn't invent a new URI scheme for this, it's too context
dependent. Music players & hardware(ipods, music players, music sharing
sites, and so on) is quite popular in western societies right now, but next
year it's something different. Technologies, such as a URI scheme, shouldn't
be hard coded on a specific use, it should be generic.

Re-use existing technologies. There's plenty of work and research on meta data
and querying data. Here's my suggestions:

Express the format in XML. This has nothing to do with XML files("text"),
unless one wants to. It means the format is conceptually, on an "abstract"
level, described in XML which in turn opens up the door for all methods XML
has.

For example, one could use an XPointer fragment with an XPath scheme:

file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album
= 'Safari'))

If "music collections" cannot be located as files, invent a scheme which can
identify them on this "abstract level."


That is actually a very good idea (to use an XPath), but then again i would be abusing
the file:/// scheme. What should it point to? Even if it would point to the physical location
of the database file, in my specific case this would be ~/.local/share/bmpx/library.mlib,
so file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz
and @album='Safari')), then i would be basically still "making something up", as you cannot
pass THIS uri to, say, a filemanager, and it would recognize it and do the correct thing.

Now of course it won't recognize query:/// either, but i made 2 proposals which would spec
query:/// in this way system wide.

What i'm up to is that while your proposal with file seems
more sane (and XPath/XPointer is certainly better than using a GET string, i might really
consider changing the query:/// URI to use that), it actually is no different. Those kinds of
file:/// URIs would need special treatment as well, and in fact, would cause even more headache
possibly, as file:/// _IS_ already a known scheme which is already specced etc, etd.
 

However, I would first assess RDF as suggested in this thread, since it is
designed exactly for things like this.

Well RDF possibly, but i think i will never in  my life use SPARQL. I took a look at it
and i want these things if not neccessarily, then at least possibly, human editable,
buit SPARQL is just way beyond the comprehension of taking a quick glance at the
file and making some corrections.
 

Cheers,

                Frans


-- Milosz

------=_Part_7734_19670285.1150992821952-- From frans.englich@telia.com Thu Jun 22 10:05:56 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 164263B085B for ; Thu, 22 Jun 2006 10:05:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00797-01 for ; Thu, 22 Jun 2006 10:05:48 -0400 (EDT) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by menubar.gnome.org (Postfix) with ESMTP id 4FFD63B081B for ; Thu, 22 Jun 2006 10:05:38 -0400 (EDT) X-T2-Posting-ID: 2yF4ydxc0UI9xI7FHZPfog== X-Cloudmark-Score: 0.000000 [] Received: from 83.72.134.122.ip.tele2adsl.dk ([83.72.134.122] verified) by mailfe08.swip.net (CommuniGate Pro SMTP 5.0.8) with ESMTP id 217821068; Thu, 22 Jun 2006 16:05:36 +0200 From: Frans Englich To: xdg@lists.freedesktop.org Subject: Re: MLQ (Media Library Query) file format and mime type proposal Date: Thu, 22 Jun 2006 14:18:59 +0000 User-Agent: KMail/1.8.50 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606221419.00204.frans.englich@telia.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.051 tagged_above=-999 required=2 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_NUMERIC_HELO=1.5] X-Spam-Score: -1.051 X-Spam-Level: X-Mailman-Approved-At: Thu, 22 Jun 2006 12:45:56 -0400 Cc: gnome-multimedia@gnome.org, Milosz Derezynski X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 14:05:56 -0000 On Thursday 22 June 2006 09:25, Milosz Derezynski wrote: > Hi, > > I'm one of the main authors of BMP 2 (still being worked on), and along the > way of reworking our library, i came across the idea of encoding library > queries as URIs, which may look like this: > > "query:///?artist=Air&album=Moon%20Safari" (Is that at all a valid URI? I'm not sure.) First of all, one can't simply invent ones own URI scheme, because it causes trouble. Especially, for such a generic name as "query". This document discusses this further: http://developer.kde.org/policies/uri-guidelines.xhtml How is interoperability for "query" ensured? Is it specified? > BMP 2 has a plugin archicture which is a small VFS on it's own, and we > treat certain things as "containers" (i.e. they "contain" URIs, like PLS > playlists, XSPF, M3U, etc). > Now i thought it might be not a bad idea to create a playlist format with > these query URLs, and i've called it "MLQ" for media library query. In > theory, it's not even > application specific. The keys (identifiers), like artist, album, etc, are > all based on GStreamer tag identifiers. (They could be maybe adapted to > http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but > it seems insufficient and doesn't specify certain items, like musicbrainz > metadata, which GST does). > > So i've called this file format "MLQ", with the extension .mlq, created a > mime package file for it: I think this highlights possible trouble. Anyone else who decides to invent "query" will get detected as "Media Library Query List". All that's needed to fix this is to use URIs properly. However, I wouldn't invent a new URI scheme for this, it's too context dependent. Music players & hardware(ipods, music players, music sharing sites, and so on) is quite popular in western societies right now, but next year it's something different. Technologies, such as a URI scheme, shouldn't be hard coded on a specific use, it should be generic. Re-use existing technologies. There's plenty of work and research on meta data and querying data. Here's my suggestions: Express the format in XML. This has nothing to do with XML files("text"), unless one wants to. It means the format is conceptually, on an "abstract" level, described in XML which in turn opens up the door for all methods XML has. For example, one could use an XPointer fragment with an XPath scheme: file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album = 'Safari')) If "music collections" cannot be located as files, invent a scheme which can identify them on this "abstract level." However, I would first assess RDF as suggested in this thread, since it is designed exactly for things like this. In this way one doesn't have to invent a whole query language for music files. That's like inventing C++ for writing games, C++ for fixing bugs in word processors, C++ for writing editors, and so on. Cheers, Frans From internalerror@gmail.com Thu Jun 22 13:17:35 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 614C33B0693 for ; Thu, 22 Jun 2006 13:17:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12677-02 for ; Thu, 22 Jun 2006 13:17:34 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.201]) by menubar.gnome.org (Postfix) with ESMTP id 0CBD83B06C8 for ; Thu, 22 Jun 2006 13:17:33 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so385228wxc for ; Thu, 22 Jun 2006 10:17:33 -0700 (PDT) Received: by 10.70.110.18 with SMTP id i18mr3484207wxc; Thu, 22 Jun 2006 10:17:33 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 10:17:33 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 19:17:33 +0200 From: "Milosz Derezynski" To: "Frans Englich" Subject: Re: MLQ (Media Library Query) file format and mime type proposal In-Reply-To: <200606221419.00204.frans.englich@telia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8538_10618378.1150996653355" References: <200606221419.00204.frans.englich@telia.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.272 tagged_above=-999 required=2 tests=[AWL=0.327, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.272 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 17:17:35 -0000 ------=_Part_8538_10618378.1150996653355 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/22/06, Frans Englich wrote: > > On Thursday 22 June 2006 09:25, Milosz Derezynski wrote: > > I think this highlights possible trouble. Anyone else who decides to > invent "query" will get detected as "Media Library Query List". All that's > needed to fix this is to use URIs properly. > I've changed the file magic so that the first line has to be "#MLQ", and our MLQ exporter writes them like that and recognizes them only like that, and i've updated the mime XML spec to recognize them this way. This is no better or worse than "#EXTM3U" for .m3u playlists, so i don't think there is any problem here now. As for the URIs themselves, i wasn't yet speaking of "open" use of them (outside of .mlq files), but only within them, so this change of the file magic should prevent problems with anything else that might use a query:/// URI in their file formats. -- Milosz ------=_Part_8538_10618378.1150996653355 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 6/22/06, Frans Englich <frans.englich@telia.com> wrote:
On Thursday 22 June 2006 09:25, Milosz Derezynski wrote:

I think this highlights possible trouble. Anyone else who decides to
invent "query" will get detected as "Media Library Query List". All that's
needed to fix this is to use URIs properly.

I've changed the file magic so that the first line has to be "#MLQ", and our
MLQ exporter writes them like that and recognizes them only like that, and i've
updated the mime XML spec to recognize them this way.  This is no better or worse than
"#EXTM3U" for .m3u playlists, so i don't think there is any problem here now.
As for the URIs themselves, i wasn't yet speaking of "open" use of them (outside of .mlq files),
but only within them, so this change of the file magic should prevent problems with
anything else that might use a query:/// URI in their file formats.

-- Milosz
------=_Part_8538_10618378.1150996653355-- From doclivingston@gmail.com Wed Jun 7 10:49:16 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6DFBE3B0CC1 for ; Wed, 7 Jun 2006 10:49:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21939-01 for ; Wed, 7 Jun 2006 10:49:15 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.229]) by menubar.gnome.org (Postfix) with ESMTP id D14723B03C1 for ; Wed, 7 Jun 2006 10:49:14 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id 50so195010wri for ; Wed, 07 Jun 2006 07:49:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:reply-to:to:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=D3/oYUbzoxrxaC8A9PmKhslTLvhndfLfj1yY1UbjWdxPLOVTGGtYcu0ciGotAkdC9rpqkdcPnVZMxJ6dpbOroKn3+pabYkPihqGfxJAljTjii14F9PbbIilMLHmiNyw9SX693UyHiryeZOKfQoct7i10NaO3a8zimwOM5qcjmis= Received: by 10.65.232.13 with SMTP id j13mr502626qbr; Wed, 07 Jun 2006 07:49:14 -0700 (PDT) Received: from alyrion.local ( [144.139.19.99]) by mx.gmail.com with ESMTP id e14sm242982qba.2006.06.07.07.49.12; Wed, 07 Jun 2006 07:49:14 -0700 (PDT) From: "James \"Doc\" Livingston" To: gnome-multimedia@gnome.org Content-Type: text/plain Date: Thu, 08 Jun 2006 00:49:05 +1000 Message-Id: <1149691745.5417.19.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.309 tagged_above=-999 required=2 tests=[AWL=0.291, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.309 X-Spam-Level: Subject: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: doclivingston@gmail.com List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 14:49:16 -0000 G'day everyone, Currently various multi-media application behave differently when the "scrolling" (up/down arrow, page up/down mouse wheel) actions are performed on their seek slider. There have been bugs (at least 164351 and 330570) filed against several applications asking that they behave like others, and it would be good to have consistent behaviour. Essentially the questions is what should happen when the user performs these actions? Should the "up" actions seek forward in time, seek back in time, or do nothing? Currently Totem and Gnome Sound Recorder map "up" to seek forwards in time, Sound-Juicer and Rhythmbox map "up" to seek back in time, and Banshee and Muine don't seek when the user does this. Which is correct is a matter of debate, and when I started a discussion about this on #gnome-hackers (which obviously isn't filled with "average users") a while back, people seemed to be split roughly equally between the options. Some of the point for up=forwards are: * people associate up with increasing the time from the start Some of the point for up=backwards are: * people associate up with increasing the time remaining (only applicable if it's shown to the user) * people associate up with "going towards the start", like for documents/web pages Some of the point for taking no action: * these are "vertical" scroll events and the slider is horizontal, so should do nothing Regardless of which is generally considered "best", I think having it consistent between application is important. Cheers, James "Doc" Livingston -- [Request for the names of the kings who became Nazgul] Dashur, Daensir, Prantsur, Vicksinn, Comuet, Cupuid, Dondor, Blitsun, and Rodulf, Witch-King of Angmar. -- Joseph Michael Bay From hadess@hadess.net Wed Jun 7 10:58:17 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 067753B0272 for ; Wed, 7 Jun 2006 10:58:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22613-04 for ; Wed, 7 Jun 2006 10:58:16 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id EA5A23B03C4 for ; Wed, 7 Jun 2006 10:58:15 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57EwBfm003839; Wed, 7 Jun 2006 10:58:11 -0400 Received: from pobox.surrey.redhat.com (pobox.surrey.redhat.com [172.16.10.17]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57EwASg001552; Wed, 7 Jun 2006 10:58:10 -0400 Received: from bnocera.surrey.redhat.com (bnocera.surrey.redhat.com [172.16.10.53]) by pobox.surrey.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57Ew9om000601; Wed, 7 Jun 2006 15:58:09 +0100 From: Bastien Nocera To: doclivingston@gmail.com In-Reply-To: <1149691745.5417.19.camel@localhost.localdomain> References: <1149691745.5417.19.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8 Date: Wed, 07 Jun 2006 15:58:09 +0100 Message-Id: <1149692289.14668.24.camel@bnocera.surrey.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-27) Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.954 tagged_above=-999 required=2 tests=[AWL=-0.496, BAYES_00=-2.599, SPF_FAIL=1.142, SPF_HELO_PASS=-0.001] X-Spam-Score: -1.954 X-Spam-Level: Cc: gnome-multimedia@gnome.org Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 14:58:17 -0000 On Thu, 2006-06-08 at 00:49 +1000, James "Doc" Livingston wrote: > G'day everyone, > Essentially the questions is what should happen when the user performs > these actions? Should the "up" actions seek forward in time, seek back > in time, or do nothing? Same problem for the volume sliders by default. Obviously, I think that apps should seek forward in time with up, and backwards with down. And I also think that when scrolling down, the step should be shorter than when moving forward (because it makes it easier to find precise points in the timeline). Maybe we need to move things like the volume widget, and some "seek sliders" to a library like gnome-media? -- Bastien Nocera If I'm not challenged, I can do nothing. Maybe my next film will be in Japanese. -- Alejandro González Iñárittu From abockover@novell.com Wed Jun 7 11:08:04 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C6EB33B022D for ; Wed, 7 Jun 2006 11:08:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23164-09 for ; Wed, 7 Jun 2006 11:08:04 -0400 (EDT) Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.25.9.101]) by menubar.gnome.org (Postfix) with ESMTP id B3F5E3B0127 for ; Wed, 7 Jun 2006 11:08:03 -0400 (EDT) Received: from [192.168.0.101] (cpe-024-162-230-116.nc.res.rr.com [24.162.230.116]) by ms-smtp-02.southeast.rr.com (8.13.6/8.13.6) with ESMTP id k57F7xLC012187; Wed, 7 Jun 2006 11:07:59 -0400 (EDT) From: Aaron Bockover To: doclivingston@gmail.com In-Reply-To: <1149691745.5417.19.camel@localhost.localdomain> References: <1149691745.5417.19.camel@localhost.localdomain> Content-Type: text/plain Date: Wed, 07 Jun 2006 11:04:47 -0400 Message-Id: <1149692687.14205.10.camel@sledipus.rex> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.472 tagged_above=-999 required=2 tests=[AWL=-0.073, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2] X-Spam-Score: -2.472 X-Spam-Level: Cc: gnome-multimedia@gnome.org Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 15:08:05 -0000 On Thu, 2006-06-08 at 00:49 +1000, James "Doc" Livingston wrote: > Currently various multi-media application behave differently when the > "scrolling" (up/down arrow, page up/down mouse wheel) actions are > performed on their seek slider. There have been bugs (at least 164351 > and 330570) filed against several applications asking that they behave > like others, and it would be good to have consistent behaviour. Agreed. > Currently Totem and Gnome Sound Recorder map "up" to seek forwards in > time, Sound-Juicer and Rhythmbox map "up" to seek back in time, and > Banshee and Muine don't seek when the user does this. Banshee (and Muine?) seeks on CTRL+Left/Right. > Some of the point for up=forwards are: > * people associate up with increasing the time from the start > Time is usually displayed on the X axis... sliders for seeking are usually horizontal... so Up/Down keys for this mess with my mind > Some of the point for up=backwards are: > * people associate up with increasing the time remaining (only > applicable if it's shown to the user) > * people associate up with "going towards the start", like for > documents/web pages Again, for me it's more literal connection with visual objects... if I press the right arrow, I am scrolling my time graph "into the future." Volume is my Y axis. > Some of the point for taking no action: > * these are "vertical" scroll events and the slider is horizontal, so > should do nothing I don't think this is should be a no-action case. I think representations just should be "on-axis" (of course feelings are going to differ, this are just how I interpret position) >From a more technical (and possibly usability) standpoint, my objection to up/down is that it's used by and is more important to other widgets (our track views in Banshee/RB), meaning the slider needs focus for the keys to actually seek. In Banshee you can press CTRL+Left/Right anywhere and it seeks. Cheers, Aaron From rbultje@ronald.bitfreak.net Wed Jun 7 11:46:19 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3D92F3B04A2 for ; Wed, 7 Jun 2006 11:46:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26037-06 for ; Wed, 7 Jun 2006 11:46:15 -0400 (EDT) Received: from ms-smtp-01.rdc-nyc.rr.com (ms-smtp-01.rdc-nyc.rr.com [24.29.109.5]) by menubar.gnome.org (Postfix) with ESMTP id 8B1693B022D for ; Wed, 7 Jun 2006 11:46:15 -0400 (EDT) Received: from [192.168.0.103] (cpe-66-65-0-167.nyc.res.rr.com [66.65.0.167]) by ms-smtp-01.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id k57Fk2jY021579; Wed, 7 Jun 2006 11:46:13 -0400 (EDT) From: "Ronald S. Bultje" To: Bastien Nocera In-Reply-To: <1149692289.14668.24.camel@bnocera.surrey.redhat.com> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> Content-Type: text/plain Date: Wed, 07 Jun 2006 11:44:22 -0400 Message-Id: <1149695062.2855.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.561 tagged_above=-999 required=2 tests=[AWL=0.038, BAYES_00=-2.599] X-Spam-Score: -2.561 X-Spam-Level: Cc: gnome-multimedia@gnome.org Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 15:46:19 -0000 On Wed, 2006-06-07 at 15:58 +0100, Bastien Nocera wrote: > Maybe we need to move things like the volume widget, and some "seek > sliders" to a library like gnome-media? I would personally prefer libegg (or bacon, where the volume widget resides). I've never really seen gnome-media as a widget-library, but more like a bunch of applications and utilities. I totally don't mind each app making their own copy if such widgets, as long as they update their copy reasonably often. Cheers, Ronald From abockover@novell.com Wed Jun 7 11:58:56 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D43973B0411 for ; Wed, 7 Jun 2006 11:58:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26954-08 for ; Wed, 7 Jun 2006 11:58:56 -0400 (EDT) Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.25.9.101]) by menubar.gnome.org (Postfix) with ESMTP id 120B23B0D4B for ; Wed, 7 Jun 2006 11:58:56 -0400 (EDT) Received: from [192.168.0.101] (cpe-024-162-230-116.nc.res.rr.com [24.162.230.116]) by ms-smtp-02.southeast.rr.com (8.13.6/8.13.6) with ESMTP id k57FwrFL000910; Wed, 7 Jun 2006 11:58:54 -0400 (EDT) From: Aaron Bockover To: "Ronald S. Bultje" In-Reply-To: <1149695062.2855.2.camel@localhost.localdomain> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> <1149695062.2855.2.camel@localhost.localdomain> Content-Type: text/plain Date: Wed, 07 Jun 2006 11:55:41 -0400 Message-Id: <1149695742.15592.1.camel@sledipus.rex> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.473 tagged_above=-999 required=2 tests=[AWL=-0.074, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2] X-Spam-Score: -2.473 X-Spam-Level: Cc: gnome-multimedia@gnome.org, Bastien Nocera Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 15:58:57 -0000 On Wed, 2006-06-07 at 11:44 -0400, Ronald S. Bultje wrote: > On Wed, 2006-06-07 at 15:58 +0100, Bastien Nocera wrote: > > Maybe we need to move things like the volume widget, and some "seek > > sliders" to a library like gnome-media? > > I would personally prefer libegg (or bacon, where the volume widget > resides). I've never really seen gnome-media as a widget-library, but > more like a bunch of applications and utilities. > > I totally don't mind each app making their own copy if such widgets, as > long as they update their copy reasonably often. I agree here; bacon would probably be best if it were to be in a library, but I think applications providing copies is fine too. I wouldn't want to depend on bacon (or gnome-media) for a widget. --Aaron From hadess@hadess.net Wed Jun 7 12:02:02 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 001A03B0DF9 for ; Wed, 7 Jun 2006 12:02:02 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27399-05 for ; Wed, 7 Jun 2006 12:01:59 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 9822B3B0E10 for ; Wed, 7 Jun 2006 12:00:49 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57G0nE9001971; Wed, 7 Jun 2006 12:00:49 -0400 Received: from pobox.surrey.redhat.com (pobox.surrey.redhat.com [172.16.10.17]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57G0mZE021228; Wed, 7 Jun 2006 12:00:48 -0400 Received: from bnocera.surrey.redhat.com (bnocera.surrey.redhat.com [172.16.10.53]) by pobox.surrey.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57G0lTo006172; Wed, 7 Jun 2006 17:00:47 +0100 From: Bastien Nocera To: Aaron Bockover In-Reply-To: <1149695742.15592.1.camel@sledipus.rex> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> <1149695062.2855.2.camel@localhost.localdomain> <1149695742.15592.1.camel@sledipus.rex> Content-Type: text/plain Date: Wed, 07 Jun 2006 17:00:47 +0100 Message-Id: <1149696047.14668.35.camel@bnocera.surrey.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-27) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.953 tagged_above=-999 required=2 tests=[AWL=-0.495, BAYES_00=-2.599, SPF_FAIL=1.142, SPF_HELO_PASS=-0.001] X-Spam-Score: -1.953 X-Spam-Level: Cc: "Ronald S. Bultje" , gnome-multimedia@gnome.org Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 16:02:02 -0000 On Wed, 2006-06-07 at 11:55 -0400, Aaron Bockover wrote: > On Wed, 2006-06-07 at 11:44 -0400, Ronald S. Bultje wrote: > > On Wed, 2006-06-07 at 15:58 +0100, Bastien Nocera wrote: > > > Maybe we need to move things like the volume widget, and some "seek > > > sliders" to a library like gnome-media? > > > > I would personally prefer libegg (or bacon, where the volume widget > > resides). I've never really seen gnome-media as a widget-library, but > > more like a bunch of applications and utilities. > > > > I totally don't mind each app making their own copy if such widgets, as > > long as they update their copy reasonably often. > > I agree here; bacon would probably be best if it were to be in a > library, but I think applications providing copies is fine too. I > wouldn't want to depend on bacon (or gnome-media) for a widget. libbacon is a cut'n'paste library like libegg, so not a problem. -- Bastien Nocera Lucas has made a vacuous, boring, pretentious, retroactively destructive sequel. He has lost the plot. The man is a fool. -- Simon Pegg (on the Phantom Menace) From uraeus@linuxrising.org Fri Jun 9 10:13:15 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 91BCF3B01D8 for ; Fri, 9 Jun 2006 10:13:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29942-03 for ; Fri, 9 Jun 2006 10:13:14 -0400 (EDT) Received: from mx1.es6.egwn.net (server02.es6.egwn.net [195.10.6.12]) by menubar.gnome.org (Postfix) with ESMTP id E0C263B01BE for ; Fri, 9 Jun 2006 10:13:13 -0400 (EDT) Received: from [192.168.1.235] (core.fluendo.com [195.10.6.237]) by mx1.es6.egwn.net (Postfix) with ESMTP id 9E4AC4F81BC; Fri, 9 Jun 2006 16:13:11 +0200 (CEST) From: Christian Fredrik Kalager Schaller To: Bastien Nocera In-Reply-To: <1149696047.14668.35.camel@bnocera.surrey.redhat.com> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> <1149695062.2855.2.camel@localhost.localdomain> <1149695742.15592.1.camel@sledipus.rex> <1149696047.14668.35.camel@bnocera.surrey.redhat.com> Content-Type: text/plain Date: Fri, 09 Jun 2006 16:11:58 +0200 Message-Id: <1149862318.2356.36.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.397 tagged_above=-999 required=2 tests=[AWL=1.202, BAYES_00=-2.599] X-Spam-Score: -1.397 X-Spam-Level: Cc: "Ronald S. Bultje" , gnome-multimedia@gnome.org Subject: a general multimedia library - Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 14:13:15 -0000 Well the topic of having a multimedia widget library has been discussed multiple times and maybe now is the time to move on it? Currently there are multiple things I see that would be natural to put into such a library: a) the gconf schemas in gnome-media b) the playlist parser library in totem c) the seek sliders widgets mentioned here d) a simple to use GStreamer GTK+ video widget e) others things? Basically this library would/could contain things which are higher level our not directly in the scope of GStreamer. Or which is very GTK+/GNOME related. Christian On Wed, 2006-06-07 at 17:00 +0100, Bastien Nocera wrote: > On Wed, 2006-06-07 at 11:55 -0400, Aaron Bockover wrote: > > On Wed, 2006-06-07 at 11:44 -0400, Ronald S. Bultje wrote: > > > On Wed, 2006-06-07 at 15:58 +0100, Bastien Nocera wrote: > > > > Maybe we need to move things like the volume widget, and some "seek > > > > sliders" to a library like gnome-media? > > > > > > I would personally prefer libegg (or bacon, where the volume widget > > > resides). I've never really seen gnome-media as a widget-library, but > > > more like a bunch of applications and utilities. > > > > > > I totally don't mind each app making their own copy if such widgets, as > > > long as they update their copy reasonably often. > > > > I agree here; bacon would probably be best if it were to be in a > > library, but I think applications providing copies is fine too. I > > wouldn't want to depend on bacon (or gnome-media) for a widget. > > libbacon is a cut'n'paste library like libegg, so not a problem. > From rbultje@ronald.bitfreak.net Fri Jun 9 10:47:45 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B71663B0413 for ; Fri, 9 Jun 2006 10:47:45 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32342-10 for ; Fri, 9 Jun 2006 10:47:42 -0400 (EDT) Received: from ms-smtp-03.rdc-nyc.rr.com (ms-smtp-03.rdc-nyc.rr.com [24.29.109.7]) by menubar.gnome.org (Postfix) with ESMTP id 215673B0FF1 for ; Fri, 9 Jun 2006 10:47:42 -0400 (EDT) Received: from [192.168.0.103] (cpe-66-65-0-167.nyc.res.rr.com [66.65.0.167]) by ms-smtp-03.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id k59Eld9O019647; Fri, 9 Jun 2006 10:47:40 -0400 (EDT) From: "Ronald S. Bultje" To: Christian Fredrik Kalager Schaller In-Reply-To: <1149862318.2356.36.camel@localhost.localdomain> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> <1149695062.2855.2.camel@localhost.localdomain> <1149695742.15592.1.camel@sledipus.rex> <1149696047.14668.35.camel@bnocera.surrey.redhat.com> <1149862318.2356.36.camel@localhost.localdomain> Content-Type: text/plain Date: Fri, 09 Jun 2006 10:46:01 -0400 Message-Id: <1149864361.2869.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.563 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599] X-Spam-Score: -2.563 X-Spam-Level: Cc: gnome-multimedia@gnome.org, Bastien Nocera Subject: Re: a general multimedia library - Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 14:47:45 -0000 Hi, On Fri, 2006-06-09 at 16:11 +0200, Christian Fredrik Kalager Schaller wrote: > Well the topic of having a multimedia widget library has been discussed > multiple times and maybe now is the time to move on it? If someone believes that this would be useful and should be done, then that person should go ahead and do it. Ronald From thomas@apestaart.org Fri Jun 9 15:11:02 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 78FFA3B00E9 for ; Fri, 9 Jun 2006 15:11:02 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15077-08 for ; Fri, 9 Jun 2006 15:11:01 -0400 (EDT) Received: from mx1.es6.egwn.net (server02.es6.egwn.net [195.10.6.12]) by menubar.gnome.org (Postfix) with ESMTP id E94F03B0149 for ; Fri, 9 Jun 2006 15:11:00 -0400 (EDT) Received: from mx1.fr4.egwn.net (server07.fr4.egwn.net [62.39.85.77]) by mx1.es6.egwn.net (Postfix) with ESMTP id 0FC914F822C; Fri, 9 Jun 2006 21:10:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mx1.fr4.egwn.net (spiffy mail daemon) with ESMTP id CB4CC83BFD; Fri, 9 Jun 2006 21:10:47 +0200 (CEST) Received: from mx1.fr4.egwn.net ([127.0.0.1]) by localhost (server07.fr4.egwn.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22095-43; Fri, 9 Jun 2006 21:10:47 +0200 (CEST) Received: from thread.fluendo.lan (core.fluendo.com [195.10.6.237]) by mx1.fr4.egwn.net (spiffy mail daemon) with ESMTP id D8A3283BF8; Fri, 9 Jun 2006 21:10:46 +0200 (CEST) Received: from otto.amantes (thomas.fluendo.lan [192.168.1.10]) by thread.fluendo.lan (Postfix) with ESMTP id 8DDD1FE93; Fri, 9 Jun 2006 21:10:57 +0200 (CEST) Received: from otto.amantes (otto.amantes [127.0.0.1]) by otto.amantes (Postfix) with ESMTP id 9B95DEFC0D; Fri, 9 Jun 2006 21:11:00 +0200 (CEST) Content-Type: multipart/mixed; boundary="127.0.0.1.500.4863.1149880260.533.2" MIME-Version: 1.0 To: gstreamer-devel@lists.sourceforge.net, gstreamer-announce@lists.sourceforge.net, kde-multimedia@kde.org, gnome-multimedia@gnome.org Message-Id: <20060609191100.9B95DEFC0D@otto.amantes> Date: Fri, 9 Jun 2006 21:11:00 +0200 (CEST) From: thomas@apestaart.org X-Scanned: By amavis at egwn.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: Yes, score=2.06 tagged_above=-999 required=2 tests=[AWL=-1.482, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, MIME_BASE64_TEXT=1.885, NO_REAL_NAME=0.961, RCVD_IN_SBL=3.16] X-Spam-Score: 2.06 X-Spam-Level: ** X-Spam-Flag: YES Cc: Subject: RELEASE: GStreamer 0.10.7 'Soepeke, ik zie ou' X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 19:11:02 -0000 --127.0.0.1.500.4863.1149880260.533.2 Content-Type: text/plain This mail announces the release of GStreamer 0.10.7 'Soepeke, ik zie ou'. GStreamer is a streaming media framework that allows the construction of graphs of elements which operate on media data. Applications using this library can do anything from real-time sound processing over playing video to capturing audio, video, and even other types of media data. Its architecture allows for adding new data types or processing capabilities simply by installing new plug-ins. GStreamer is the core module, containing libraries, headers, the basic object hierarchy, and a set of media-agnostic core elements. For more information, see [http://gstreamer.freedesktop.org/modules/gstreamer.html] To file bugs, go to [http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer&component=gstreamer+%28core%29] --127.0.0.1.500.4863.1149880260.533.2 Content-Type: text/plain; name=RELEASE Content-Transfer-Encoding: base64 ClJlbGVhc2Ugbm90ZXMgZm9yIEdTdHJlYW1lcsKgMC4xMC43ICJTb2VwZWtlLCBpayB6aWUgb3Ui CiAgICAgICAgCgoKVGhlIEdTdHJlYW1lciB0ZWFtIGlzIHByb3VkIHRvIGFubm91bmNlIGEgbmV3 IHJlbGVhc2UKaW4gdGhlIDAuMTAueCBzdGFibGUgc2VyaWVzIG9mIHRoZQpjb3JlIG9mIHRoZSBH U3RyZWFtZXIgc3RyZWFtaW5nIG1lZGlhIGZyYW1ld29yay4KCgpUaGUgMC4xMC54IHNlcmllcyBp cyBhIHN0YWJsZSBzZXJpZXMgdGFyZ2V0ZWQgYXQgZW5kIHVzZXJzLgpJdCBpcyBub3QgQVBJIG9y IEFCSSBjb21wYXRpYmxlIHdpdGggdGhlIHN0YWJsZSAwLjgueCBzZXJpZXMuCkl0IGlzLCBob3dl dmVyLCBwYXJhbGxlbCBpbnN0YWxsYWJsZSB3aXRoIHRoZSAwLjgueCBzZXJpZXMuCgoKVGhlIDAu MTAueCBzZXJpZXMgaGFzIGJlZW4gcmV3b3JrZWQgZm9yIHRocmVhZHNhZmV0eS4gIEl0IGFsc28g ZmVhdHVyZXMKdmFyaW91cyBmZWF0dXJlIGFkZGl0aW9ucyBhbmQgZW5jaGFuY2VtZW50cy4KCgpU aGlzIG1vZHVsZSwgZ3N0cmVhbWVyLCBvbmx5IGNvbnRhaW5zIGNvcmUgZnVuY3Rpb25hbGl0eS4K Rm9yIGFjdHVhbCBtZWRpYSBwbGF5YmFjaywgeW91IHdpbGwgbmVlZCBvdGhlciBtb2R1bGVzLgoK Z3N0LXBsdWdpbnMtYmFzZQpjb250YWlucyBhIGJhc2ljIHNldCBvZiB3ZWxsLXN1cHBvcnRlZCBw bHVnLWlucwpnc3QtcGx1Z2lucy1nb29kCmNvbnRhaW5zIGEgc2V0IG9mIHdlbGwtc3VwcG9ydGVk IHBsdWctaW5zIHVuZGVyIG91ciBwcmVmZXJyZWQgbGljZW5zZQpnc3QtcGx1Z2lucy11Z2x5CmNv bnRhaW5zIGEgc2V0IG9mIHdlbGwtc3VwcG9ydGVkIHBsdWctaW5zLCBidXQgbWlnaHQgcG9zZSBw cm9ibGVtcyBmb3IKICAgIGRpc3RyaWJ1dG9ycwpnc3QtcGx1Z2lucy1iYWQKY29udGFpbnMgYSBz ZXQgb2YgbGVzcyBzdXBwb3J0ZWQgcGx1Zy1pbnMgdGhhdCBoYXZlbid0IHBhc3NlZCB0aGUKICAg IHJpZ29yb3VzIHF1YWxpdHkgdGVzdGluZyB3ZSBleHBlY3QKCgoKICAKRmVhdHVyZXMgb2YgdGhp cyByZWxlYXNlCiAgICAKICAgICAgKiBQYXJhbGxlbCBpbnN0YWxsYWJpbGl0eSB3aXRoIDAuOC54 IHNlcmllcwogICAgICAqIFRocmVhZHNhZmUgZGVzaWduIGFuZCBBUEkKICAgICAgKiBSZWdpc3Ry eSBjYWNoZSB1cGRhdGluZyBpcyBub3cgZG9uZSBpbiBhIGZvcmssIHNvIG5vIHBsdWdpbnMgYXJl IGxlZnQgb3BlbmVkCiAgICAgICogTmV3IHZlcnNpb24gb2YgZGF0YSBwcm90b2NvbCBub3cgc2Vy aWFsaXplcyBldmVudHMKICAgICAgKiBxdWV1ZSBmaXhlcwogICAgICAqIHdpbjMyIGZpeGVzCgpC dWdzIGZpeGVkIGluIHRoaXMgcmVsZWFzZQogICAgCiAgICAgICogMzM4MzM1IDogW3BhdGNoXSBt ZW1sZWFrIGluIGdzdC11dGlscy5jIChsZWFrIHBhZHMgZnJvbSBpdGVyYXRvcikKICAgICAgKiAz NDM1OTggOiB1bmRlZmluZWQgc3ltYm9sIGluIGNvcmVpbmRleGVycyB3aGVuIHVzaW5nIC0tZGlz YWJsZS1sb2EuLi4KICAgICAgKiAzMzY5MjkgOiBHc3RDb2xsZWN0UGFkcyBkb2VzIG5vdCBjbGVh ci9yZXNldCBzZWdtZW50IGluZm8gYWZ0ZXIgZmwuLi4KICAgICAgKiAzMzcxMDAgOiBbZmFrZXNp bmtdIGFkZCAiIHByZXJvbGwtaGFuZG9mZiAiIHNpZ25hbAogICAgICAqIDMzOTkxOCA6IEdzdFRh Z1NldHRlciBtZXJnZS1tb2RlIGRlc2NyaXB0aW9uIHVuY2xlYXIsIGFuZCBpbXBsZW1lbi4uLgog ICAgICAqIDM0MDUwMSA6IFtmaWxlc3JjXSBnaXZlIHByaW1hcnkgcmFuawogICAgICAqIDM0MTY2 MiA6IGdzdC1sYXVuY2ggcHJpbnRfdGFncygpIGZpeAogICAgICAqIDM0MjIzOCA6IEFQSTogZ3N0 X2VsZW1lbnRfc2Vla19zaW1wbGUKICAgICAgKiAzNDIzMjEgOiBHU1RfUVVFUllfUE9TSVRJT04g ZmFpbHMgaWYgR3N0QmFzZVNyYyBpbiBnZXRfcmFuZ2UgbW9kZQogICAgICAqIDM0Mjc3NyA6IHJl YnVpbGRpbmcgdGhlIHJlZ2lzdHJ5IGxlYXZlcyBhbGwgcGx1Z2lucyBpbiBtZW1vcnkKICAgICAg KiAzNDI4MjAgOiBnc3RuZXRjbGllbnRjbG9jay5jKDQ1Myk6IHNlcnZhZGRyIHVzZWQgYmVmb3Jl IHNldAogICAgICAqIDM0MzA1NyA6IGdzdC1sYXVuY2gtMC4xMCBzZWdmYXVsdHMgd2hlbiBwYXNz ZWQgZ3N0LXBsdWdpbi1wYXRoIGFuZC4uLgogICAgICAqIDM0MzM0MSA6IFtBUEldIGFkZCBHU1Rf VEFHX1BSRVZJRVdfSU1BR0UKICAgICAgKiAzNDM4MjcgOiBsZWFrIGluIGdzdF9pbmRleF9ndHlw ZV9yZXNvbHZlcgogICAgICAqIDM0MzkyOSA6IFVzZSBvZiAvLyBpbiBwdWJsaWMgaGVhZGVyCiAg ICAgICogMzQzOTg4IDogZGF0YSBwcm90b2NvbCBuZWVkcyBleHRlbmRpbmcgdG8gaGFuZGxlIGV2 ZW50cyBiZXR0ZXIKICAgICAgKiAzNDE0NzkgOiBUb28gbWFueSBwbHVnaW5zIGxvYWRlZCBldmVu IGZvciB1cC10by1kYXRlIHJlZ2lzdHJ5CiAgICAgICogMzQzMzM0IDogR3N0Q29sbGVjdFBhZHMg dGVzdHN1aXRlIGFuZCBmaXhlcwogICAgICAqIDM0MzUzOCA6IEdzdENvbGxlY3RQYWRzIGRvZXNu J3QgcmVzZXQgRU9TIGZpZWxkcyB3aGVuIHN0b3BwZWQKCkFQSSBjaGFuZ2VkIGluIHRoaXMgcmVs ZWFzZQogICAgIAoKLSBBUEkgYWRkaXRpb25zOgogICAgCiogZ3N0X2VsZW1lbnRfc2Vla19zaW1w bGUoKQoqIEdTVF9GTE9XX0NVU1RPTV9TVUNDRVNTCiogR1NUX0ZMT1dfQ1VTVE9NX0VSUk9SCiog R1NUX0ZMT1dfSVNfU1VDQ0VTUwoqIGdzdF9jb2xsZWN0X3BhZHNfc2V0X2ZsdXNoaW5nKCkKKiBH U1RfVEFHX1BSRVZJRVdfSU1BR0UKKiBnc3RfZHBfY3JjKCkKKiBHc3REUFBhY2tldGl6ZXIKKiBH c3REUFZlcnNpb24KKiBHc3RGYWtlU2luazo6cHJlcm9sbC1oYW5kb2ZmCiogR3N0RmFrZVNpbms6 OnVzZS1tbWFwCgpEb3dubG9hZAoKWW91IGNhbiBmaW5kIHNvdXJjZSByZWxlYXNlcyBvZiBnc3Ry ZWFtZXIgaW4gdGhlIGRvd25sb2FkIGRpcmVjdG9yeToKaHR0cDovL2dzdHJlYW1lci5mcmVlZGVz a3RvcC5vcmcvc3JjL2dzdHJlYW1lci8KCkdTdHJlYW1lciBIb21lcGFnZQoKTW9yZSBkZXRhaWxz IGNhbiBiZSBmb3VuZCBvbiB0aGUgcHJvamVjdCdzIHdlYnNpdGU6Cmh0dHA6Ly9nc3RyZWFtZXIu ZnJlZWRlc2t0b3Aub3JnLwoKU3VwcG9ydCBhbmQgQnVncwoKV2UgdXNlIEdOT01FJ3MgYnVnemls bGEgZm9yIGJ1ZyByZXBvcnRzIGFuZCBmZWF0dXJlIHJlcXVlc3RzOgpodHRwOi8vYnVnemlsbGEu Z25vbWUub3JnL2VudGVyX2J1Zy5jZ2k/cHJvZHVjdD1HU3RyZWFtZXIKCkRldmVsb3BlcnMKCkNW UyBpcyBob3N0ZWQgb24gY3ZzLmZyZWVkZXNrdG9wLm9yZy4KQWxsIGNvZGUgaXMgaW4gQ1ZTIGFu ZCBjYW4gYmUgY2hlY2tlZCBvdXQgZnJvbSB0aGVyZS4KSW50ZXJlc3RlZCBkZXZlbG9wZXJzIG9m IHRoZSBjb3JlIGxpYnJhcnksIHBsdWctaW5zLCBhbmQgYXBwbGljYXRpb25zIHNob3VsZApzdWJz Y3JpYmUgdG8gdGhlIGdzdHJlYW1lci1kZXZlbCBsaXN0LiBJZiB0aGVyZSBpcyBzdWZmaWNpZW50 IGludGVyZXN0IHdlCndpbGwgY3JlYXRlIG1vcmUgbGlzdHMgYXMgbmVjZXNzYXJ5LgoKICAgICAg ICAKQXBwbGljYXRpb25zCgpBcHBsaWNhdGlvbnMgcG9ydGVkIHRvIEdTdHJlYW1lciAwLjEwIGlu Y2x1ZGUgVG90ZW0sIFJoeXRobUJveCwgU291bmQtSnVpY2VyLApHbm9tZSBNZWRpYSwgRmx1bW90 aW9uLCBBbWFyb2ssIEphbWJvcmVlLCBQaXRpdmksIElzdGFuYnVsLCBBbm5vQW1wLCBFbGlzYSwg YW5kIG90aGVycy4KTGV0IHVzIGtub3cgaWYgeW91IHdhbnQgdG8gYmUgYWRkZWQgdG8gdGhpcyBs aXN0LgoKICAKQ29udHJpYnV0b3JzIHRvIHRoaXMgcmVsZWFzZQogICAgCiAgICAgICogQWxlc3Nh bmRybyBEZWNpbmEKICAgICAgKiBFZHdhcmQgSGVydmV5CiAgICAgICogSmFuIFNjaG1pZHQKICAg ICAgKiBKdWxpZW4gTW91dHRlCiAgICAgICogTHV0eiBNdWVsbGVyCiAgICAgICogTWFyayBOYXV3 ZWxhZXJ0cwogICAgICAqIE1pY2hhZWwgU21pdGgKICAgICAgKiBTZWJhc3RpZW4gTW91dHRlCiAg ICAgICogU3RlZmFuIEtvc3QKICAgICAgKiBUaG9tYXMgVmFuZGVyIFN0aWNoZWxlCiAgICAgICog VGltLVBoaWxpcHAgTcO8bGxlcgogICAgICAqIFdpbSBUYXltYW5zCiAgICAgICogWmFoZWVyIEFi YmFzIE1lcmFsaQrCoA== --127.0.0.1.500.4863.1149880260.533.2-- From thomas@apestaart.org Fri Jun 9 15:11:49 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5C75C3B00E9 for ; Fri, 9 Jun 2006 15:11:49 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15136-05 for ; Fri, 9 Jun 2006 15:11:48 -0400 (EDT) Received: from mx1.es6.egwn.net (server02.es6.egwn.net [195.10.6.12]) by menubar.gnome.org (Postfix) with ESMTP id 0A9E03B0149 for ; Fri, 9 Jun 2006 15:11:47 -0400 (EDT) Received: from mx1.fr4.egwn.net (server07.fr4.egwn.net [62.39.85.77]) by mx1.es6.egwn.net (Postfix) with ESMTP id 5C5134F822C; Fri, 9 Jun 2006 21:11:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mx1.fr4.egwn.net (spiffy mail daemon) with ESMTP id 20D9883BFD; Fri, 9 Jun 2006 21:11:35 +0200 (CEST) Received: from mx1.fr4.egwn.net ([127.0.0.1]) by localhost (server07.fr4.egwn.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23574-43; Fri, 9 Jun 2006 21:11:34 +0200 (CEST) Received: from thread.fluendo.lan (core.fluendo.com [195.10.6.237]) by mx1.fr4.egwn.net (spiffy mail daemon) with ESMTP id 33DE383BF8; Fri, 9 Jun 2006 21:11:34 +0200 (CEST) Received: from otto.amantes (thomas.fluendo.lan [192.168.1.10]) by thread.fluendo.lan (Postfix) with ESMTP id 071AFFE93; Fri, 9 Jun 2006 21:11:45 +0200 (CEST) Received: from otto.amantes (otto.amantes [127.0.0.1]) by otto.amantes (Postfix) with ESMTP id 35F55EFC0D; Fri, 9 Jun 2006 21:11:48 +0200 (CEST) Content-Type: multipart/mixed; boundary="127.0.0.1.500.5548.1149880308.216.2" MIME-Version: 1.0 To: gstreamer-devel@lists.sourceforge.net, gstreamer-announce@lists.sourceforge.net, kde-multimedia@kde.org, gnome-multimedia@gnome.org Message-Id: <20060609191148.35F55EFC0D@otto.amantes> Date: Fri, 9 Jun 2006 21:11:48 +0200 (CEST) From: thomas@apestaart.org X-Scanned: By amavis at egwn.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: Yes, score=2.198 tagged_above=-999 required=2 tests=[AWL=-1.575, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, MIME_BASE64_TEXT=1.885, NO_REAL_NAME=0.961, RCVD_IN_SBL=3.16, TW_EG=0.077, TW_EV=0.077, TW_FD=0.077] X-Spam-Score: 2.198 X-Spam-Level: ** X-Spam-Flag: YES Cc: Subject: RELEASE: GStreamer Base Plug-ins 0.10.8 'Moar gij zie mij nie' X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 19:11:49 -0000 --127.0.0.1.500.5548.1149880308.216.2 Content-Type: text/plain This mail announces the release of GStreamer Base Plug-ins 0.10.8 'Moar gij zie mij nie'. GStreamer Base Plug-ins is a well-groomed and well-maintained collection of GStreamer plug-ins and elements, spanning the range of possible types of elements one would want to write for GStreamer. It also contains helper libraries and base classes useful for writing elements. A wide range of video and audio decoders, encoders, and filters are included. For more information, see [http://gstreamer.freedesktop.org/modules/gst-plugins-base.html] To file bugs, go to [http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer&component=gst-plugins-base] --127.0.0.1.500.5548.1149880308.216.2 Content-Type: text/plain; name=RELEASE Content-Transfer-Encoding: base64 ClJlbGVhc2Ugbm90ZXMgZm9yIEdTdHJlYW1lciBCYXNlIFBsdWctaW5zwqAwLjEwLjggIk1vYXIg Z2lqIHppZXQgbWlqIG5pZSIKICAgICAgICAKCgpUaGUgR1N0cmVhbWVyIHRlYW0gaXMgcHJvdWQg dG8gYW5ub3VuY2UgYSBuZXcgcmVsZWFzZQppbiB0aGUgMC4xMC54IHN0YWJsZSBzZXJpZXMgb2Yg dGhlCkdTdHJlYW1lciBCYXNlIFBsdWctaW5zLgoKClRoZSAwLjEwLnggc2VyaWVzIGlzIGEgc3Rh YmxlIHNlcmllcyB0YXJnZXRlZCBhdCBlbmQgdXNlcnMuCkl0IGlzIG5vdCBBUEkgb3IgQUJJIGNv bXBhdGlibGUgd2l0aCB0aGUgc3RhYmxlIDAuOC54IHNlcmllcy4KSXQgaXMsIGhvd2V2ZXIsIHBh cmFsbGVsIGluc3RhbGxhYmxlIHdpdGggdGhlIDAuOC54IHNlcmllcy4KCgoKVGhpcyBtb2R1bGUg Y29udGFpbnMgYSBzZXQgb2YgcmVmZXJlbmNlIHBsdWdpbnMsIGJhc2UgY2xhc3NlcyBmb3Igb3Ro ZXIKcGx1Z2lucywgYW5kIGhlbHBlciBsaWJyYXJpZXMuCgpUaGlzIG1vZHVsZSBpcyBrZXB0IHVw LXRvLWRhdGUgdG9nZXRoZXIgd2l0aCB0aGUgY29yZSBkZXZlbG9wbWVudHMuICBFbGVtZW50Cndy aXRlcnMgc2hvdWxkIGxvb2sgYXQgdGhlIGVsZW1lbnRzIGluIHRoaXMgbW9kdWxlIGFzIGEgcmVm ZXJlbmNlIGZvcgp0aGVpciBkZXZlbG9wbWVudC4KClRoaXMgbW9kdWxlIGNvbnRhaW5zIGVsZW1l bnRzIGZvciwgYW1vbmcgb3RoZXJzOgoKICBkZXZpY2UgcGx1Z2luczogeCh2KWltYWdlc2luaywg YWxzYSwgdjRsc3JjLCBjZHBhcmFub2lhCiAgY29udGFpbmVyczogb2dnCiAgY29kZWNzOiB2b3Ji aXMsIHRoZW9yYQogIHRleHQ6IHRleHRvdmVybGF5LCBzdWJwYXJzZQogIHNvdXJjZXM6IGF1ZGlv dGVzdHNyYywgdmlkZW90ZXN0c3JjLCBnbm9tZXZmc3NyYwogIG5ldHdvcms6IHRjcAogIHR5cGVm aW5kCiAgYXVkaW8gcHJvY2Vzc2luZzogYXVkaW9jb252ZXJ0LCBhZGRlciwgYXVkaW9yYXRlLCBh dWRpb3NjYWxlLCB2b2x1bWUKICB2aXN1YWxpc2F0aW9uOiBsaWJ2aXN1YWwKICB2aWRlbyBwcm9j ZXNzaW5nOiBmZm1wZWdjb2xvcnNwYWNlCiAgYWdncmVnYXRlIGVsZW1lbnRzOiBkZWNvZGViaW4s IHBsYXliaW4KCgpPdGhlciBtb2R1bGVzIGNvbnRhaW5pbmcgcGx1Zy1pbnMgYXJlOgoKCmdzdC1w bHVnaW5zLWdvb2QKY29udGFpbnMgYSBzZXQgb2Ygd2VsbC1zdXBwb3J0ZWQgcGx1Zy1pbnMgdW5k ZXIgb3VyIHByZWZlcnJlZCBsaWNlbnNlCmdzdC1wbHVnaW5zLXVnbHkKY29udGFpbnMgYSBzZXQg b2Ygd2VsbC1zdXBwb3J0ZWQgcGx1Zy1pbnMsIGJ1dCBtaWdodCBwb3NlIHByb2JsZW1zIGZvcgog ICAgZGlzdHJpYnV0b3JzCmdzdC1wbHVnaW5zLWJhZApjb250YWlucyBhIHNldCBvZiBsZXNzIHN1 cHBvcnRlZCBwbHVnLWlucyB0aGF0IGhhdmVuJ3QgcGFzc2VkIHRoZQogICAgcmlnb3JvdXMgcXVh bGl0eSB0ZXN0aW5nIHdlIGV4cGVjdAoKCgogIApGZWF0dXJlcyBvZiB0aGlzIHJlbGVhc2UKICAg IAogICAgICAqIFBhcmFsbGVsIGluc3RhbGxhYmlsaXR5IHdpdGggMC44Lnggc2VyaWVzCiAgICAg ICogVGhyZWFkc2FmZSBkZXNpZ24gYW5kIEFQSQogICAgICAqIGFsc2FzaW5rIHByb2JpbmcgZml4 ZXMKICAgICAgKiB4dmltYWdlc2luayBlcnJvciByZXBvcnRpbmcgZml4ZXMKICAgICAgKiBzdWJ0 aXRsZSBmaXhlcwogICAgICAqIGFkZGVyIGZpeGVzCiAgICAgICogdm9yYmlzIG11bHRpY2hhbm5l bCBmaXhlcwogICAgICAqIG11bHRpZmRzaW5rIHN0cmVhbWhlYWRlciBmaXhlcwoKQnVncyBmaXhl ZCBpbiB0aGlzIHJlbGVhc2UKICAgIAogICAgICAqIDE2OTkzNiA6IFtzdWJwYXJzZV0gc3VwcG9y dCBmb3IgU0FNSSBzdWJ0aXRsZXMKICAgICAgKiAzMTUzMTIgOiBHc3RyZWFtZXIgWHYgdXNlcyBS R0IgaW5zdGVhZCBvZiBZVVYuCiAgICAgICogMzM0MDAyIDogdmlkZW80bGludXggc2hvdWxkbid0 IGRlcGVuZCBvbiBYIGluIGNvbmZpZ3VyZSBzY3JpcHQKICAgICAgKiAzMzY4ODEgOiBbbGlidmlz dWFsXSBhZGRpdGlvbmFsIHN1cHBvcnQgZm9yIGxpYnZpc3VhbC0wLjQKICAgICAgKiAzMzc1NDQg OiBbeHZpbWFnZXNpbmtdIEludGVybmFsIEVycm9yIHdoZW4gaW1hZ2UgaXMgdG9vIGxhcmdlCiAg ICAgICogMzM5NTIwIDogW3N1YnBhcnNlXSBhZGQgIiBlbmNvZGluZyAiIHByb3BlcnR5CiAgICAg ICogMzQwOTA5IDogW2Fsc2FzaW5rXSBjYW4ndCBlbmFibGUgc3BkaWYgb3V0cHV0CiAgICAgICog MzQxNTQyIDogc29tZSB1c2VycyBoYXZlIGFuIGFzc2VydGlvbiBmYWlsZWQ6IChHU1RfVklERU9f U0lOS19XSURULi4uCiAgICAgICogMzQxNTYyIDogYXVkaW9jb252ZXJ0IGRvZXNuJ3QgbGlzdCBm b3JtYXRzIGluIG9yZGVyIG9mIHByZWZlcmVuY2UKICAgICAgKiAzNDE2OTYgOiBhdWRpb2NvbnZl cnQgY3Jhc2hlcyBpZiBjb252ZXJ0aW5nIGZyb20gYSBmb3JtYXQgd2l0aCBubyAuLi4KICAgICAg KiAzNDE3MTkgOiBiaXNlY3Rpb24gYWxnb3JpdGhtIGluIG9nZyBkb2Vzbid0IGJpc2VjdCBpbiBz b21lIGNhc2VzCiAgICAgICogMzQxNzMyIDogW2Fsc2FzaW5rXSBkb2Vzbid0IHF1ZXJ5IHN1cHBv cnRlZCBzYW1wbGUgcmF0ZXMKICAgICAgKiAzNDE4NzMgOiBbYWxzYXNpbmtdIG1pbm9yIG1lbW9y eSBsZWFrLCB1c2VzIHVucHJvdGVjdGVkIHN0YXRpYyB2YXIuLi4KICAgICAgKiAzNDIxNDMgOiBb c3VicGFyc2VdIHNhbWkgcGFyc2VyIG5lZWRzIHRvIGVzY2FwZSBjaGFyYWN0ZXJzCiAgICAgICog MzQyMTgxIDogW2Fsc2FdIGFkZCBwcm9wZXJ0eSBwcm9iZSBpbnRlcmZhY2UgdG8gYWxzYXNpbmsg YW5kIGFsc2FzcmMKICAgICAgKiAzNDIyNjggOiBbcGxheWJpbl0gYWRkICdzdWJ0aXRsZS1lbmNv ZGluZycgcHJvcGVydHkKICAgICAgKiAzNDIzNDUgOiBbcmlmZl0gRWxlcGhhbnQncyBEcmVhbSBB VkkgZG9lcyBub3QgcGxheSwgSlVOSyBjaHVuayBiZWYuLi4KICAgICAgKiAzNDI1NjYgOiBCdWls ZGluZyB3aXRob3V0IEdUSysgZmFpbHMKICAgICAgKiAzNDMzOTcgOiBILjI2NC9BQUMgbW92aWUg ZGVhZGxvY2tzIHdpdGggdG90ZW0gaW4gZ3N0cmVhbWVyIGNvZGUsIHAuLi4KICAgICAgKiAzMzk5 MzUgOiBbYWRkZXJdIGRlYWQtbG9ja3Mgd2hlbiBhZGRpbmcgc2luayBwYWRzIGluIFBBVVNFRCBz dGF0ZQoKRG93bmxvYWQKCllvdSBjYW4gZmluZCBzb3VyY2UgcmVsZWFzZXMgb2YgZ3N0LXBsdWdp bnMtYmFzZSBpbiB0aGUgZG93bmxvYWQgZGlyZWN0b3J5OgpodHRwOi8vZ3N0cmVhbWVyLmZyZWVk ZXNrdG9wLm9yZy9zcmMvZ3N0LXBsdWdpbnMtYmFzZS8KCkdTdHJlYW1lciBIb21lcGFnZQoKTW9y ZSBkZXRhaWxzIGNhbiBiZSBmb3VuZCBvbiB0aGUgcHJvamVjdCdzIHdlYnNpdGU6Cmh0dHA6Ly9n c3RyZWFtZXIuZnJlZWRlc2t0b3Aub3JnLwoKU3VwcG9ydCBhbmQgQnVncwoKV2UgdXNlIEdOT01F J3MgYnVnemlsbGEgZm9yIGJ1ZyByZXBvcnRzIGFuZCBmZWF0dXJlIHJlcXVlc3RzOgpodHRwOi8v YnVnemlsbGEuZ25vbWUub3JnL2VudGVyX2J1Zy5jZ2k/cHJvZHVjdD1HU3RyZWFtZXIKCkRldmVs b3BlcnMKCkNWUyBpcyBob3N0ZWQgb24gY3ZzLmZyZWVkZXNrdG9wLm9yZy4KQWxsIGNvZGUgaXMg aW4gQ1ZTIGFuZCBjYW4gYmUgY2hlY2tlZCBvdXQgZnJvbSB0aGVyZS4KSW50ZXJlc3RlZCBkZXZl bG9wZXJzIG9mIHRoZSBjb3JlIGxpYnJhcnksIHBsdWctaW5zLCBhbmQgYXBwbGljYXRpb25zIHNo b3VsZApzdWJzY3JpYmUgdG8gdGhlIGdzdHJlYW1lci1kZXZlbCBsaXN0LiBJZiB0aGVyZSBpcyBz dWZmaWNpZW50IGludGVyZXN0IHdlCndpbGwgY3JlYXRlIG1vcmUgbGlzdHMgYXMgbmVjZXNzYXJ5 LgoKICAgICAgICAKQXBwbGljYXRpb25zCiAgCkNvbnRyaWJ1dG9ycyB0byB0aGlzIHJlbGVhc2UK ICAgIAogICAgICAqIEVkd2FyZCBIZXJ2ZXkKICAgICAgKiBKYW4gU2NobWlkdAogICAgICAqIEp1 bGllbiBNb3V0dGUKICAgICAgKiBNYXJ0aW4gU3p1bGVja2kKICAgICAgKiBNaWNoYWVsIFNtaXRo CiAgICAgICogUGV0ZXIgS2plbGxlcnN0ZWR0CiAgICAgICogU2ViYXN0aWVuIE1vdXR0ZQogICAg ICAqIFN0ZWZhbiBLb3N0CiAgICAgICogVGhvbWFzIFZhbmRlciBTdGljaGVsZQogICAgICAqIFRp bS1QaGlsaXBwIE3DvGxsZXIKICAgICAgKiBXaW0gVGF5bWFucwogICAgICAqIFlvdW5nLUhvIENo YQogICAgICAqIFphaGVlciBBYmJhcyBNZXJhbGkKwqA= --127.0.0.1.500.5548.1149880308.216.2-- From thomas@apestaart.org Sat Jun 10 13:20:04 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 77ABD3B0280 for ; Sat, 10 Jun 2006 13:20:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16793-02 for ; Sat, 10 Jun 2006 13:20:03 -0400 (EDT) Received: from core.fluendo.com (core.fluendo.com [195.10.6.237]) by menubar.gnome.org (Postfix) with ESMTP id E5DCC3B01B8 for ; Sat, 10 Jun 2006 13:20:02 -0400 (EDT) Received: from onzenbak.amantes (70.Red-81-38-184.dynamicIP.rima-tde.net [81.38.184.70]) by core.fluendo.com (Postfix) with ESMTP id 205F71DC; Sat, 10 Jun 2006 19:20:01 +0200 (CEST) Received: from otto.amantes (otto.amantes [192.168.1.10]) by onzenbak.amantes (Postfix) with ESMTP id 4680720476; Sat, 10 Jun 2006 19:19:58 +0200 (CEST) Received: from otto.amantes (otto.amantes [127.0.0.1]) by otto.amantes (Postfix) with ESMTP id 3B641EFC0D; Sat, 10 Jun 2006 19:20:01 +0200 (CEST) Content-Type: multipart/mixed; boundary="127.0.0.1.500.6078.1149960001.170.2" MIME-Version: 1.0 To: gstreamer-devel@lists.sourceforge.net, gstreamer-announce@lists.sourceforge.net, kde-multimedia@kde.org, gnome-multimedia@gnome.org Message-Id: <20060610172001.3B641EFC0D@otto.amantes> Date: Sat, 10 Jun 2006 19:20:01 +0200 (CEST) From: thomas@apestaart.org X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.991 tagged_above=-999 required=2 tests=[AWL=-1.373, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, MIME_BASE64_TEXT=1.885, NO_REAL_NAME=0.961] X-Spam-Score: -0.991 X-Spam-Level: Cc: Subject: RELEASE: GStreamer 0.10.8 'Soepeke, ik zie ou nog altijd nie' X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 17:20:04 -0000 --127.0.0.1.500.6078.1149960001.170.2 Content-Type: text/plain This mail announces the release of GStreamer 0.10.8 'Soepeke, ik zie ou nog altijd nie'. GStreamer is a streaming media framework that allows the construction of graphs of elements which operate on media data. Applications using this library can do anything from real-time sound processing over playing video to capturing audio, video, and even other types of media data. Its architecture allows for adding new data types or processing capabilities simply by installing new plug-ins. GStreamer is the core module, containing libraries, headers, the basic object hierarchy, and a set of media-agnostic core elements. For more information, see [http://gstreamer.freedesktop.org/modules/gstreamer.html] To file bugs, go to [http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer&component=gstreamer+%28core%29] --127.0.0.1.500.6078.1149960001.170.2 Content-Type: text/plain; name=RELEASE Content-Transfer-Encoding: base64 ClJlbGVhc2Ugbm90ZXMgZm9yIEdTdHJlYW1lcsKgMC4xMC44ICJTb2VwZWtlLCBpayB6aWUgb3Ug bm9nIGFsdGlqZCBuaWUiCiAgICAgICAgCgoKVGhlIEdTdHJlYW1lciB0ZWFtIGlzIHByb3VkIHRv IGFubm91bmNlIGEgbmV3IHJlbGVhc2UKaW4gdGhlIDAuMTAueCBzdGFibGUgc2VyaWVzIG9mIHRo ZQpjb3JlIG9mIHRoZSBHU3RyZWFtZXIgc3RyZWFtaW5nIG1lZGlhIGZyYW1ld29yay4KCgpUaGUg MC4xMC54IHNlcmllcyBpcyBhIHN0YWJsZSBzZXJpZXMgdGFyZ2V0ZWQgYXQgZW5kIHVzZXJzLgpJ dCBpcyBub3QgQVBJIG9yIEFCSSBjb21wYXRpYmxlIHdpdGggdGhlIHN0YWJsZSAwLjgueCBzZXJp ZXMuCkl0IGlzLCBob3dldmVyLCBwYXJhbGxlbCBpbnN0YWxsYWJsZSB3aXRoIHRoZSAwLjgueCBz ZXJpZXMuCgoKVGhlIDAuMTAueCBzZXJpZXMgaGFzIGJlZW4gcmV3b3JrZWQgZm9yIHRocmVhZHNh ZmV0eS4gIEl0IGFsc28gZmVhdHVyZXMKdmFyaW91cyBmZWF0dXJlIGFkZGl0aW9ucyBhbmQgZW5j aGFuY2VtZW50cy4KCgpUaGlzIG1vZHVsZSwgZ3N0cmVhbWVyLCBvbmx5IGNvbnRhaW5zIGNvcmUg ZnVuY3Rpb25hbGl0eS4KRm9yIGFjdHVhbCBtZWRpYSBwbGF5YmFjaywgeW91IHdpbGwgbmVlZCBv dGhlciBtb2R1bGVzLgoKZ3N0LXBsdWdpbnMtYmFzZQpjb250YWlucyBhIGJhc2ljIHNldCBvZiB3 ZWxsLXN1cHBvcnRlZCBwbHVnLWlucwpnc3QtcGx1Z2lucy1nb29kCmNvbnRhaW5zIGEgc2V0IG9m IHdlbGwtc3VwcG9ydGVkIHBsdWctaW5zIHVuZGVyIG91ciBwcmVmZXJyZWQgbGljZW5zZQpnc3Qt cGx1Z2lucy11Z2x5CmNvbnRhaW5zIGEgc2V0IG9mIHdlbGwtc3VwcG9ydGVkIHBsdWctaW5zLCBi dXQgbWlnaHQgcG9zZSBwcm9ibGVtcyBmb3IKICAgIGRpc3RyaWJ1dG9ycwpnc3QtcGx1Z2lucy1i YWQKY29udGFpbnMgYSBzZXQgb2YgbGVzcyBzdXBwb3J0ZWQgcGx1Zy1pbnMgdGhhdCBoYXZlbid0 IHBhc3NlZCB0aGUKICAgIHJpZ29yb3VzIHF1YWxpdHkgdGVzdGluZyB3ZSBleHBlY3QKCgoKICAK RmVhdHVyZXMgb2YgdGhpcyByZWxlYXNlCiAgICAKICAgICAgKiBQYXJhbGxlbCBpbnN0YWxsYWJp bGl0eSB3aXRoIDAuOC54IHNlcmllcwogICAgICAqIFRocmVhZHNhZmUgZGVzaWduIGFuZCBBUEkK ICAgICAgKiBJbXBvcnRhbnQgZml4IGZvciByZWdpc3RyeSB1cGRhdGUgY2F1c2luZyBhcHBsZXRz IG5vdCB0byBsb2FkCgpCdWdzIGZpeGVkIGluIHRoaXMgcmVsZWFzZQogICAgCiAgICAgICogMzQ0 NDc0IDogR25vbWUgTWl4ZXIgQXBwbGV0IGRvZXNuJ3Qgd2FudCB0byBsb2FkCgpEb3dubG9hZAoK WW91IGNhbiBmaW5kIHNvdXJjZSByZWxlYXNlcyBvZiBnc3RyZWFtZXIgaW4gdGhlIGRvd25sb2Fk IGRpcmVjdG9yeToKaHR0cDovL2dzdHJlYW1lci5mcmVlZGVza3RvcC5vcmcvc3JjL2dzdHJlYW1l ci8KCkdTdHJlYW1lciBIb21lcGFnZQoKTW9yZSBkZXRhaWxzIGNhbiBiZSBmb3VuZCBvbiB0aGUg cHJvamVjdCdzIHdlYnNpdGU6Cmh0dHA6Ly9nc3RyZWFtZXIuZnJlZWRlc2t0b3Aub3JnLwoKU3Vw cG9ydCBhbmQgQnVncwoKV2UgdXNlIEdOT01FJ3MgYnVnemlsbGEgZm9yIGJ1ZyByZXBvcnRzIGFu ZCBmZWF0dXJlIHJlcXVlc3RzOgpodHRwOi8vYnVnemlsbGEuZ25vbWUub3JnL2VudGVyX2J1Zy5j Z2k/cHJvZHVjdD1HU3RyZWFtZXIKCkRldmVsb3BlcnMKCkNWUyBpcyBob3N0ZWQgb24gY3ZzLmZy ZWVkZXNrdG9wLm9yZy4KQWxsIGNvZGUgaXMgaW4gQ1ZTIGFuZCBjYW4gYmUgY2hlY2tlZCBvdXQg ZnJvbSB0aGVyZS4KSW50ZXJlc3RlZCBkZXZlbG9wZXJzIG9mIHRoZSBjb3JlIGxpYnJhcnksIHBs dWctaW5zLCBhbmQgYXBwbGljYXRpb25zIHNob3VsZApzdWJzY3JpYmUgdG8gdGhlIGdzdHJlYW1l ci1kZXZlbCBsaXN0LiBJZiB0aGVyZSBpcyBzdWZmaWNpZW50IGludGVyZXN0IHdlCndpbGwgY3Jl YXRlIG1vcmUgbGlzdHMgYXMgbmVjZXNzYXJ5LgoKICAgICAgICAKQXBwbGljYXRpb25zCgpBcHBs aWNhdGlvbnMgcG9ydGVkIHRvIEdTdHJlYW1lciAwLjEwIGluY2x1ZGUgVG90ZW0sIFJoeXRobUJv eCwgU291bmQtSnVpY2VyLApHbm9tZSBNZWRpYSwgRmx1bW90aW9uLCBBbWFyb2ssIEphbWJvcmVl LCBQaXRpdmksIElzdGFuYnVsLCBBbm5vQW1wLCBFbGlzYSwgYW5kIG90aGVycy4KTGV0IHVzIGtu b3cgaWYgeW91IHdhbnQgdG8gYmUgYWRkZWQgdG8gdGhpcyBsaXN0LgoKICAKQ29udHJpYnV0b3Jz IHRvIHRoaXMgcmVsZWFzZQogICAgCiAgICAgICogRWR3YXJkIEhlcnZleQogICAgICAqIFRob21h cyBWYW5kZXIgU3RpY2hlbGUKICAgICAgKiBUaW0tUGhpbGlwcCBNw7xsbGVyCsKg --127.0.0.1.500.6078.1149960001.170.2-- From sjoeboo@sjoeboo.com Wed Jun 14 10:50:35 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CE3003B037F; Wed, 14 Jun 2006 10:50:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08478-04; Wed, 14 Jun 2006 10:50:34 -0400 (EDT) Received: from server.sjoeboo.com (unknown [64.79.192.114]) by menubar.gnome.org (Postfix) with ESMTP id D38F13B02C8; Wed, 14 Jun 2006 10:50:33 -0400 (EDT) Received: by server.sjoeboo.com (Postfix, from userid 33) id 6D37418C4F7F; Wed, 14 Jun 2006 07:50:15 -0700 (PDT) To: gnome-multimedia@gnome.org, rhythmbox-devel@gnome.org Subject: totem and goom information... MIME-Version: 1.0 Date: Wed, 14 Jun 2006 7:50:15 -0700 From: sjoeboo Organization: sjoeboo.com Message-ID: <5135b2d86e5568cedc7e8138809a3b9f@localhost> X-Sender: sjoeboo@sjoeboo.com User-Agent: RoundCube Webmail/0.1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[AWL=0.000, BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: sjoeboo@sjoeboo.com List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 14:50:36 -0000 Good "morning" everyone, So, my (and what should be everyones) favorite music player for gnome, rhythmbox, has been on a steady march of advancement for the past few months, with a whole slew of new features comming about. One thing I though of recently is visualizations, and how ncie it would be to have at least one, possibly as a plugin. I know totem uses GOOM to do this, and was wondering what I might have to do in terms of gstreamer etc to have rhythmbox use it as well. I was looking around on the Totem site for a mailing list etc, but couldn't find anything. Does anyone know where I might find more info for something like this? Thanks, and keep up the great work. -- Matthew Nicholson sjoeboo@sjoeboo.com sjoeboo.com From internalerror@gmail.com Thu Jun 22 05:25:58 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E43203B02D2 for ; Thu, 22 Jun 2006 05:25:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12537-03 for ; Thu, 22 Jun 2006 05:25:56 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.201]) by menubar.gnome.org (Postfix) with ESMTP id D48DD3B0179 for ; Thu, 22 Jun 2006 05:25:55 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so314263wxc for ; Thu, 22 Jun 2006 02:25:55 -0700 (PDT) Received: by 10.70.91.12 with SMTP id o12mr2775555wxb; Thu, 22 Jun 2006 02:25:55 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 02:25:55 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 11:25:55 +0200 From: "Milosz Derezynski" To: xdg@lists.freedesktop.org Subject: MLQ (Media Library Query) file format and mime type proposal MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3009_31371308.1150968355005" X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.255 tagged_above=-999 required=2 tests=[AWL=0.344, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.255 X-Spam-Level: Cc: gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 09:25:58 -0000 ------=_Part_3009_31371308.1150968355005 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I'm one of the main authors of BMP 2 (still being worked on), and along the way of reworking our library, i came across the idea of encoding library queries as URIs, which may look like this: "query:///?artist=Air&album=Moon%20Safari" BMP 2 has a plugin archicture which is a small VFS on it's own, and we treat certain things as "containers" (i.e. they "contain" URIs, like PLS playlists, XSPF, M3U, etc). Now i thought it might be not a bad idea to create a playlist format with these query URLs, and i've called it "MLQ" for media library query. In theory, it's not even application specific. The keys (identifiers), like artist, album, etc, are all based on GStreamer tag identifiers. (They could be maybe adapted to http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but it seems insufficient and doesn't specify certain items, like musicbrainz metadata, which GST does). So i've called this file format "MLQ", with the extension .mlq, created a mime package file for it: Media Library Query List Adding a file of this type to BMPx, or just a plain query:/// URI itself causes a library query and appending of the relevant items to the tracklist (BMP is currently mostly based on the concept of a mutable playlist to which items can be added from various sources, unlike e.g. RB which has mostly immutable "Playlists", but allows for custom queues). Another example is: query:///?artist=Air&album=Moon%20Safari&title=La%20Femme%20d'Argent query:///?artist=Air&album=Moon%20Safari&title=Sexy%20Boy query:///?artist=Air&album=Moon%20Safari&title=All%20I%20Need query:///?artist=Air&album=Moon%20Safari&title=Kelly,%20Watch%20The%20Stars! query:///?artist=Air&album=Moon%20Safari&title=Talisman query:///?artist=Air&album=Moon%20Safari&title=Remember query:///?artist=Air&album=Moon%20Safari&title=You%20Make%20It%20Easy query:///?artist=Air&album=Moon%20Safari&title=Ce%20Matin%20La query:///?artist=Air&album=Moon%20Safari&title=New%20Star%20In%20The%20Sky query:///?artist=Air&album=Moon%20Safari&title=Le%20Voyage%20De%20Penelope Or it might just be: query:///?genre=Jazz Since this is very common, and having the discussions about a common music database in mind, this seems like a useful proposal, since it is not player specific. This ships currently with BMP 2/BMPx SVN, and while i will ship this with the 0.20 release (end-July) anyway, what does everyone think of this in a broader context (common music database, etc)? -- Milosz ------=_Part_3009_31371308.1150968355005 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

I'm one of the main authors of BMP 2 (still being worked on), and along the way of reworking our library, i came across the idea of encoding library queries as URIs, which may look like this:

"query:///?artist=Air&album=Moon%20Safari"

BMP 2 has a plugin archicture which is a small VFS on it's own, and we treat certain things as "containers" (i.e. they "contain" URIs, like PLS playlists, XSPF, M3U, etc).
Now i thought it might be not a bad idea to create a playlist format with these query URLs, and i've called it "MLQ" for media library query. In theory, it's not even
application specific. The keys (identifiers), like artist, album, etc, are all based on GStreamer tag identifiers. (They could be maybe adapted to http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but it seems insufficient and doesn't specify certain items, like musicbrainz metadata, which GST does).

So i've called this file format "MLQ", with the extension .mlq, created a mime package file for it:

<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info ">
  <mime-type type="application/x-media-library-query">
         <comment xml:lang="en">Media Library Query List</comment>
         <magic priority="50">
            <match value="query:///" type="string" offset="0"/>
         </magic>
         <glob pattern="*.mlq"/>
  </mime-type>
</mime-info>

Adding a file of this type to BMPx, or just a plain query:/// URI itself causes a library query and appending of the relevant items to the tracklist (BMP is currently mostly based on the concept of a mutable playlist to which items can be added from various sources, unlike e.g. RB which has mostly immutable "Playlists", but allows for custom queues).

Another example is:

query:///?artist=Air&album=Moon%20Safari&title=La%20Femme%20d'Argent
query:///?artist=Air&album=Moon%20Safari&title=Sexy%20Boy
query:///?artist=Air&album=Moon%20Safari&title=All%20I%20Need
query:///?artist=Air&album=Moon%20Safari&title=Kelly,%20Watch%20The%20Stars!
query:///?artist=Air&album=Moon%20Safari&title=Talisman
query:///?artist=Air&album=Moon%20Safari&title=Remember
query:///?artist=Air&album=Moon%20Safari&title=You%20Make%20It%20Easy
query:///?artist=Air&album=Moon%20Safari&title=Ce%20Matin%20La
query:///?artist=Air&album=Moon%20Safari&title=New%20Star%20In%20The%20Sky
query:///?artist=Air&album=Moon%20Safari&title=Le%20Voyage%20De%20Penelope

Or it might just be:

query:///?genre=Jazz

Since this is very common, and having the discussions about a common music database in mind, this seems like a useful proposal, since it is not player specific.
This ships currently with BMP 2/BMPx SVN, and while i will ship this with the 0.20 release (end-July) anyway, what does everyone think of this in a broader context (common music database, etc)?

-- Milosz
------=_Part_3009_31371308.1150968355005-- From internalerror@gmail.com Thu Jun 22 05:32:59 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7208D3B00DE for ; Thu, 22 Jun 2006 05:32:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12916-03 for ; Thu, 22 Jun 2006 05:32:58 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.207]) by menubar.gnome.org (Postfix) with ESMTP id 6F0643B0373 for ; Thu, 22 Jun 2006 05:32:58 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so314918wxc for ; Thu, 22 Jun 2006 02:32:57 -0700 (PDT) Received: by 10.70.103.9 with SMTP id a9mr2787413wxc; Thu, 22 Jun 2006 02:32:57 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 02:32:57 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 11:32:57 +0200 From: "Milosz Derezynski" To: xdg@lists.freedesktop.org Subject: MLQ: Followup MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3081_18949182.1150968777845" X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.875 tagged_above=-999 required=2 tests=[AWL=-0.071, BAYES_00=-2.599, HTML_00_10=0.795, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -1.875 X-Spam-Level: Cc: gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 09:32:59 -0000 ------=_Part_3081_18949182.1150968777845 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline What i forgot to mention: One benefit of MLQs over 'regular' playlists at least with BMP 2 is that i've introduced a concept of keeping track of tracks across mount point changes which basically works like this: BMP stores for each file the HAL volume and device UDI, and the VRP (Volume Relative Path), that is, the path stripped off the mount point root. Whenever it seems that a file is missing, it checks whether the volume UDI of this file is still present on the system, and if so, gathers the new mount point, and adjusts the URI of this file in the library (this obiviously only works with tracks from the library only anyway since only there we can reliably store the HAL volume/device UDI and the VRP). This means practically: - Mount your music to /music - Start BMP - Add music from /music to the library - Quit BMP - Remount /music to e.g. /old_music - Start BMP - Use the library as before. Whenever BMP finds a file is missing, it will correct the URI on-the-fly as long as the volume is mounted at all on the system (and has an UDI to begin with; problem cases here are network volumes, NFS and SMBFS) So the benefit of an MLQ is that unlike a static playlist, you can be rather sure that no matter where you really move the music, BMP will always be able to find it. Downsides/doesn't-works: - There is no volume UDI available - You make a regular 'move' (mv), and not just a remount In the context of having a common music database, or something like Tracker, this seems very useful (Jamie: Hence my urge to add HAL volume/device UDI per file to the metadata). -- Milosz ------=_Part_3081_18949182.1150968777845 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline What i forgot to mention:

One benefit of MLQs over 'regular' playlists at least with BMP 2 is that i've introduced a concept of keeping track of tracks across mount point changes which basically works like this:

BMP stores for each file the HAL volume and device UDI, and the VRP (Volume Relative Path), that is, the path stripped off the mount point root.
Whenever it seems that a file is missing, it checks whether the volume UDI of this file is still present on the system, and if so, gathers the new mount point, and adjusts the URI of this
file in the library (this obiviously only works with tracks from the library only anyway since only there we can reliably store the HAL volume/device UDI and the VRP).

This means practically:

- Mount your music to /music
- Start BMP
- Add music from /music to the library
- Quit BMP
- Remount /music to e.g. /old_music
- Start BMP
- Use the library as before. Whenever BMP finds a file is missing, it will correct the URI on-the-fly as long as the volume is mounted at all on the system (and has an UDI to begin with; problem cases here are network volumes, NFS and SMBFS)

So the benefit of an MLQ is that unlike a static playlist, you can be rather sure that no matter where you really move the music, BMP will always be able to find it.

Downsides/doesn't-works:

- There is no volume UDI available
- You make a regular 'move' (mv), and not just a remount

In the context of having a common music database, or something like Tracker, this seems very useful (Jamie: Hence my urge to add HAL volume/device UDI per file to the metadata).

-- Milosz
------=_Part_3081_18949182.1150968777845-- From internalerror@gmail.com Thu Jun 22 06:23:10 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 61AE53B0403 for ; Thu, 22 Jun 2006 06:23:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15637-08 for ; Thu, 22 Jun 2006 06:23:09 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.195]) by menubar.gnome.org (Postfix) with ESMTP id 7534E3B045B for ; Thu, 22 Jun 2006 06:23:08 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so321629wxc for ; Thu, 22 Jun 2006 03:23:07 -0700 (PDT) Received: by 10.70.14.14 with SMTP id 14mr2842980wxn; Thu, 22 Jun 2006 03:23:07 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 03:23:07 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 12:23:07 +0200 From: "Milosz Derezynski" To: "Josef Spillner" Subject: Re: MLQ (Media Library Query) file format and mime type proposal In-Reply-To: <200606221139.41836.spillner@kde.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3405_33193106.1150971787566" References: <200606221139.41836.spillner@kde.org> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.443 tagged_above=-999 required=2 tests=[AWL=-0.496, BAYES_00=-2.599, HTML_10_20=1.351, HTML_MESSAGE=0.001, MIME_BASE64_NO_NAME=0.224, SPF_PASS=-0.001, TW_XD=0.077] X-Spam-Score: -1.443 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 10:23:10 -0000 ------=_Part_3405_33193106.1150971787566 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline WWVhaCB3ZWxsIGp1c3QgdG8gc3RheSB3aXRoaW4gdGhlIGZvY3VzIG9mIGEgbXVzaWMgbGlicmFy eSwgdGhlcmUgaGFzIHRvIGJlCnNvbWV0aGluZwp0aGF0IGRvZXMgdGhlIHJlc29sdXRpb24uCgpP TkUgcG9zc2libGUgb3B0aW9uIHdvdWxkIGJlIHRvIHNwZWNpZnkgYSBELUJVUyBpbnRlcmZhY2Ug bmFtZSwgYW5kIGEgaGF2ZQpzaW1wbGUgbGF1bmNoZXIuCgpBbGwgYXBwcyBzdXBwb3J0aW5nIE1M UXMgd291bGQgaGF2ZSB0byBoYXZlIGEgbWluaW1hbCBjb21tb24gc3Vic2V0Cm9mIEQtQlVTIGlu dGVyZmFjZXJ5IHRvIGFsbG93IHRoaXMga2luZCBvZiBxdWVyeSB0byBiZSBzZW50IHRvIHRoZW0g aW4gc29tZQp3YXkKKHNvbWV0aGluZyBsaWtlIGFuIEFkZFVyaSBjYWxsIG1pZ2h0IGp1c3Qgc3Vm ZmljZSksIHRoZW4gdGhlIGxhdW5jaGVyIHdvdWxkCmJhc2ljYWxseQpjb25zaXN0IG9mIHN0YXJ0 aW5nIHRoZSByZWxldmFudCBhcGxsaWNhdGlvbiB0cm91Z2ggRC1CVVMgYWN0aXZhdGlvbiwgYW5k CnRoZW4gcGFzcyBvbgp0aGUgYWN0dWFsIHF1ZXJ5IHRvIGl0LgoKKFdlIGhhdmUgYSBkdW1teSBt ZXRob2QgIlN0YXJ0dXAiIG9uIG91ciBELUJVUyBpZmFjZSB3aGljaApkb2VzIG5vdGhpbmcsIGJ1 dCBjYXVzZXMgRC1CVVMgdG8gc3RhcnQgdXAgQk1QLiBUaGUgcmVhc29uaW5nIGlzIHRoYXQgd2UK aGF2ZSBvbmUgbWFpbgpiaW5hcnkgYW5kIG9uZSAicmVtb3RlIiBiaW5hcnksIHdoaWNoIGlzIHRo b3VnaCBzZXQgc28gdGhhdCBpdCBpcyBwZXJjZWl2ZWQKYXMgYmVpbmcgdGhlIG1haW4KYmluYXJ5 LCBhcyBpbiBpdCdzIGluIC91c3IvYmluLCB3aGVyZWFzIHRoZSAtYmluIChtYWluKSBiaW5hcnkg aXMgaW4KL3Vzci9saWJleGVjLiBUaGUgcmVhc29uCmlzIHNvIHRoYXQgd2UgaGF2ZSBhIGxpZ2h0 d2VpZ2h0IHJlbW90ZSBhcHAgdGhhdCBjYW4gcGVyZm9ybSBhY3Rpb25zIG9uIHRoZQptYWluIGJp bmFyeQphbmQgZG9uJ3QgaGF2ZSB0byBoYXZlIHRoZSBtYWluIGFwcCBiZSBjYXBhYmxlIG9mIGJl aW5nIGEgY2xpZW50IHRvIGl0J3Mgb3duCnNlcnZlcgphbmQgaGF2ZSBhbGwgdGhlIHN0YXJ0dXAg c2hpenpsZSBnb2luZyBqdXN0IHRvIHBlcmZvcm0gYSBjZXJ0YWluIHJlbW90ZQpvcGVyYXRpb24p LgoKRm9yIGV4YW1wbGUgeW91J2QgaGF2ZToKcXVlcnk6Ly9vcmcuYmVlcG1lZGlhcGxheWVyLmJt cC8/YXJ0aXN0PUFpciZBbGJ1bT1Nb29uJTIwU2FmYXJpCgpUaGUgc2NyaXB0LCBvciBiZSBpdCBh IGJpbmFyeSwgbGV0J3MgY2FsbCBpdCAicGxheS1tbHEiLCB3b3VsZCBsYXVuY2ggdGhlCnBsYXll ciB3aXRoIHRoZSBzcGVjaWZpZWQgaW50ZXJmYWNlIGFuZCBwYXNzIGl0IHRoZSBhY3R1YWwgcXVl cnkuCgpfQW5vdGhlcl8gcG9zc2liaWxpdHksIGFsdGhvdWdoIHRoaXMgd291bGQgcmVxdWlyZSBw bGF5ZXJzIHRoYXQgY2FuIHdvcmsKd2l0aAptdXRhYmxlIHBsYXlsaXN0cyBsaWtlIEJNUCwgaXMg dGhhdCBpdCB3b3VsZCBwYXNzIHRoZSBxdWVyeSBvbiB0byBlLmcuCnNvbWV0aGluZwpsaWtlIFRy YWNrZXIgb3Igc29tZSBvdGhlciBpbmRleGVyLCB3aGljaCB3b3VsZCB0aGVuIGV4ZWN1dGUgdGhl IHF1ZXJ5IGFuZApfSVRfIHdvdWxkIHRoZW4gc3RhcnQgdGhlIHBsYXllciBzcGVjaWZpZWQgYnkg dGhlIGludGVyZmFjZSBhbmQgcGFzcyBpdAphbG9uZyB0aGUKcmVzdWx0aW5nIFVSSXMuCgotLSBN aWxvc3oKCk9uIDYvMjIvMDYsIEpvc2VmIFNwaWxsbmVyIDxzcGlsbG5lckBrZGUub3JnPiB3cm90 ZToKPgo+IEFsbGUgMTE6MjUsIGdpb3ZlZMOsLCAyMi4gZ2l1Z25vIDIwMDYsIE1pbG9zeiBEZXJl enluc2tpIGhhIHNjcml0dG86Cj4gPiBTaW5jZSB0aGlzIGlzIHZlcnkgY29tbW9uLCBhbmQgaGF2 aW5nIHRoZSBkaXNjdXNzaW9ucyBhYm91dCBhIGNvbW1vbgo+IG11c2ljCj4gPiBkYXRhYmFzZSBp biBtaW5kLCB0aGlzIHNlZW1zIGxpa2UgYSB1c2VmdWwgcHJvcG9zYWwsIHNpbmNlIGl0IGlzIG5v dAo+IHBsYXllcgo+ID4gc3BlY2lmaWMuCj4KPiBJdCBpcyBub3QgZXZlbiBtdXNpYyBzcGVjaWZp Yy4gSSd2ZSB1c2VkIHF1ZXJ5Oi8vIFVSSXMgZm9yIGEgbG9uZyB0aW1lCj4gd2l0aAo+IG1ldGFz ZXJ2ZXJzLCBhbHRob3VnaCBvbmx5IGluIGEgcmVhZC1vbmx5IGNvbnRleHQsIHdoZXJlYXMgZm9y IHdyaXRlCj4gYWNjZXNzCj4gdGhlIChhbHRlcm5hdGl2ZSkgZnVsbC1ibG93biBYTUwgaW50ZXJm YWNlIGlzIHVzZWQuCj4KPiBUaGUgd2F5IGl0IGlzIHVzZWQgZm9yIHRoZSBtZXRhc2VydmVyIGlz IGxpa2UgcXVlcnk6Ly90eXBlL2NhdGVnb3J5LCB3aGVyZQo+IGUuZy4gdHlwZSB3b3VsZCBiZSB0 aGUgZ2VuZXJpYyBuYW1lIGZvciBhIHNlcnZlciAoc2F5LCAnZnJlZWNpdicgb3IKPiAnY3Vwc2Qn KQo+IGFuZCBjYXRlZ29yeSB3b3VsZCBiZSAnY29ubmVjdGlvbicgKHRvIGdldCBiYWNrIGEgY29u bmVjdGlvbiBVUkkpIG9yCj4gJ21ldGEnCj4gKHRvIGdldCBiYWNrIG90aGVyIG1ldGFzZXJ2ZXIg VVJJcyBmb3IgdGhlIHNhbWUgdHlwZSkuCj4gVXNpbmcgc3VjaCBhIHNjaGVtZSBtYWtlcyBhbiBh cHBsaWNhdGlvbiByZXNpc3RhbnQgYWdhaW5zdCBob3N0IG5hbWUKPiBjaGFuZ2VzCj4gaW4gdGhl IGxvbmcgcnVuLCBpLmUuIGl0IHdpbGwgcGljayB1cCBtb3Zpbmcgc2VydmVycyBhdXRvbWF0aWNh bGx5Lgo+Cj4gVGhpcyBpcyBwcm9iYWJseSBub3QgdGhlIHNhbWUgdGhpbmcgYXMgeW91ciBxdWVy eSwgYnV0IG9idmlvdXNseSBpdCdzIGFsc28KPiB1c2VkIHRvIHF1ZXJ5IGEgZGF0YWJhc2UgYmVo aW5kIGl0ICh3aGljaCBpcyBhIFhNTCBkYXRhYmFzZSBpbiBteSBjYXNlLAo+IGJ1dAo+IGNvdWxk IGJlIFNRTCBvciBhbnl0aGluZyBlbHNlIGZvciB0aGF0IG1hdHRlcikuIFNvIG1heWJlIGl0IG1h a2VzIHNlbnNlIHRvCj4gc3RhbmRhcmRpc2UgdGhpcyBpbiBhIGJyb2FkZXIgY29udGV4dC4KPgo+ IEtERSBSYWRpbyBTdGF0aW9uIGlzIG9uZSBleGFtcGxlIHdoZXJlIHRoaXMgaXMgdXNlZCAoaGEg LSBmb3VuZCBhIHJlbGF0aW9uCj4gdG8KPiBtdXNpYyEpLCBhbmQgdGhlIEdHWiBHYW1pbmcgWm9u ZSBwcm9qZWN0IGlzIGFub3RoZXIgb25lICh3aGVyZSBpdAo+IG9yaWdpbmF0ZWQKPiBzaW5jZSBt ZXRhc2VydmVycyBhcmUgY29tbW9ucGxhY2Ugd2l0aCBnYW1lIHNlcnZlcnMpLgo+Cj4gSm9zZWYK PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IHhkZyBt YWlsaW5nIGxpc3QKPiB4ZGdAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCj4gaHR0cDovL2xpc3RzLmZy ZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hkZwo+Cg== ------=_Part_3405_33193106.1150971787566 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline WWVhaCB3ZWxsIGp1c3QgdG8gc3RheSB3aXRoaW4gdGhlIGZvY3VzIG9mIGEgbXVzaWMgbGlicmFy eSwgdGhlcmUgaGFzIHRvIGJlIHNvbWV0aGluZzxicj50aGF0IGRvZXMgdGhlIHJlc29sdXRpb24u PGJyPjxicj5PTkUgcG9zc2libGUgb3B0aW9uIHdvdWxkIGJlIHRvIHNwZWNpZnkgYSBELUJVUyBp bnRlcmZhY2UgbmFtZSwgYW5kIGEgaGF2ZSBzaW1wbGUgbGF1bmNoZXIuPGJyPjxicj5BbGwgYXBw cyBzdXBwb3J0aW5nIE1MUXMgd291bGQgaGF2ZSB0byBoYXZlIGEgbWluaW1hbCBjb21tb24gc3Vi c2V0Cjxicj5vZiBELUJVUyBpbnRlcmZhY2VyeSB0byBhbGxvdyB0aGlzIGtpbmQgb2YgcXVlcnkg dG8gYmUgc2VudCB0byB0aGVtIGluIHNvbWUgd2F5PGJyPihzb21ldGhpbmcgbGlrZSBhbiBBZGRV cmkgY2FsbCBtaWdodCBqdXN0IHN1ZmZpY2UpLCB0aGVuIHRoZSBsYXVuY2hlciB3b3VsZCBiYXNp Y2FsbHk8YnI+Y29uc2lzdCBvZiBzdGFydGluZyB0aGUgcmVsZXZhbnQgYXBsbGljYXRpb24gdHJv dWdoIEQtQlVTIGFjdGl2YXRpb24sIGFuZCB0aGVuIHBhc3Mgb24KPGJyPnRoZSBhY3R1YWwgcXVl cnkgdG8gaXQuIDxicj48YnI+KFdlIGhhdmUgYSBkdW1teSBtZXRob2QgJnF1b3Q7U3RhcnR1cCZx dW90OyBvbiBvdXIgRC1CVVMgaWZhY2Ugd2hpY2g8YnI+ZG9lcyBub3RoaW5nLCBidXQgY2F1c2Vz IEQtQlVTIHRvIHN0YXJ0IHVwIEJNUC4gVGhlIHJlYXNvbmluZyBpcyB0aGF0IHdlIGhhdmUgb25l IG1haW48YnI+YmluYXJ5IGFuZCBvbmUgJnF1b3Q7cmVtb3RlJnF1b3Q7IGJpbmFyeSwgd2hpY2gg aXMgdGhvdWdoIHNldCBzbyB0aGF0IGl0IGlzIHBlcmNlaXZlZCBhcyBiZWluZyB0aGUgbWFpbgo8 YnI+YmluYXJ5LCBhcyBpbiBpdCdzIGluIC91c3IvYmluLCB3aGVyZWFzIHRoZSAtYmluIChtYWlu KSBiaW5hcnkgaXMgaW4gL3Vzci9saWJleGVjLiBUaGUgcmVhc29uPGJyPmlzIHNvIHRoYXQgd2Ug aGF2ZSBhIGxpZ2h0d2VpZ2h0IHJlbW90ZSBhcHAgdGhhdCBjYW4gcGVyZm9ybSBhY3Rpb25zIG9u IHRoZSBtYWluIGJpbmFyeTxicj5hbmQgZG9uJ3QgaGF2ZSB0byBoYXZlIHRoZSBtYWluIGFwcCBi ZSBjYXBhYmxlIG9mIGJlaW5nIGEgY2xpZW50IHRvIGl0J3Mgb3duIHNlcnZlcgo8YnI+YW5kIGhh dmUgYWxsIHRoZSBzdGFydHVwIHNoaXp6bGUgZ29pbmcganVzdCB0byBwZXJmb3JtIGEgY2VydGFp biByZW1vdGUgb3BlcmF0aW9uKS48YnI+PGJyPkZvciBleGFtcGxlIHlvdSdkIGhhdmU6PGJyPnF1 ZXJ5Oi8vb3JnLmJlZXBtZWRpYXBsYXllci5ibXAvP2FydGlzdD1BaXImYW1wO0FsYnVtPU1vb24l MjBTYWZhcmk8YnI+PGJyPlRoZSBzY3JpcHQsIG9yIGJlIGl0IGEgYmluYXJ5LCBsZXQncyBjYWxs IGl0ICZxdW90O3BsYXktbWxxJnF1b3Q7LCB3b3VsZCBsYXVuY2ggdGhlCjxicj5wbGF5ZXIgd2l0 aCB0aGUgc3BlY2lmaWVkIGludGVyZmFjZSBhbmQgcGFzcyBpdCB0aGUgYWN0dWFsIHF1ZXJ5Ljxi cj48YnI+X0Fub3RoZXJfIHBvc3NpYmlsaXR5LCBhbHRob3VnaCB0aGlzIHdvdWxkIHJlcXVpcmUg cGxheWVycyB0aGF0IGNhbiB3b3JrIHdpdGg8YnI+bXV0YWJsZSBwbGF5bGlzdHMgbGlrZSBCTVAs IGlzIHRoYXQgaXQgd291bGQgcGFzcyB0aGUgcXVlcnkgb24gdG8gCmUuZy4gc29tZXRoaW5nPGJy Pmxpa2UgVHJhY2tlciBvciBzb21lIG90aGVyIGluZGV4ZXIsIHdoaWNoIHdvdWxkIHRoZW4gZXhl Y3V0ZSB0aGUgcXVlcnkgYW5kPGJyPl9JVF8gd291bGQgdGhlbiBzdGFydCB0aGUgcGxheWVyIHNw ZWNpZmllZCBieSB0aGUgaW50ZXJmYWNlIGFuZCBwYXNzIGl0IGFsb25nIHRoZTxicj5yZXN1bHRp bmcgVVJJcy48YnI+PGJyPi0tIE1pbG9zejxicj48YnI+CjxkaXY+PHNwYW4gY2xhc3M9ImdtYWls X3F1b3RlIj5PbiA2LzIyLzA2LCA8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+Sm9zZWYgU3Bp bGxuZXI8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86c3BpbGxuZXJAa2RlLm9yZyI+c3BpbGxuZXJA a2RlLm9yZzwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv dGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFy Z2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4KQWxsZSAxMToyNSwg Z2lvdmVkw6wsIDIyLiBnaXVnbm8gMjAwNiwgTWlsb3N6IERlcmV6eW5za2kgaGEgc2NyaXR0bzo8 YnI+Jmd0OyBTaW5jZSB0aGlzIGlzIHZlcnkgY29tbW9uLCBhbmQgaGF2aW5nIHRoZSBkaXNjdXNz aW9ucyBhYm91dCBhIGNvbW1vbiBtdXNpYzxicj4mZ3Q7IGRhdGFiYXNlIGluIG1pbmQsIHRoaXMg c2VlbXMgbGlrZSBhIHVzZWZ1bCBwcm9wb3NhbCwgc2luY2UgaXQgaXMgbm90IHBsYXllcgo8YnI+ Jmd0OyBzcGVjaWZpYy48YnI+PGJyPkl0IGlzIG5vdCBldmVuIG11c2ljIHNwZWNpZmljLiBJJ3Zl IHVzZWQgcXVlcnk6Ly8gVVJJcyBmb3IgYSBsb25nIHRpbWUgd2l0aDxicj5tZXRhc2VydmVycywg YWx0aG91Z2ggb25seSBpbiBhIHJlYWQtb25seSBjb250ZXh0LCB3aGVyZWFzIGZvciB3cml0ZSBh Y2Nlc3M8YnI+dGhlIChhbHRlcm5hdGl2ZSkgZnVsbC1ibG93biBYTUwgaW50ZXJmYWNlIGlzIHVz ZWQuCjxicj48YnI+VGhlIHdheSBpdCBpcyB1c2VkIGZvciB0aGUgbWV0YXNlcnZlciBpcyBsaWtl IHF1ZXJ5Oi8vdHlwZS9jYXRlZ29yeSwgd2hlcmU8YnI+ZS5nLiB0eXBlIHdvdWxkIGJlIHRoZSBn ZW5lcmljIG5hbWUgZm9yIGEgc2VydmVyIChzYXksICdmcmVlY2l2JyBvciAnY3Vwc2QnKTxicj5h bmQgY2F0ZWdvcnkgd291bGQgYmUgJ2Nvbm5lY3Rpb24nICh0byBnZXQgYmFjayBhIGNvbm5lY3Rp b24gVVJJKSBvciAnbWV0YScKPGJyPih0byBnZXQgYmFjayBvdGhlciBtZXRhc2VydmVyIFVSSXMg Zm9yIHRoZSBzYW1lIHR5cGUpLjxicj5Vc2luZyBzdWNoIGEgc2NoZW1lIG1ha2VzIGFuIGFwcGxp Y2F0aW9uIHJlc2lzdGFudCBhZ2FpbnN0IGhvc3QgbmFtZSBjaGFuZ2VzPGJyPmluIHRoZSBsb25n IHJ1biwgaS5lLiBpdCB3aWxsIHBpY2sgdXAgbW92aW5nIHNlcnZlcnMgYXV0b21hdGljYWxseS48 YnI+PGJyPlRoaXMgaXMgcHJvYmFibHkgbm90IHRoZSBzYW1lIHRoaW5nIGFzIHlvdXIgcXVlcnks IGJ1dCBvYnZpb3VzbHkgaXQncyBhbHNvCjxicj51c2VkIHRvIHF1ZXJ5IGEgZGF0YWJhc2UgYmVo aW5kIGl0ICh3aGljaCBpcyBhIFhNTCBkYXRhYmFzZSBpbiBteSBjYXNlLCBidXQ8YnI+Y291bGQg YmUgU1FMIG9yIGFueXRoaW5nIGVsc2UgZm9yIHRoYXQgbWF0dGVyKS4gU28gbWF5YmUgaXQgbWFr ZXMgc2Vuc2UgdG88YnI+c3RhbmRhcmRpc2UgdGhpcyBpbiBhIGJyb2FkZXIgY29udGV4dC48YnI+ PGJyPktERSBSYWRpbyBTdGF0aW9uIGlzIG9uZSBleGFtcGxlIHdoZXJlIHRoaXMgaXMgdXNlZCAo aGEgLSBmb3VuZCBhIHJlbGF0aW9uIHRvCjxicj5tdXNpYyEpLCBhbmQgdGhlIEdHWiBHYW1pbmcg Wm9uZSBwcm9qZWN0IGlzIGFub3RoZXIgb25lICh3aGVyZSBpdCBvcmlnaW5hdGVkPGJyPnNpbmNl IG1ldGFzZXJ2ZXJzIGFyZSBjb21tb25wbGFjZSB3aXRoIGdhbWUgc2VydmVycykuPGJyPjxicj5K b3NlZjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj54ZGcgbWFpbGluZyBsaXN0Cjxicj48YSBocmVmPSJtYWlsdG86eGRnQGxpc3RzLmZyZWVkZXNr dG9wLm9yZyI+eGRnQGxpc3RzLmZyZWVkZXNrdG9wLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cDov L2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hkZyI+aHR0cDovL2xpc3Rz LmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hkZzwvYT48YnI+PC9ibG9ja3F1b3Rl PjwvZGl2Pjxicj4K ------=_Part_3405_33193106.1150971787566-- From jamiemcc@blueyonder.co.uk Thu Jun 22 06:41:17 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 687D03B0251 for ; Thu, 22 Jun 2006 06:41:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17075-06 for ; Thu, 22 Jun 2006 06:41:15 -0400 (EDT) Received: from smtp-out5.blueyonder.co.uk (smtp-out5.blueyonder.co.uk [195.188.213.8]) by menubar.gnome.org (Postfix) with ESMTP id 74F7B3B021B for ; Thu, 22 Jun 2006 06:41:15 -0400 (EDT) Received: from [172.23.170.145] (helo=anti-virus03-08) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1FtMca-0004xo-T2; Thu, 22 Jun 2006 11:41:12 +0100 Received: from [62.30.198.187] (helo=[62.30.198.187]) by asmtp-out2.blueyonder.co.uk with esmtpa (Exim 4.52) id 1FtMcZ-0001pP-Rp; Thu, 22 Jun 2006 11:41:11 +0100 Message-ID: <449A73D1.6030401@blueyonder.co.uk> Date: Thu, 22 Jun 2006 11:41:21 +0100 From: Jamie McCracken User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Milosz Derezynski Subject: Re: MLQ: Followup References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.459 tagged_above=-999 required=2 tests=[AWL=0.141, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.459 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 10:41:17 -0000 Milosz Derezynski wrote: > What i forgot to mention: > > One benefit of MLQs over 'regular' playlists at least with BMP 2 is that > i've introduced a concept of keeping track of tracks across mount point > changes which basically works like this: > > BMP stores for each file the HAL volume and device UDI, and the VRP > (Volume Relative Path), that is, the path stripped off the mount point root. > Whenever it seems that a file is missing, it checks whether the volume > UDI of this file is still present on the system, and if so, gathers the > new mount point, and adjusts the URI of this > file in the library (this obiviously only works with tracks from the > library only anyway since only there we can reliably store the HAL > volume/device UDI and the VRP). > > This means practically: > > - Mount your music to /music > - Start BMP > - Add music from /music to the library > - Quit BMP > - Remount /music to e.g. /old_music > - Start BMP > - Use the library as before. Whenever BMP finds a file is missing, it > will correct the URI on-the-fly as long as the volume is mounted at all > on the system (and has an UDI to begin with; problem cases here are > network volumes, NFS and SMBFS) > > So the benefit of an MLQ is that unlike a static playlist, you can be > rather sure that no matter where you really move the music, BMP will > always be able to find it. > > Downsides/doesn't-works: > > - There is no volume UDI available > - You make a regular 'move' (mv), and not just a remount > > In the context of having a common music database, or something like > Tracker, this seems very useful (Jamie: Hence my urge to add HAL > volume/device UDI per file to the metadata). Im quite happy to add this as metadata to tracker and even get tracker to hide stuff based on it (using hal) but it still needs to be part of the uri for a music file (otherwise we wont be able to uniquely identify the files) -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ From jamiemcc@blueyonder.co.uk Thu Jun 22 06:52:34 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 93DEE3B031A for ; Thu, 22 Jun 2006 06:52:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17877-10 for ; Thu, 22 Jun 2006 06:52:32 -0400 (EDT) Received: from smtp-out5.blueyonder.co.uk (smtp-out5.blueyonder.co.uk [195.188.213.8]) by menubar.gnome.org (Postfix) with ESMTP id 66C8B3B0262 for ; Thu, 22 Jun 2006 06:52:32 -0400 (EDT) Received: from [172.23.170.140] (helo=anti-virus02-07) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1FtMnX-0007Tp-4T; Thu, 22 Jun 2006 11:52:31 +0100 Received: from [62.30.198.187] (helo=[62.30.198.187]) by asmtp-out1.blueyonder.co.uk with esmtpa (Exim 4.52) id 1FtMnU-0001TX-7r; Thu, 22 Jun 2006 11:52:28 +0100 Message-ID: <449A7676.6060309@blueyonder.co.uk> Date: Thu, 22 Jun 2006 11:52:38 +0100 From: Jamie McCracken User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Milosz Derezynski Subject: Re: MLQ (Media Library Query) file format and mime type proposal References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.422 tagged_above=-999 required=2 tests=[AWL=0.101, BAYES_00=-2.599, SPF_PASS=-0.001, TW_RQ=0.077] X-Spam-Score: -2.422 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 10:52:34 -0000 Milosz Derezynski wrote: > Hi, > > I'm one of the main authors of BMP 2 (still being worked on), and along > the way of reworking our library, i came across the idea of encoding > library queries as URIs, which may look like this: > > "query:///?artist=Air&album=Moon%20Safari" > > BMP 2 has a plugin archicture which is a small VFS on it's own, and we > treat certain things as "containers" (i.e. they "contain" URIs, like PLS > playlists, XSPF, M3U, etc). > Now i thought it might be not a bad idea to create a playlist format > with these query URLs, and i've called it "MLQ" for media library query. > In theory, it's not even > application specific. The keys (identifiers), like artist, album, etc, > are all based on GStreamer tag identifiers. (They could be maybe adapted > to http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , > but it seems insufficient and doesn't specify certain items, like > musicbrainz metadata, which GST does). Tracker's metadata spec does (http://freedesktop.org/wiki/Standards/shared-filemetadata-spec) > > So i've called this file format "MLQ", with the extension .mlq, created > a mime package file for it: > > > > > Media Library Query List > > > > > > > > Adding a file of this type to BMPx, or just a plain query:/// URI itself > causes a library query and appending of the relevant items to the > tracklist (BMP is currently mostly based on the concept of a mutable > playlist to which items can be added from various sources, unlike e.g. > RB which has mostly immutable "Playlists", but allows for custom queues). > > Another example is: > > query:///?artist=Air&album=Moon%20Safari&title=La%20Femme%20d'Argent > query:///?artist=Air&album=Moon%20Safari&title=Sexy%20Boy > query:///?artist=Air&album=Moon%20Safari&title=All%20I%20Need > query:///?artist=Air&album=Moon%20Safari&title=Kelly,%20Watch%20The%20Stars! > query:///?artist=Air&album=Moon%20Safari&title=Talisman > query:///?artist=Air&album=Moon%20Safari&title=Remember > query:///?artist=Air&album=Moon%20Safari&title=You%20Make%20It%20Easy > query:///?artist=Air&album=Moon%20Safari&title=Ce%20Matin%20La > query:///?artist=Air&album=Moon%20Safari&title=New%20Star%20In%20The%20Sky > query:///?artist=Air&album=Moon%20Safari&title=Le%20Voyage%20De%20Penelope > > Or it might just be: > > query:///?genre=Jazz > > Since this is very common, and having the discussions about a common > music database in mind, this seems like a useful proposal, since it is > not player specific. > This ships currently with BMP 2/BMPx SVN, and while i will ship this > with the 0.20 release (end-July) anyway, what does everyone think of > this in a broader context (common music database, etc)? Could be interesting as an alternative to rdf query that tracker uses but rdf query is a *standard* and is the WC3's recommended means of querying metadata. A more compact version of the xml based rdf query language is sparql (http://www.w3.org/TR/rdf-sparql-query/) and is also a candidate for standardisation. I guess its going to be fun deciding which to use (I will go with the flow) -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ From doclivingston@gmail.com Thu Jun 22 07:00:08 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 966243B038B for ; Thu, 22 Jun 2006 07:00:08 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18372-10 for ; Thu, 22 Jun 2006 07:00:05 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by menubar.gnome.org (Postfix) with ESMTP id 2DC8B3B00ED for ; Thu, 22 Jun 2006 07:00:05 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id f25so276546pyf for ; Thu, 22 Jun 2006 04:00:04 -0700 (PDT) Received: by 10.35.91.15 with SMTP id t15mr948347pyl; Thu, 22 Jun 2006 04:00:04 -0700 (PDT) Received: from alyrion.local ( [144.139.19.209]) by mx.gmail.com with ESMTP id w28sm110735pyc.2006.06.22.04.00.02; Thu, 22 Jun 2006 04:00:04 -0700 (PDT) Subject: Re: MLQ: Followup From: "James \"Doc\" Livingston" To: gnome-multimedia@gnome.org In-Reply-To: References: Content-Type: text/plain Date: Thu, 22 Jun 2006 20:59:59 +1000 Message-Id: <1150973999.5186.17.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.317 tagged_above=-999 required=2 tests=[AWL=0.283, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.317 X-Spam-Level: X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: doclivingston@gmail.com List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 11:00:08 -0000 On Thu, 2006-06-22 at 11:32 +0200, Milosz Derezynski wrote: > One benefit of MLQs over 'regular' playlists at least with BMP 2 is > that i've introduced a concept of keeping track of tracks across mount > point changes which basically works like this: > So the benefit of an MLQ is that unlike a static playlist, you can be > rather sure that no matter where you really move the music, BMP will > always be able to find it. I'm a bit confused about how "HAL UDI + partial path" is related to the MLQ idea. To me they seem fairly orthogonal. However using HAL UDIs is a good idea. Most apps currently use the URI as it's unique identifier and the method of finding the actual file, we could decide that the common db would use a as the unique id/location method. > Downsides/doesn't-works: > - There is no volume UDI available If this is a permanent thing, e.g. a non-HAL system or a http:// resource, then we could say that a null UDI and the full uri would be used instead. If it's temporary, e.g. HAL isn't running, or isn't detecting the device properly, then it's probably more complicated. Dealing with the fact that the users music is stored as and we don't know the URI would be funky. Perhaps we could say all db entries have the field, and a "last known"/non-HAL location field. > - You make a regular 'move' (mv), and not just a remount That is different again, and is probably best solved with audio fingerprinting, and/or embedding unique metadata in the file. Cheers. James "Doc" Livingston -- If USENET is anarchy, IRC is a paranoid schizophrenic after 6 days on speed. -- Chris "Saundo" Saunderson in asr. From doclivingston@gmail.com Thu Jun 22 07:04:28 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CFF783B0254 for ; Thu, 22 Jun 2006 07:04:28 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18854-05 for ; Thu, 22 Jun 2006 07:04:27 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by menubar.gnome.org (Postfix) with ESMTP id 0309C3B05B2 for ; Thu, 22 Jun 2006 07:04:26 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id f28so267516pyf for ; Thu, 22 Jun 2006 04:04:26 -0700 (PDT) Received: by 10.35.82.15 with SMTP id j15mr949278pyl; Thu, 22 Jun 2006 04:04:26 -0700 (PDT) Received: from alyrion.local ( [144.139.19.209]) by mx.gmail.com with ESMTP id w66sm860753pyw.2006.06.22.04.04.24; Thu, 22 Jun 2006 04:04:26 -0700 (PDT) Subject: Re: MLQ (Media Library Query) file format and mime type proposal From: "James \"Doc\" Livingston" To: gnome-multimedia@gnome.org In-Reply-To: References: Content-Type: text/plain Date: Thu, 22 Jun 2006 21:04:21 +1000 Message-Id: <1150974261.5186.22.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.319 tagged_above=-999 required=2 tests=[AWL=0.281, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.319 X-Spam-Level: X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: doclivingston@gmail.com List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 11:04:29 -0000 On Thu, 2006-06-22 at 11:25 +0200, Milosz Derezynski wrote: > I'm one of the main authors of BMP 2 (still being worked on), and > along the way of reworking our library, i came across the idea of > encoding library queries as URIs, which may look like this: > > "query:///?artist=Air&album=Moon%20Safari" > Adding a file of this type to BMPx, or just a plain query:/// URI > itself causes a library query and appending of the relevant items to > the tracklist (BMP is currently mostly based on the concept of a > mutable playlist to which items can be added from various sources, > unlike e.g. RB which has mostly immutable "Playlists", but allows for > custom queues). I'm a bit confused as to what this is actually for. Is it meant for saving "smart playlist"-type (or other db queries) things to disk? If so, it's probably better to use one of the existing query formats. If we want to use XML, then RDF (which is what Tracker uses for all it's queries) is probably as good as anything. James "Doc" Livingston -- "The Web brings people together because no matter what kind of a twisted sexual mutant you happen to be, you've got millions of pals out there. Type in 'Find people that have sex with goats that are on fire' and the computer will ask, 'Specify type of goat.'" -- Rich Jeni From internalerror@gmail.com Thu Jun 22 07:35:27 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BBE833B064F for ; Thu, 22 Jun 2006 07:35:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20711-02 for ; Thu, 22 Jun 2006 07:35:26 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.197]) by menubar.gnome.org (Postfix) with ESMTP id 1F4E83B0528 for ; Thu, 22 Jun 2006 07:35:26 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so334141wxc for ; Thu, 22 Jun 2006 04:35:26 -0700 (PDT) Received: by 10.70.65.10 with SMTP id n10mr2935604wxa; Thu, 22 Jun 2006 04:35:25 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 04:35:25 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 13:35:25 +0200 From: "Milosz Derezynski" To: doclivingston@gmail.com Subject: Re: MLQ: Followup In-Reply-To: <1150973999.5186.17.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3961_29338319.1150976125920" References: <1150973999.5186.17.camel@localhost.localdomain> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.246 tagged_above=-999 required=2 tests=[AWL=0.353, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.246 X-Spam-Level: Cc: gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 11:35:27 -0000 ------=_Part_3961_29338319.1150976125920 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/22/06, James Doc Livingston wrote: If it's temporary, e.g. HAL isn't running, or isn't detecting the device > properly, then it's probably more complicated. Dealing with the fact > that the users music is stored as and we don't know the URI > would be funky. Perhaps we could say all db entries have the > field, and a "last known"/non-HAL location field. > That's what i'm currently doing, i store the full URI, but also the UDI and the partial path, and in case HAL is not avaiable there is still the full URI present as a current resort. The ideal situation would be that HAL would be always available, would have UDIs for all volumes, and would run on all systems we need to run this to (Including let's say Solaris, etc), in which case it would be exactly what you said, one would need to only store the volume UDI and the partial path. Well anyway, repeating myself, just wanted to add that we also already store the full URI as a backup. ------=_Part_3961_29338319.1150976125920 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 6/22/06, James Doc Livingston <doclivingston@gmail.com> wrote:

If it's temporary, e.g. HAL isn't running, or isn't detecting the device
properly, then it's probably more complicated. Dealing with the fact
that the users music is stored as <UDI, path> and we don't know the URI
would be funky. Perhaps we could say all db entries have the <UDI, path>
field, and a "last known"/non-HAL location field.


That's what i'm currently doing, i store the full URI, but also the UDI and the partial path,
and in case HAL is not avaiable there is still the full URI present as a current resort.

The ideal situation would be that HAL would be always available, would have UDIs for all
volumes, and would run on all systems we need to run this to (Including let's say Solaris,
etc), in which case it would be exactly what you said, one would need to only store the volume
UDI and the partial path. Well anyway, repeating myself, just wanted to add that we also
already store the full URI as a backup.
------=_Part_3961_29338319.1150976125920-- From internalerror@gmail.com Thu Jun 22 12:04:05 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 802573B0830 for ; Thu, 22 Jun 2006 12:04:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07916-06 for ; Thu, 22 Jun 2006 12:04:01 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.201]) by menubar.gnome.org (Postfix) with ESMTP id 35C833B083F for ; Thu, 22 Jun 2006 12:01:33 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so373874wxc for ; Thu, 22 Jun 2006 09:01:32 -0700 (PDT) Received: by 10.70.83.20 with SMTP id g20mr3337015wxb; Thu, 22 Jun 2006 09:01:32 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 09:01:32 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 18:01:32 +0200 From: "Milosz Derezynski" To: "Frans Englich" Subject: Re: MLQ (Media Library Query) file format and mime type proposal In-Reply-To: <200606221419.00204.frans.englich@telia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7583_10781705.1150992092417" References: <200606221419.00204.frans.englich@telia.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.073 tagged_above=-999 required=2 tests=[AWL=0.152, BAYES_00=-2.599, HTML_30_40=0.374, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.073 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 16:04:05 -0000 ------=_Part_7583_10781705.1150992092417 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/22/06, Frans Englich wrote: > > On Thursday 22 June 2006 09:25, Milosz Derezynski wrote: > > Hi, > > > > I'm one of the main authors of BMP 2 (still being worked on), and along > the > > way of reworking our library, i came across the idea of encoding library > > queries as URIs, which may look like this: > > > > "query:///?artist=Air&album=Moon%20Safari" > > (Is that at all a valid URI? I'm not sure.) I think it is valid yes. First of all, one can't simply invent ones own URI scheme, because it causes > trouble. Especially, for such a generic name as "query". This document > discusses this further: > > http://developer.kde.org/policies/uri-guidelines.xhtml > > How is interoperability for "query" ensured? Is it specified? Not at all yet but because of that i'm asking on those 2 lists here now (xdg and gnome-multimedia), and furthermore i made some interoperability proposals, just 2 totally off my head but not totally out of place either. > BMP 2 has a plugin archicture which is a small VFS on it's own, and we > > treat certain things as "containers" (i.e. they "contain" URIs, like PLS > > playlists, XSPF, M3U, etc). > > Now i thought it might be not a bad idea to create a playlist format > with > > these query URLs, and i've called it "MLQ" for media library query. In > > theory, it's not even > > application specific. The keys (identifiers), like artist, album, etc, > are > > all based on GStreamer tag identifiers. (They could be maybe adapted to > > http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , > but > > it seems insufficient and doesn't specify certain items, like > musicbrainz > > metadata, which GST does). > > > > So i've called this file format "MLQ", with the extension .mlq, created > a > > mime package file for it: > > I think this highlights possible trouble. Anyone else who decides to > invent "query" will get detected as "Media Library Query List". All that's > needed to fix this is to use URIs properly. Yeah well that is problematic for them haha :P > However, I wouldn't invent a new URI scheme for this, it's too context > dependent. Music players & hardware(ipods, music players, music sharing > sites, and so on) is quite popular in western societies right now, but > next > year it's something different. Technologies, such as a URI scheme, > shouldn't > be hard coded on a specific use, it should be generic. > > Re-use existing technologies. There's plenty of work and research on meta > data > and querying data. Here's my suggestions: > > Express the format in XML. This has nothing to do with XML files("text"), > unless one wants to. It means the format is conceptually, on an "abstract" > level, described in XML which in turn opens up the door for all methods > XML > has. > > For example, one could use an XPointer fragment with an XPath scheme: > > file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album > = 'Safari')) > > If "music collections" cannot be located as files, invent a scheme which > can > identify them on this "abstract level." That is actually a very good idea (to use an XPath), but then again i would be abusing the file:/// scheme. What should it point to? Even if it would point to the physical location of the database file, in my specific case this would be ~/.local/share/bmpx/library.mlib, so file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz and @album='Safari')), then i would be basically still "making something up", as you cannot pass THIS uri to, say, a filemanager, and it would recognize it and do the correct thing. Now of course it won't recognize query:/// either, but i made 2 proposals which would spec query:/// in this way system wide. What i'm up to is that while your proposal with file seems more sane (and XPath/XPointer is certainly better than using a GET string, i might really consider changing the query:/// URI to use that), it actually is no different. Those kinds of file:/// URIs would need special treatment as well, and in fact, would cause even more headache possibly, as file:/// _IS_ already a known scheme which is already specced etc, etd. However, I would first assess RDF as suggested in this thread, since it is > designed exactly for things like this. Well RDF possibly, but i think i will never in my life use SPARQL. I took a look at it and i want these things if not neccessarily, then at least possibly, human editable, buit SPARQL is just way beyond the comprehension of taking a quick glance at the file and making some corrections. > > Cheers, > > Frans > -- Milosz ------=_Part_7583_10781705.1150992092417 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 6/22/06, Frans Englich <frans.englich@telia.com> wrote:
On Thursday 22 June 2006 09:25, Milosz Derezynski wrote:
> Hi,
>
> I'm one of the main authors of BMP 2 (still being worked on), and along the
> way of reworking our library, i came across the idea of encoding library
> queries as URIs, which may look like this:
>
> "query:///?artist=Air&album=Moon%20Safari"

(Is that at all a valid URI? I'm not sure.)

I think it is valid yes.

First of all, one can't simply invent ones own URI scheme, because it causes
trouble. Especially, for such a generic name as "query". This document
discusses this further:

http://developer.kde.org/policies/uri-guidelines.xhtml

How is interoperability for "query" ensured? Is it specified?

Not at all yet but  because of that i'm asking on those 2 lists here now (xdg
and gnome-multimedia), and furthermore i made some interoperability
proposals, just 2 totally off my head but not totally out of place either.
 

> BMP 2 has a plugin archicture which is a small VFS on it's own, and we
> treat certain things as "containers" (i.e. they "contain" URIs, like PLS
> playlists, XSPF, M3U, etc).
> Now i thought it might be not a bad idea to create a playlist format with
> these query URLs, and i've called it "MLQ" for media library query. In
> theory, it's not even
> application specific. The keys (identifiers), like artist, album, etc, are
> all based on GStreamer tag identifiers. (They could be maybe adapted to
> http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but
> it seems insufficient and doesn't specify certain items, like musicbrainz
> metadata, which GST does).
>
> So i've called this file format "MLQ", with the extension .mlq, created a
> mime package file for it:

I think this highlights possible trouble. Anyone else who decides to
invent "query" will get detected as "Media Library Query List". All that's
needed to fix this is to use URIs properly.

Yeah well that is problematic for them haha :P
 
However, I wouldn't invent a new URI scheme for this, it's too context
dependent. Music players & hardware(ipods, music players, music sharing
sites, and so on) is quite popular in western societies right now, but next
year it's something different. Technologies, such as a URI scheme, shouldn't
be hard coded on a specific use, it should be generic.

Re-use existing technologies. There's plenty of work and research on meta data
and querying data. Here's my suggestions:

Express the format in XML. This has nothing to do with XML files("text"),
unless one wants to. It means the format is conceptually, on an "abstract"
level, described in XML which in turn opens up the door for all methods XML
has.

For example, one could use an XPointer fragment with an XPath scheme:

file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album
= 'Safari'))

If "music collections" cannot be located as files, invent a scheme which can
identify them on this "abstract level."


That is actually a very good idea (to use an XPath), but then again i would be abusing
the file:/// scheme. What should it point to? Even if it would point to the physical location
of the database file, in my specific case this would be ~/.local/share/bmpx/library.mlib,
so file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz
and @album='Safari')), then i would be basically still "making something up", as you cannot
pass THIS uri to, say, a filemanager, and it would recognize it and do the correct thing.

Now of course it won't recognize query:/// either, but i made 2 proposals which would spec
query:/// in this way system wide.

What i'm up to is that while your proposal with file seems
more sane (and XPath/XPointer is certainly better than using a GET string, i might really
consider changing the query:/// URI to use that), it actually is no different. Those kinds of
file:/// URIs would need special treatment as well, and in fact, would cause even more headache
possibly, as file:/// _IS_ already a known scheme which is already specced etc, etd.
 

However, I would first assess RDF as suggested in this thread, since it is
designed exactly for things like this.

Well RDF possibly, but i think i will never in  my life use SPARQL. I took a look at it
and i want these things if not neccessarily, then at least possibly, human editable,
buit SPARQL is just way beyond the comprehension of taking a quick glance at the
file and making some corrections.
 

Cheers,

                Frans


-- Milosz
------=_Part_7583_10781705.1150992092417-- From internalerror@gmail.com Thu Jun 22 12:13:45 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5FD223B0389 for ; Thu, 22 Jun 2006 12:13:45 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08581-05 for ; Thu, 22 Jun 2006 12:13:43 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.205]) by menubar.gnome.org (Postfix) with ESMTP id B81413B01D2 for ; Thu, 22 Jun 2006 12:13:42 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so375754wxc for ; Thu, 22 Jun 2006 09:13:42 -0700 (PDT) Received: by 10.70.18.10 with SMTP id 10mr3379733wxr; Thu, 22 Jun 2006 09:13:42 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 09:13:41 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 18:13:41 +0200 From: "Milosz Derezynski" To: "Frans Englich" Subject: Re: MLQ (Media Library Query) file format and mime type proposal In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7734_19670285.1150992821952" References: <200606221419.00204.frans.englich@telia.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.079 tagged_above=-999 required=2 tests=[AWL=0.146, BAYES_00=-2.599, HTML_30_40=0.374, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.079 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 16:13:45 -0000 ------=_Part_7734_19670285.1150992821952 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I didn't know about tag URIs though, i'm taking a look at it now, thanks. On 6/22/06, Milosz Derezynski wrote: > > > > On 6/22/06, Frans Englich wrote: > > > > On Thursday 22 June 2006 09:25, Milosz Derezynski wrote: > > > Hi, > > > > > > I'm one of the main authors of BMP 2 (still being worked on), and > > along the > > > way of reworking our library, i came across the idea of encoding > > library > > > queries as URIs, which may look like this: > > > > > > "query:///?artist=Air&album=Moon%20Safari" > > > > (Is that at all a valid URI? I'm not sure.) > > > I think it is valid yes. > > First of all, one can't simply invent ones own URI scheme, because it > > causes > > trouble. Especially, for such a generic name as "query". This document > > discusses this further: > > > > http://developer.kde.org/policies/uri-guidelines.xhtml > > > > How is interoperability for "query" ensured? Is it specified? > > > Not at all yet but because of that i'm asking on those 2 lists here now > (xdg > and gnome-multimedia), and furthermore i made some interoperability > proposals, just 2 totally off my head but not totally out of place either. > > > > BMP 2 has a plugin archicture which is a small VFS on it's own, and we > > > treat certain things as "containers" (i.e. they "contain" URIs, like > > PLS > > > playlists, XSPF, M3U, etc). > > > Now i thought it might be not a bad idea to create a playlist format > > with > > > these query URLs, and i've called it "MLQ" for media library query. In > > > theory, it's not even > > > application specific. The keys (identifiers), like artist, album, etc, > > are > > > all based on GStreamer tag identifiers. (They could be maybe adapted > > to > > > http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , > > but > > > it seems insufficient and doesn't specify certain items, like > > musicbrainz > > > metadata, which GST does). > > > > > > So i've called this file format "MLQ", with the extension .mlq, > > created a > > > mime package file for it: > > > > I think this highlights possible trouble. Anyone else who decides to > > invent "query" will get detected as "Media Library Query List". All > > that's > > needed to fix this is to use URIs properly. > > > Yeah well that is problematic for them haha :P > > > > However, I wouldn't invent a new URI scheme for this, it's too context > > dependent. Music players & hardware(ipods, music players, music sharing > > sites, and so on) is quite popular in western societies right now, but > > next > > year it's something different. Technologies, such as a URI scheme, > > shouldn't > > be hard coded on a specific use, it should be generic. > > > > Re-use existing technologies. There's plenty of work and research on > > meta data > > and querying data. Here's my suggestions: > > > > Express the format in XML. This has nothing to do with XML > > files("text"), > > unless one wants to. It means the format is conceptually, on an > > "abstract" > > level, described in XML which in turn opens up the door for all methods > > XML > > has. > > > > For example, one could use an XPointer fragment with an XPath scheme: > > > > file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album > > = 'Safari')) > > > > If "music collections" cannot be located as files, invent a scheme which > > can > > identify them on this "abstract level." > > > > That is actually a very good idea (to use an XPath), but then again i > would be abusing > the file:/// scheme. What should it point to? Even if it would point to > the physical location > of the database file, in my specific case this would be > ~/.local/share/bmpx/library.mlib, > so file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz > > and @album='Safari')), then i would be basically still "making something > up", as you cannot > pass THIS uri to, say, a filemanager, and it would recognize it and do the > correct thing. > > Now of course it won't recognize query:/// either, but i made 2 proposals > which would spec > query:/// in this way system wide. > > What i'm up to is that while your proposal with file seems > more sane (and XPath/XPointer is certainly better than using a GET string, > i might really > consider changing the query:/// URI to use that), it actually is no > different. Those kinds of > file:/// URIs would need special treatment as well, and in fact, would > cause even more headache > possibly, as file:/// _IS_ already a known scheme which is already specced > etc, etd. > > > However, I would first assess RDF as suggested in this thread, since it is > > designed exactly for things like this. > > > Well RDF possibly, but i think i will never in my life use SPARQL. I took > a look at it > and i want these things if not neccessarily, then at least possibly, human > editable, > buit SPARQL is just way beyond the comprehension of taking a quick glance > at the > file and making some corrections. > > > > > > Cheers, > > > > Frans > > > > > -- Milosz > ------=_Part_7734_19670285.1150992821952 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I didn't know about tag URIs though, i'm taking a look at it now, thanks.

On 6/22/06, Milosz Derezynski <internalerror@gmail.com > wrote:


On 6/22/06, Frans Englich <frans.englich@telia.com> wrote:
On Thursday 22 June 2006 09:25, Milosz Derezynski wrote:
> Hi,
>
> I'm one of the main authors of BMP 2 (still being worked on), and along the
> way of reworking our library, i came across the idea of encoding library
> queries as URIs, which may look like this:
>
> "query:///?artist=Air&album=Moon%20Safari"

(Is that at all a valid URI? I'm not sure.)

I think it is valid yes.

First of all, one can't simply invent ones own URI scheme, because it causes
trouble. Especially, for such a generic name as "query". This document
discusses this further:

http://developer.kde.org/policies/uri-guidelines.xhtml

How is interoperability for "query" ensured? Is it specified?

Not at all yet but  because of that i'm asking on those 2 lists here now (xdg
and gnome-multimedia), and furthermore i made some interoperability
proposals, just 2 totally off my head but not totally out of place either.
 

> BMP 2 has a plugin archicture which is a small VFS on it's own, and we
> treat certain things as "containers" (i.e. they "contain" URIs, like PLS
> playlists, XSPF, M3U, etc).
> Now i thought it might be not a bad idea to create a playlist format with
> these query URLs, and i've called it "MLQ" for media library query. In
> theory, it's not even
> application specific. The keys (identifiers), like artist, album, etc, are
> all based on GStreamer tag identifiers. (They could be maybe adapted to
> http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but
> it seems insufficient and doesn't specify certain items, like musicbrainz
> metadata, which GST does).
>
> So i've called this file format "MLQ", with the extension .mlq, created a
> mime package file for it:

I think this highlights possible trouble. Anyone else who decides to
invent "query" will get detected as "Media Library Query List". All that's
needed to fix this is to use URIs properly.

Yeah well that is problematic for them haha :P
 
However, I wouldn't invent a new URI scheme for this, it's too context
dependent. Music players & hardware(ipods, music players, music sharing
sites, and so on) is quite popular in western societies right now, but next
year it's something different. Technologies, such as a URI scheme, shouldn't
be hard coded on a specific use, it should be generic.

Re-use existing technologies. There's plenty of work and research on meta data
and querying data. Here's my suggestions:

Express the format in XML. This has nothing to do with XML files("text"),
unless one wants to. It means the format is conceptually, on an "abstract"
level, described in XML which in turn opens up the door for all methods XML
has.

For example, one could use an XPointer fragment with an XPath scheme:

file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album
= 'Safari'))

If "music collections" cannot be located as files, invent a scheme which can
identify them on this "abstract level."


That is actually a very good idea (to use an XPath), but then again i would be abusing
the file:/// scheme. What should it point to? Even if it would point to the physical location
of the database file, in my specific case this would be ~/.local/share/bmpx/library.mlib,
so file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz
and @album='Safari')), then i would be basically still "making something up", as you cannot
pass THIS uri to, say, a filemanager, and it would recognize it and do the correct thing.

Now of course it won't recognize query:/// either, but i made 2 proposals which would spec
query:/// in this way system wide.

What i'm up to is that while your proposal with file seems
more sane (and XPath/XPointer is certainly better than using a GET string, i might really
consider changing the query:/// URI to use that), it actually is no different. Those kinds of
file:/// URIs would need special treatment as well, and in fact, would cause even more headache
possibly, as file:/// _IS_ already a known scheme which is already specced etc, etd.
 

However, I would first assess RDF as suggested in this thread, since it is
designed exactly for things like this.

Well RDF possibly, but i think i will never in  my life use SPARQL. I took a look at it
and i want these things if not neccessarily, then at least possibly, human editable,
buit SPARQL is just way beyond the comprehension of taking a quick glance at the
file and making some corrections.
 

Cheers,

                Frans


-- Milosz

------=_Part_7734_19670285.1150992821952-- From frans.englich@telia.com Thu Jun 22 10:05:56 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 164263B085B for ; Thu, 22 Jun 2006 10:05:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00797-01 for ; Thu, 22 Jun 2006 10:05:48 -0400 (EDT) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by menubar.gnome.org (Postfix) with ESMTP id 4FFD63B081B for ; Thu, 22 Jun 2006 10:05:38 -0400 (EDT) X-T2-Posting-ID: 2yF4ydxc0UI9xI7FHZPfog== X-Cloudmark-Score: 0.000000 [] Received: from 83.72.134.122.ip.tele2adsl.dk ([83.72.134.122] verified) by mailfe08.swip.net (CommuniGate Pro SMTP 5.0.8) with ESMTP id 217821068; Thu, 22 Jun 2006 16:05:36 +0200 From: Frans Englich To: xdg@lists.freedesktop.org Subject: Re: MLQ (Media Library Query) file format and mime type proposal Date: Thu, 22 Jun 2006 14:18:59 +0000 User-Agent: KMail/1.8.50 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606221419.00204.frans.englich@telia.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.051 tagged_above=-999 required=2 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_NUMERIC_HELO=1.5] X-Spam-Score: -1.051 X-Spam-Level: X-Mailman-Approved-At: Thu, 22 Jun 2006 12:45:56 -0400 Cc: gnome-multimedia@gnome.org, Milosz Derezynski X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 14:05:56 -0000 On Thursday 22 June 2006 09:25, Milosz Derezynski wrote: > Hi, > > I'm one of the main authors of BMP 2 (still being worked on), and along the > way of reworking our library, i came across the idea of encoding library > queries as URIs, which may look like this: > > "query:///?artist=Air&album=Moon%20Safari" (Is that at all a valid URI? I'm not sure.) First of all, one can't simply invent ones own URI scheme, because it causes trouble. Especially, for such a generic name as "query". This document discusses this further: http://developer.kde.org/policies/uri-guidelines.xhtml How is interoperability for "query" ensured? Is it specified? > BMP 2 has a plugin archicture which is a small VFS on it's own, and we > treat certain things as "containers" (i.e. they "contain" URIs, like PLS > playlists, XSPF, M3U, etc). > Now i thought it might be not a bad idea to create a playlist format with > these query URLs, and i've called it "MLQ" for media library query. In > theory, it's not even > application specific. The keys (identifiers), like artist, album, etc, are > all based on GStreamer tag identifiers. (They could be maybe adapted to > http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but > it seems insufficient and doesn't specify certain items, like musicbrainz > metadata, which GST does). > > So i've called this file format "MLQ", with the extension .mlq, created a > mime package file for it: I think this highlights possible trouble. Anyone else who decides to invent "query" will get detected as "Media Library Query List". All that's needed to fix this is to use URIs properly. However, I wouldn't invent a new URI scheme for this, it's too context dependent. Music players & hardware(ipods, music players, music sharing sites, and so on) is quite popular in western societies right now, but next year it's something different. Technologies, such as a URI scheme, shouldn't be hard coded on a specific use, it should be generic. Re-use existing technologies. There's plenty of work and research on meta data and querying data. Here's my suggestions: Express the format in XML. This has nothing to do with XML files("text"), unless one wants to. It means the format is conceptually, on an "abstract" level, described in XML which in turn opens up the door for all methods XML has. For example, one could use an XPointer fragment with an XPath scheme: file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album = 'Safari')) If "music collections" cannot be located as files, invent a scheme which can identify them on this "abstract level." However, I would first assess RDF as suggested in this thread, since it is designed exactly for things like this. In this way one doesn't have to invent a whole query language for music files. That's like inventing C++ for writing games, C++ for fixing bugs in word processors, C++ for writing editors, and so on. Cheers, Frans From internalerror@gmail.com Thu Jun 22 13:17:35 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 614C33B0693 for ; Thu, 22 Jun 2006 13:17:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12677-02 for ; Thu, 22 Jun 2006 13:17:34 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.201]) by menubar.gnome.org (Postfix) with ESMTP id 0CBD83B06C8 for ; Thu, 22 Jun 2006 13:17:33 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so385228wxc for ; Thu, 22 Jun 2006 10:17:33 -0700 (PDT) Received: by 10.70.110.18 with SMTP id i18mr3484207wxc; Thu, 22 Jun 2006 10:17:33 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 10:17:33 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 19:17:33 +0200 From: "Milosz Derezynski" To: "Frans Englich" Subject: Re: MLQ (Media Library Query) file format and mime type proposal In-Reply-To: <200606221419.00204.frans.englich@telia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8538_10618378.1150996653355" References: <200606221419.00204.frans.englich@telia.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.272 tagged_above=-999 required=2 tests=[AWL=0.327, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.272 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 17:17:35 -0000 ------=_Part_8538_10618378.1150996653355 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/22/06, Frans Englich wrote: > > On Thursday 22 June 2006 09:25, Milosz Derezynski wrote: > > I think this highlights possible trouble. Anyone else who decides to > invent "query" will get detected as "Media Library Query List". All that's > needed to fix this is to use URIs properly. > I've changed the file magic so that the first line has to be "#MLQ", and our MLQ exporter writes them like that and recognizes them only like that, and i've updated the mime XML spec to recognize them this way. This is no better or worse than "#EXTM3U" for .m3u playlists, so i don't think there is any problem here now. As for the URIs themselves, i wasn't yet speaking of "open" use of them (outside of .mlq files), but only within them, so this change of the file magic should prevent problems with anything else that might use a query:/// URI in their file formats. -- Milosz ------=_Part_8538_10618378.1150996653355 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 6/22/06, Frans Englich <frans.englich@telia.com> wrote:
On Thursday 22 June 2006 09:25, Milosz Derezynski wrote:

I think this highlights possible trouble. Anyone else who decides to
invent "query" will get detected as "Media Library Query List". All that's
needed to fix this is to use URIs properly.

I've changed the file magic so that the first line has to be "#MLQ", and our
MLQ exporter writes them like that and recognizes them only like that, and i've
updated the mime XML spec to recognize them this way.  This is no better or worse than
"#EXTM3U" for .m3u playlists, so i don't think there is any problem here now.
As for the URIs themselves, i wasn't yet speaking of "open" use of them (outside of .mlq files),
but only within them, so this change of the file magic should prevent problems with
anything else that might use a query:/// URI in their file formats.

-- Milosz
------=_Part_8538_10618378.1150996653355-- From doclivingston@gmail.com Wed Jun 7 10:49:16 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6DFBE3B0CC1 for ; Wed, 7 Jun 2006 10:49:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21939-01 for ; Wed, 7 Jun 2006 10:49:15 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.229]) by menubar.gnome.org (Postfix) with ESMTP id D14723B03C1 for ; Wed, 7 Jun 2006 10:49:14 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id 50so195010wri for ; Wed, 07 Jun 2006 07:49:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:reply-to:to:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=D3/oYUbzoxrxaC8A9PmKhslTLvhndfLfj1yY1UbjWdxPLOVTGGtYcu0ciGotAkdC9rpqkdcPnVZMxJ6dpbOroKn3+pabYkPihqGfxJAljTjii14F9PbbIilMLHmiNyw9SX693UyHiryeZOKfQoct7i10NaO3a8zimwOM5qcjmis= Received: by 10.65.232.13 with SMTP id j13mr502626qbr; Wed, 07 Jun 2006 07:49:14 -0700 (PDT) Received: from alyrion.local ( [144.139.19.99]) by mx.gmail.com with ESMTP id e14sm242982qba.2006.06.07.07.49.12; Wed, 07 Jun 2006 07:49:14 -0700 (PDT) From: "James \"Doc\" Livingston" To: gnome-multimedia@gnome.org Content-Type: text/plain Date: Thu, 08 Jun 2006 00:49:05 +1000 Message-Id: <1149691745.5417.19.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.309 tagged_above=-999 required=2 tests=[AWL=0.291, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.309 X-Spam-Level: Subject: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: doclivingston@gmail.com List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 14:49:16 -0000 G'day everyone, Currently various multi-media application behave differently when the "scrolling" (up/down arrow, page up/down mouse wheel) actions are performed on their seek slider. There have been bugs (at least 164351 and 330570) filed against several applications asking that they behave like others, and it would be good to have consistent behaviour. Essentially the questions is what should happen when the user performs these actions? Should the "up" actions seek forward in time, seek back in time, or do nothing? Currently Totem and Gnome Sound Recorder map "up" to seek forwards in time, Sound-Juicer and Rhythmbox map "up" to seek back in time, and Banshee and Muine don't seek when the user does this. Which is correct is a matter of debate, and when I started a discussion about this on #gnome-hackers (which obviously isn't filled with "average users") a while back, people seemed to be split roughly equally between the options. Some of the point for up=forwards are: * people associate up with increasing the time from the start Some of the point for up=backwards are: * people associate up with increasing the time remaining (only applicable if it's shown to the user) * people associate up with "going towards the start", like for documents/web pages Some of the point for taking no action: * these are "vertical" scroll events and the slider is horizontal, so should do nothing Regardless of which is generally considered "best", I think having it consistent between application is important. Cheers, James "Doc" Livingston -- [Request for the names of the kings who became Nazgul] Dashur, Daensir, Prantsur, Vicksinn, Comuet, Cupuid, Dondor, Blitsun, and Rodulf, Witch-King of Angmar. -- Joseph Michael Bay From hadess@hadess.net Wed Jun 7 10:58:17 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 067753B0272 for ; Wed, 7 Jun 2006 10:58:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22613-04 for ; Wed, 7 Jun 2006 10:58:16 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id EA5A23B03C4 for ; Wed, 7 Jun 2006 10:58:15 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57EwBfm003839; Wed, 7 Jun 2006 10:58:11 -0400 Received: from pobox.surrey.redhat.com (pobox.surrey.redhat.com [172.16.10.17]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57EwASg001552; Wed, 7 Jun 2006 10:58:10 -0400 Received: from bnocera.surrey.redhat.com (bnocera.surrey.redhat.com [172.16.10.53]) by pobox.surrey.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57Ew9om000601; Wed, 7 Jun 2006 15:58:09 +0100 From: Bastien Nocera To: doclivingston@gmail.com In-Reply-To: <1149691745.5417.19.camel@localhost.localdomain> References: <1149691745.5417.19.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8 Date: Wed, 07 Jun 2006 15:58:09 +0100 Message-Id: <1149692289.14668.24.camel@bnocera.surrey.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-27) Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.954 tagged_above=-999 required=2 tests=[AWL=-0.496, BAYES_00=-2.599, SPF_FAIL=1.142, SPF_HELO_PASS=-0.001] X-Spam-Score: -1.954 X-Spam-Level: Cc: gnome-multimedia@gnome.org Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 14:58:17 -0000 On Thu, 2006-06-08 at 00:49 +1000, James "Doc" Livingston wrote: > G'day everyone, > Essentially the questions is what should happen when the user performs > these actions? Should the "up" actions seek forward in time, seek back > in time, or do nothing? Same problem for the volume sliders by default. Obviously, I think that apps should seek forward in time with up, and backwards with down. And I also think that when scrolling down, the step should be shorter than when moving forward (because it makes it easier to find precise points in the timeline). Maybe we need to move things like the volume widget, and some "seek sliders" to a library like gnome-media? -- Bastien Nocera If I'm not challenged, I can do nothing. Maybe my next film will be in Japanese. -- Alejandro González Iñárittu From abockover@novell.com Wed Jun 7 11:08:04 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C6EB33B022D for ; Wed, 7 Jun 2006 11:08:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23164-09 for ; Wed, 7 Jun 2006 11:08:04 -0400 (EDT) Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.25.9.101]) by menubar.gnome.org (Postfix) with ESMTP id B3F5E3B0127 for ; Wed, 7 Jun 2006 11:08:03 -0400 (EDT) Received: from [192.168.0.101] (cpe-024-162-230-116.nc.res.rr.com [24.162.230.116]) by ms-smtp-02.southeast.rr.com (8.13.6/8.13.6) with ESMTP id k57F7xLC012187; Wed, 7 Jun 2006 11:07:59 -0400 (EDT) From: Aaron Bockover To: doclivingston@gmail.com In-Reply-To: <1149691745.5417.19.camel@localhost.localdomain> References: <1149691745.5417.19.camel@localhost.localdomain> Content-Type: text/plain Date: Wed, 07 Jun 2006 11:04:47 -0400 Message-Id: <1149692687.14205.10.camel@sledipus.rex> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.472 tagged_above=-999 required=2 tests=[AWL=-0.073, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2] X-Spam-Score: -2.472 X-Spam-Level: Cc: gnome-multimedia@gnome.org Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 15:08:05 -0000 On Thu, 2006-06-08 at 00:49 +1000, James "Doc" Livingston wrote: > Currently various multi-media application behave differently when the > "scrolling" (up/down arrow, page up/down mouse wheel) actions are > performed on their seek slider. There have been bugs (at least 164351 > and 330570) filed against several applications asking that they behave > like others, and it would be good to have consistent behaviour. Agreed. > Currently Totem and Gnome Sound Recorder map "up" to seek forwards in > time, Sound-Juicer and Rhythmbox map "up" to seek back in time, and > Banshee and Muine don't seek when the user does this. Banshee (and Muine?) seeks on CTRL+Left/Right. > Some of the point for up=forwards are: > * people associate up with increasing the time from the start > Time is usually displayed on the X axis... sliders for seeking are usually horizontal... so Up/Down keys for this mess with my mind > Some of the point for up=backwards are: > * people associate up with increasing the time remaining (only > applicable if it's shown to the user) > * people associate up with "going towards the start", like for > documents/web pages Again, for me it's more literal connection with visual objects... if I press the right arrow, I am scrolling my time graph "into the future." Volume is my Y axis. > Some of the point for taking no action: > * these are "vertical" scroll events and the slider is horizontal, so > should do nothing I don't think this is should be a no-action case. I think representations just should be "on-axis" (of course feelings are going to differ, this are just how I interpret position) >From a more technical (and possibly usability) standpoint, my objection to up/down is that it's used by and is more important to other widgets (our track views in Banshee/RB), meaning the slider needs focus for the keys to actually seek. In Banshee you can press CTRL+Left/Right anywhere and it seeks. Cheers, Aaron From rbultje@ronald.bitfreak.net Wed Jun 7 11:46:19 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3D92F3B04A2 for ; Wed, 7 Jun 2006 11:46:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26037-06 for ; Wed, 7 Jun 2006 11:46:15 -0400 (EDT) Received: from ms-smtp-01.rdc-nyc.rr.com (ms-smtp-01.rdc-nyc.rr.com [24.29.109.5]) by menubar.gnome.org (Postfix) with ESMTP id 8B1693B022D for ; Wed, 7 Jun 2006 11:46:15 -0400 (EDT) Received: from [192.168.0.103] (cpe-66-65-0-167.nyc.res.rr.com [66.65.0.167]) by ms-smtp-01.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id k57Fk2jY021579; Wed, 7 Jun 2006 11:46:13 -0400 (EDT) From: "Ronald S. Bultje" To: Bastien Nocera In-Reply-To: <1149692289.14668.24.camel@bnocera.surrey.redhat.com> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> Content-Type: text/plain Date: Wed, 07 Jun 2006 11:44:22 -0400 Message-Id: <1149695062.2855.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.561 tagged_above=-999 required=2 tests=[AWL=0.038, BAYES_00=-2.599] X-Spam-Score: -2.561 X-Spam-Level: Cc: gnome-multimedia@gnome.org Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 15:46:19 -0000 On Wed, 2006-06-07 at 15:58 +0100, Bastien Nocera wrote: > Maybe we need to move things like the volume widget, and some "seek > sliders" to a library like gnome-media? I would personally prefer libegg (or bacon, where the volume widget resides). I've never really seen gnome-media as a widget-library, but more like a bunch of applications and utilities. I totally don't mind each app making their own copy if such widgets, as long as they update their copy reasonably often. Cheers, Ronald From abockover@novell.com Wed Jun 7 11:58:56 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D43973B0411 for ; Wed, 7 Jun 2006 11:58:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26954-08 for ; Wed, 7 Jun 2006 11:58:56 -0400 (EDT) Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.25.9.101]) by menubar.gnome.org (Postfix) with ESMTP id 120B23B0D4B for ; Wed, 7 Jun 2006 11:58:56 -0400 (EDT) Received: from [192.168.0.101] (cpe-024-162-230-116.nc.res.rr.com [24.162.230.116]) by ms-smtp-02.southeast.rr.com (8.13.6/8.13.6) with ESMTP id k57FwrFL000910; Wed, 7 Jun 2006 11:58:54 -0400 (EDT) From: Aaron Bockover To: "Ronald S. Bultje" In-Reply-To: <1149695062.2855.2.camel@localhost.localdomain> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> <1149695062.2855.2.camel@localhost.localdomain> Content-Type: text/plain Date: Wed, 07 Jun 2006 11:55:41 -0400 Message-Id: <1149695742.15592.1.camel@sledipus.rex> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.473 tagged_above=-999 required=2 tests=[AWL=-0.074, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2] X-Spam-Score: -2.473 X-Spam-Level: Cc: gnome-multimedia@gnome.org, Bastien Nocera Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 15:58:57 -0000 On Wed, 2006-06-07 at 11:44 -0400, Ronald S. Bultje wrote: > On Wed, 2006-06-07 at 15:58 +0100, Bastien Nocera wrote: > > Maybe we need to move things like the volume widget, and some "seek > > sliders" to a library like gnome-media? > > I would personally prefer libegg (or bacon, where the volume widget > resides). I've never really seen gnome-media as a widget-library, but > more like a bunch of applications and utilities. > > I totally don't mind each app making their own copy if such widgets, as > long as they update their copy reasonably often. I agree here; bacon would probably be best if it were to be in a library, but I think applications providing copies is fine too. I wouldn't want to depend on bacon (or gnome-media) for a widget. --Aaron From hadess@hadess.net Wed Jun 7 12:02:02 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 001A03B0DF9 for ; Wed, 7 Jun 2006 12:02:02 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27399-05 for ; Wed, 7 Jun 2006 12:01:59 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 9822B3B0E10 for ; Wed, 7 Jun 2006 12:00:49 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57G0nE9001971; Wed, 7 Jun 2006 12:00:49 -0400 Received: from pobox.surrey.redhat.com (pobox.surrey.redhat.com [172.16.10.17]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57G0mZE021228; Wed, 7 Jun 2006 12:00:48 -0400 Received: from bnocera.surrey.redhat.com (bnocera.surrey.redhat.com [172.16.10.53]) by pobox.surrey.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57G0lTo006172; Wed, 7 Jun 2006 17:00:47 +0100 From: Bastien Nocera To: Aaron Bockover In-Reply-To: <1149695742.15592.1.camel@sledipus.rex> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> <1149695062.2855.2.camel@localhost.localdomain> <1149695742.15592.1.camel@sledipus.rex> Content-Type: text/plain Date: Wed, 07 Jun 2006 17:00:47 +0100 Message-Id: <1149696047.14668.35.camel@bnocera.surrey.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-27) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.953 tagged_above=-999 required=2 tests=[AWL=-0.495, BAYES_00=-2.599, SPF_FAIL=1.142, SPF_HELO_PASS=-0.001] X-Spam-Score: -1.953 X-Spam-Level: Cc: "Ronald S. Bultje" , gnome-multimedia@gnome.org Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 16:02:02 -0000 On Wed, 2006-06-07 at 11:55 -0400, Aaron Bockover wrote: > On Wed, 2006-06-07 at 11:44 -0400, Ronald S. Bultje wrote: > > On Wed, 2006-06-07 at 15:58 +0100, Bastien Nocera wrote: > > > Maybe we need to move things like the volume widget, and some "seek > > > sliders" to a library like gnome-media? > > > > I would personally prefer libegg (or bacon, where the volume widget > > resides). I've never really seen gnome-media as a widget-library, but > > more like a bunch of applications and utilities. > > > > I totally don't mind each app making their own copy if such widgets, as > > long as they update their copy reasonably often. > > I agree here; bacon would probably be best if it were to be in a > library, but I think applications providing copies is fine too. I > wouldn't want to depend on bacon (or gnome-media) for a widget. libbacon is a cut'n'paste library like libegg, so not a problem. -- Bastien Nocera Lucas has made a vacuous, boring, pretentious, retroactively destructive sequel. He has lost the plot. The man is a fool. -- Simon Pegg (on the Phantom Menace) From uraeus@linuxrising.org Fri Jun 9 10:13:15 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 91BCF3B01D8 for ; Fri, 9 Jun 2006 10:13:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29942-03 for ; Fri, 9 Jun 2006 10:13:14 -0400 (EDT) Received: from mx1.es6.egwn.net (server02.es6.egwn.net [195.10.6.12]) by menubar.gnome.org (Postfix) with ESMTP id E0C263B01BE for ; Fri, 9 Jun 2006 10:13:13 -0400 (EDT) Received: from [192.168.1.235] (core.fluendo.com [195.10.6.237]) by mx1.es6.egwn.net (Postfix) with ESMTP id 9E4AC4F81BC; Fri, 9 Jun 2006 16:13:11 +0200 (CEST) From: Christian Fredrik Kalager Schaller To: Bastien Nocera In-Reply-To: <1149696047.14668.35.camel@bnocera.surrey.redhat.com> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> <1149695062.2855.2.camel@localhost.localdomain> <1149695742.15592.1.camel@sledipus.rex> <1149696047.14668.35.camel@bnocera.surrey.redhat.com> Content-Type: text/plain Date: Fri, 09 Jun 2006 16:11:58 +0200 Message-Id: <1149862318.2356.36.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.397 tagged_above=-999 required=2 tests=[AWL=1.202, BAYES_00=-2.599] X-Spam-Score: -1.397 X-Spam-Level: Cc: "Ronald S. Bultje" , gnome-multimedia@gnome.org Subject: a general multimedia library - Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 14:13:15 -0000 Well the topic of having a multimedia widget library has been discussed multiple times and maybe now is the time to move on it? Currently there are multiple things I see that would be natural to put into such a library: a) the gconf schemas in gnome-media b) the playlist parser library in totem c) the seek sliders widgets mentioned here d) a simple to use GStreamer GTK+ video widget e) others things? Basically this library would/could contain things which are higher level our not directly in the scope of GStreamer. Or which is very GTK+/GNOME related. Christian On Wed, 2006-06-07 at 17:00 +0100, Bastien Nocera wrote: > On Wed, 2006-06-07 at 11:55 -0400, Aaron Bockover wrote: > > On Wed, 2006-06-07 at 11:44 -0400, Ronald S. Bultje wrote: > > > On Wed, 2006-06-07 at 15:58 +0100, Bastien Nocera wrote: > > > > Maybe we need to move things like the volume widget, and some "seek > > > > sliders" to a library like gnome-media? > > > > > > I would personally prefer libegg (or bacon, where the volume widget > > > resides). I've never really seen gnome-media as a widget-library, but > > > more like a bunch of applications and utilities. > > > > > > I totally don't mind each app making their own copy if such widgets, as > > > long as they update their copy reasonably often. > > > > I agree here; bacon would probably be best if it were to be in a > > library, but I think applications providing copies is fine too. I > > wouldn't want to depend on bacon (or gnome-media) for a widget. > > libbacon is a cut'n'paste library like libegg, so not a problem. > From rbultje@ronald.bitfreak.net Fri Jun 9 10:47:45 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B71663B0413 for ; Fri, 9 Jun 2006 10:47:45 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32342-10 for ; Fri, 9 Jun 2006 10:47:42 -0400 (EDT) Received: from ms-smtp-03.rdc-nyc.rr.com (ms-smtp-03.rdc-nyc.rr.com [24.29.109.7]) by menubar.gnome.org (Postfix) with ESMTP id 215673B0FF1 for ; Fri, 9 Jun 2006 10:47:42 -0400 (EDT) Received: from [192.168.0.103] (cpe-66-65-0-167.nyc.res.rr.com [66.65.0.167]) by ms-smtp-03.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id k59Eld9O019647; Fri, 9 Jun 2006 10:47:40 -0400 (EDT) From: "Ronald S. Bultje" To: Christian Fredrik Kalager Schaller In-Reply-To: <1149862318.2356.36.camel@localhost.localdomain> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> <1149695062.2855.2.camel@localhost.localdomain> <1149695742.15592.1.camel@sledipus.rex> <1149696047.14668.35.camel@bnocera.surrey.redhat.com> <1149862318.2356.36.camel@localhost.localdomain> Content-Type: text/plain Date: Fri, 09 Jun 2006 10:46:01 -0400 Message-Id: <1149864361.2869.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.563 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599] X-Spam-Score: -2.563 X-Spam-Level: Cc: gnome-multimedia@gnome.org, Bastien Nocera Subject: Re: a general multimedia library - Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 14:47:45 -0000 Hi, On Fri, 2006-06-09 at 16:11 +0200, Christian Fredrik Kalager Schaller wrote: > Well the topic of having a multimedia widget library has been discussed > multiple times and maybe now is the time to move on it? If someone believes that this would be useful and should be done, then that person should go ahead and do it. Ronald From thomas@apestaart.org Fri Jun 9 15:11:02 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 78FFA3B00E9 for ; Fri, 9 Jun 2006 15:11:02 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15077-08 for ; Fri, 9 Jun 2006 15:11:01 -0400 (EDT) Received: from mx1.es6.egwn.net (server02.es6.egwn.net [195.10.6.12]) by menubar.gnome.org (Postfix) with ESMTP id E94F03B0149 for ; Fri, 9 Jun 2006 15:11:00 -0400 (EDT) Received: from mx1.fr4.egwn.net (server07.fr4.egwn.net [62.39.85.77]) by mx1.es6.egwn.net (Postfix) with ESMTP id 0FC914F822C; Fri, 9 Jun 2006 21:10:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mx1.fr4.egwn.net (spiffy mail daemon) with ESMTP id CB4CC83BFD; Fri, 9 Jun 2006 21:10:47 +0200 (CEST) Received: from mx1.fr4.egwn.net ([127.0.0.1]) by localhost (server07.fr4.egwn.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22095-43; Fri, 9 Jun 2006 21:10:47 +0200 (CEST) Received: from thread.fluendo.lan (core.fluendo.com [195.10.6.237]) by mx1.fr4.egwn.net (spiffy mail daemon) with ESMTP id D8A3283BF8; Fri, 9 Jun 2006 21:10:46 +0200 (CEST) Received: from otto.amantes (thomas.fluendo.lan [192.168.1.10]) by thread.fluendo.lan (Postfix) with ESMTP id 8DDD1FE93; Fri, 9 Jun 2006 21:10:57 +0200 (CEST) Received: from otto.amantes (otto.amantes [127.0.0.1]) by otto.amantes (Postfix) with ESMTP id 9B95DEFC0D; Fri, 9 Jun 2006 21:11:00 +0200 (CEST) Content-Type: multipart/mixed; boundary="127.0.0.1.500.4863.1149880260.533.2" MIME-Version: 1.0 To: gstreamer-devel@lists.sourceforge.net, gstreamer-announce@lists.sourceforge.net, kde-multimedia@kde.org, gnome-multimedia@gnome.org Message-Id: <20060609191100.9B95DEFC0D@otto.amantes> Date: Fri, 9 Jun 2006 21:11:00 +0200 (CEST) From: thomas@apestaart.org X-Scanned: By amavis at egwn.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: Yes, score=2.06 tagged_above=-999 required=2 tests=[AWL=-1.482, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, MIME_BASE64_TEXT=1.885, NO_REAL_NAME=0.961, RCVD_IN_SBL=3.16] X-Spam-Score: 2.06 X-Spam-Level: ** X-Spam-Flag: YES Cc: Subject: RELEASE: GStreamer 0.10.7 'Soepeke, ik zie ou' X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 19:11:02 -0000 --127.0.0.1.500.4863.1149880260.533.2 Content-Type: text/plain This mail announces the release of GStreamer 0.10.7 'Soepeke, ik zie ou'. GStreamer is a streaming media framework that allows the construction of graphs of elements which operate on media data. Applications using this library can do anything from real-time sound processing over playing video to capturing audio, video, and even other types of media data. Its architecture allows for adding new data types or processing capabilities simply by installing new plug-ins. GStreamer is the core module, containing libraries, headers, the basic object hierarchy, and a set of media-agnostic core elements. For more information, see [http://gstreamer.freedesktop.org/modules/gstreamer.html] To file bugs, go to [http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer&component=gstreamer+%28core%29] --127.0.0.1.500.4863.1149880260.533.2 Content-Type: text/plain; name=RELEASE Content-Transfer-Encoding: base64 ClJlbGVhc2Ugbm90ZXMgZm9yIEdTdHJlYW1lcsKgMC4xMC43ICJTb2VwZWtlLCBpayB6aWUgb3Ui CiAgICAgICAgCgoKVGhlIEdTdHJlYW1lciB0ZWFtIGlzIHByb3VkIHRvIGFubm91bmNlIGEgbmV3 IHJlbGVhc2UKaW4gdGhlIDAuMTAueCBzdGFibGUgc2VyaWVzIG9mIHRoZQpjb3JlIG9mIHRoZSBH U3RyZWFtZXIgc3RyZWFtaW5nIG1lZGlhIGZyYW1ld29yay4KCgpUaGUgMC4xMC54IHNlcmllcyBp cyBhIHN0YWJsZSBzZXJpZXMgdGFyZ2V0ZWQgYXQgZW5kIHVzZXJzLgpJdCBpcyBub3QgQVBJIG9y IEFCSSBjb21wYXRpYmxlIHdpdGggdGhlIHN0YWJsZSAwLjgueCBzZXJpZXMuCkl0IGlzLCBob3dl dmVyLCBwYXJhbGxlbCBpbnN0YWxsYWJsZSB3aXRoIHRoZSAwLjgueCBzZXJpZXMuCgoKVGhlIDAu MTAueCBzZXJpZXMgaGFzIGJlZW4gcmV3b3JrZWQgZm9yIHRocmVhZHNhZmV0eS4gIEl0IGFsc28g ZmVhdHVyZXMKdmFyaW91cyBmZWF0dXJlIGFkZGl0aW9ucyBhbmQgZW5jaGFuY2VtZW50cy4KCgpU aGlzIG1vZHVsZSwgZ3N0cmVhbWVyLCBvbmx5IGNvbnRhaW5zIGNvcmUgZnVuY3Rpb25hbGl0eS4K Rm9yIGFjdHVhbCBtZWRpYSBwbGF5YmFjaywgeW91IHdpbGwgbmVlZCBvdGhlciBtb2R1bGVzLgoK Z3N0LXBsdWdpbnMtYmFzZQpjb250YWlucyBhIGJhc2ljIHNldCBvZiB3ZWxsLXN1cHBvcnRlZCBw bHVnLWlucwpnc3QtcGx1Z2lucy1nb29kCmNvbnRhaW5zIGEgc2V0IG9mIHdlbGwtc3VwcG9ydGVk IHBsdWctaW5zIHVuZGVyIG91ciBwcmVmZXJyZWQgbGljZW5zZQpnc3QtcGx1Z2lucy11Z2x5CmNv bnRhaW5zIGEgc2V0IG9mIHdlbGwtc3VwcG9ydGVkIHBsdWctaW5zLCBidXQgbWlnaHQgcG9zZSBw cm9ibGVtcyBmb3IKICAgIGRpc3RyaWJ1dG9ycwpnc3QtcGx1Z2lucy1iYWQKY29udGFpbnMgYSBz ZXQgb2YgbGVzcyBzdXBwb3J0ZWQgcGx1Zy1pbnMgdGhhdCBoYXZlbid0IHBhc3NlZCB0aGUKICAg IHJpZ29yb3VzIHF1YWxpdHkgdGVzdGluZyB3ZSBleHBlY3QKCgoKICAKRmVhdHVyZXMgb2YgdGhp cyByZWxlYXNlCiAgICAKICAgICAgKiBQYXJhbGxlbCBpbnN0YWxsYWJpbGl0eSB3aXRoIDAuOC54 IHNlcmllcwogICAgICAqIFRocmVhZHNhZmUgZGVzaWduIGFuZCBBUEkKICAgICAgKiBSZWdpc3Ry eSBjYWNoZSB1cGRhdGluZyBpcyBub3cgZG9uZSBpbiBhIGZvcmssIHNvIG5vIHBsdWdpbnMgYXJl IGxlZnQgb3BlbmVkCiAgICAgICogTmV3IHZlcnNpb24gb2YgZGF0YSBwcm90b2NvbCBub3cgc2Vy aWFsaXplcyBldmVudHMKICAgICAgKiBxdWV1ZSBmaXhlcwogICAgICAqIHdpbjMyIGZpeGVzCgpC dWdzIGZpeGVkIGluIHRoaXMgcmVsZWFzZQogICAgCiAgICAgICogMzM4MzM1IDogW3BhdGNoXSBt ZW1sZWFrIGluIGdzdC11dGlscy5jIChsZWFrIHBhZHMgZnJvbSBpdGVyYXRvcikKICAgICAgKiAz NDM1OTggOiB1bmRlZmluZWQgc3ltYm9sIGluIGNvcmVpbmRleGVycyB3aGVuIHVzaW5nIC0tZGlz YWJsZS1sb2EuLi4KICAgICAgKiAzMzY5MjkgOiBHc3RDb2xsZWN0UGFkcyBkb2VzIG5vdCBjbGVh ci9yZXNldCBzZWdtZW50IGluZm8gYWZ0ZXIgZmwuLi4KICAgICAgKiAzMzcxMDAgOiBbZmFrZXNp bmtdIGFkZCAiIHByZXJvbGwtaGFuZG9mZiAiIHNpZ25hbAogICAgICAqIDMzOTkxOCA6IEdzdFRh Z1NldHRlciBtZXJnZS1tb2RlIGRlc2NyaXB0aW9uIHVuY2xlYXIsIGFuZCBpbXBsZW1lbi4uLgog ICAgICAqIDM0MDUwMSA6IFtmaWxlc3JjXSBnaXZlIHByaW1hcnkgcmFuawogICAgICAqIDM0MTY2 MiA6IGdzdC1sYXVuY2ggcHJpbnRfdGFncygpIGZpeAogICAgICAqIDM0MjIzOCA6IEFQSTogZ3N0 X2VsZW1lbnRfc2Vla19zaW1wbGUKICAgICAgKiAzNDIzMjEgOiBHU1RfUVVFUllfUE9TSVRJT04g ZmFpbHMgaWYgR3N0QmFzZVNyYyBpbiBnZXRfcmFuZ2UgbW9kZQogICAgICAqIDM0Mjc3NyA6IHJl YnVpbGRpbmcgdGhlIHJlZ2lzdHJ5IGxlYXZlcyBhbGwgcGx1Z2lucyBpbiBtZW1vcnkKICAgICAg KiAzNDI4MjAgOiBnc3RuZXRjbGllbnRjbG9jay5jKDQ1Myk6IHNlcnZhZGRyIHVzZWQgYmVmb3Jl IHNldAogICAgICAqIDM0MzA1NyA6IGdzdC1sYXVuY2gtMC4xMCBzZWdmYXVsdHMgd2hlbiBwYXNz ZWQgZ3N0LXBsdWdpbi1wYXRoIGFuZC4uLgogICAgICAqIDM0MzM0MSA6IFtBUEldIGFkZCBHU1Rf VEFHX1BSRVZJRVdfSU1BR0UKICAgICAgKiAzNDM4MjcgOiBsZWFrIGluIGdzdF9pbmRleF9ndHlw ZV9yZXNvbHZlcgogICAgICAqIDM0MzkyOSA6IFVzZSBvZiAvLyBpbiBwdWJsaWMgaGVhZGVyCiAg ICAgICogMzQzOTg4IDogZGF0YSBwcm90b2NvbCBuZWVkcyBleHRlbmRpbmcgdG8gaGFuZGxlIGV2 ZW50cyBiZXR0ZXIKICAgICAgKiAzNDE0NzkgOiBUb28gbWFueSBwbHVnaW5zIGxvYWRlZCBldmVu IGZvciB1cC10by1kYXRlIHJlZ2lzdHJ5CiAgICAgICogMzQzMzM0IDogR3N0Q29sbGVjdFBhZHMg dGVzdHN1aXRlIGFuZCBmaXhlcwogICAgICAqIDM0MzUzOCA6IEdzdENvbGxlY3RQYWRzIGRvZXNu J3QgcmVzZXQgRU9TIGZpZWxkcyB3aGVuIHN0b3BwZWQKCkFQSSBjaGFuZ2VkIGluIHRoaXMgcmVs ZWFzZQogICAgIAoKLSBBUEkgYWRkaXRpb25zOgogICAgCiogZ3N0X2VsZW1lbnRfc2Vla19zaW1w bGUoKQoqIEdTVF9GTE9XX0NVU1RPTV9TVUNDRVNTCiogR1NUX0ZMT1dfQ1VTVE9NX0VSUk9SCiog R1NUX0ZMT1dfSVNfU1VDQ0VTUwoqIGdzdF9jb2xsZWN0X3BhZHNfc2V0X2ZsdXNoaW5nKCkKKiBH U1RfVEFHX1BSRVZJRVdfSU1BR0UKKiBnc3RfZHBfY3JjKCkKKiBHc3REUFBhY2tldGl6ZXIKKiBH c3REUFZlcnNpb24KKiBHc3RGYWtlU2luazo6cHJlcm9sbC1oYW5kb2ZmCiogR3N0RmFrZVNpbms6 OnVzZS1tbWFwCgpEb3dubG9hZAoKWW91IGNhbiBmaW5kIHNvdXJjZSByZWxlYXNlcyBvZiBnc3Ry ZWFtZXIgaW4gdGhlIGRvd25sb2FkIGRpcmVjdG9yeToKaHR0cDovL2dzdHJlYW1lci5mcmVlZGVz a3RvcC5vcmcvc3JjL2dzdHJlYW1lci8KCkdTdHJlYW1lciBIb21lcGFnZQoKTW9yZSBkZXRhaWxz IGNhbiBiZSBmb3VuZCBvbiB0aGUgcHJvamVjdCdzIHdlYnNpdGU6Cmh0dHA6Ly9nc3RyZWFtZXIu ZnJlZWRlc2t0b3Aub3JnLwoKU3VwcG9ydCBhbmQgQnVncwoKV2UgdXNlIEdOT01FJ3MgYnVnemls bGEgZm9yIGJ1ZyByZXBvcnRzIGFuZCBmZWF0dXJlIHJlcXVlc3RzOgpodHRwOi8vYnVnemlsbGEu Z25vbWUub3JnL2VudGVyX2J1Zy5jZ2k/cHJvZHVjdD1HU3RyZWFtZXIKCkRldmVsb3BlcnMKCkNW UyBpcyBob3N0ZWQgb24gY3ZzLmZyZWVkZXNrdG9wLm9yZy4KQWxsIGNvZGUgaXMgaW4gQ1ZTIGFu ZCBjYW4gYmUgY2hlY2tlZCBvdXQgZnJvbSB0aGVyZS4KSW50ZXJlc3RlZCBkZXZlbG9wZXJzIG9m IHRoZSBjb3JlIGxpYnJhcnksIHBsdWctaW5zLCBhbmQgYXBwbGljYXRpb25zIHNob3VsZApzdWJz Y3JpYmUgdG8gdGhlIGdzdHJlYW1lci1kZXZlbCBsaXN0LiBJZiB0aGVyZSBpcyBzdWZmaWNpZW50 IGludGVyZXN0IHdlCndpbGwgY3JlYXRlIG1vcmUgbGlzdHMgYXMgbmVjZXNzYXJ5LgoKICAgICAg ICAKQXBwbGljYXRpb25zCgpBcHBsaWNhdGlvbnMgcG9ydGVkIHRvIEdTdHJlYW1lciAwLjEwIGlu Y2x1ZGUgVG90ZW0sIFJoeXRobUJveCwgU291bmQtSnVpY2VyLApHbm9tZSBNZWRpYSwgRmx1bW90 aW9uLCBBbWFyb2ssIEphbWJvcmVlLCBQaXRpdmksIElzdGFuYnVsLCBBbm5vQW1wLCBFbGlzYSwg YW5kIG90aGVycy4KTGV0IHVzIGtub3cgaWYgeW91IHdhbnQgdG8gYmUgYWRkZWQgdG8gdGhpcyBs aXN0LgoKICAKQ29udHJpYnV0b3JzIHRvIHRoaXMgcmVsZWFzZQogICAgCiAgICAgICogQWxlc3Nh bmRybyBEZWNpbmEKICAgICAgKiBFZHdhcmQgSGVydmV5CiAgICAgICogSmFuIFNjaG1pZHQKICAg ICAgKiBKdWxpZW4gTW91dHRlCiAgICAgICogTHV0eiBNdWVsbGVyCiAgICAgICogTWFyayBOYXV3 ZWxhZXJ0cwogICAgICAqIE1pY2hhZWwgU21pdGgKICAgICAgKiBTZWJhc3RpZW4gTW91dHRlCiAg ICAgICogU3RlZmFuIEtvc3QKICAgICAgKiBUaG9tYXMgVmFuZGVyIFN0aWNoZWxlCiAgICAgICog VGltLVBoaWxpcHAgTcO8bGxlcgogICAgICAqIFdpbSBUYXltYW5zCiAgICAgICogWmFoZWVyIEFi YmFzIE1lcmFsaQrCoA== --127.0.0.1.500.4863.1149880260.533.2-- From thomas@apestaart.org Fri Jun 9 15:11:49 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5C75C3B00E9 for ; Fri, 9 Jun 2006 15:11:49 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15136-05 for ; Fri, 9 Jun 2006 15:11:48 -0400 (EDT) Received: from mx1.es6.egwn.net (server02.es6.egwn.net [195.10.6.12]) by menubar.gnome.org (Postfix) with ESMTP id 0A9E03B0149 for ; Fri, 9 Jun 2006 15:11:47 -0400 (EDT) Received: from mx1.fr4.egwn.net (server07.fr4.egwn.net [62.39.85.77]) by mx1.es6.egwn.net (Postfix) with ESMTP id 5C5134F822C; Fri, 9 Jun 2006 21:11:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mx1.fr4.egwn.net (spiffy mail daemon) with ESMTP id 20D9883BFD; Fri, 9 Jun 2006 21:11:35 +0200 (CEST) Received: from mx1.fr4.egwn.net ([127.0.0.1]) by localhost (server07.fr4.egwn.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23574-43; Fri, 9 Jun 2006 21:11:34 +0200 (CEST) Received: from thread.fluendo.lan (core.fluendo.com [195.10.6.237]) by mx1.fr4.egwn.net (spiffy mail daemon) with ESMTP id 33DE383BF8; Fri, 9 Jun 2006 21:11:34 +0200 (CEST) Received: from otto.amantes (thomas.fluendo.lan [192.168.1.10]) by thread.fluendo.lan (Postfix) with ESMTP id 071AFFE93; Fri, 9 Jun 2006 21:11:45 +0200 (CEST) Received: from otto.amantes (otto.amantes [127.0.0.1]) by otto.amantes (Postfix) with ESMTP id 35F55EFC0D; Fri, 9 Jun 2006 21:11:48 +0200 (CEST) Content-Type: multipart/mixed; boundary="127.0.0.1.500.5548.1149880308.216.2" MIME-Version: 1.0 To: gstreamer-devel@lists.sourceforge.net, gstreamer-announce@lists.sourceforge.net, kde-multimedia@kde.org, gnome-multimedia@gnome.org Message-Id: <20060609191148.35F55EFC0D@otto.amantes> Date: Fri, 9 Jun 2006 21:11:48 +0200 (CEST) From: thomas@apestaart.org X-Scanned: By amavis at egwn.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: Yes, score=2.198 tagged_above=-999 required=2 tests=[AWL=-1.575, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, MIME_BASE64_TEXT=1.885, NO_REAL_NAME=0.961, RCVD_IN_SBL=3.16, TW_EG=0.077, TW_EV=0.077, TW_FD=0.077] X-Spam-Score: 2.198 X-Spam-Level: ** X-Spam-Flag: YES Cc: Subject: RELEASE: GStreamer Base Plug-ins 0.10.8 'Moar gij zie mij nie' X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 19:11:49 -0000 --127.0.0.1.500.5548.1149880308.216.2 Content-Type: text/plain This mail announces the release of GStreamer Base Plug-ins 0.10.8 'Moar gij zie mij nie'. GStreamer Base Plug-ins is a well-groomed and well-maintained collection of GStreamer plug-ins and elements, spanning the range of possible types of elements one would want to write for GStreamer. It also contains helper libraries and base classes useful for writing elements. A wide range of video and audio decoders, encoders, and filters are included. For more information, see [http://gstreamer.freedesktop.org/modules/gst-plugins-base.html] To file bugs, go to [http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer&component=gst-plugins-base] --127.0.0.1.500.5548.1149880308.216.2 Content-Type: text/plain; name=RELEASE Content-Transfer-Encoding: base64 ClJlbGVhc2Ugbm90ZXMgZm9yIEdTdHJlYW1lciBCYXNlIFBsdWctaW5zwqAwLjEwLjggIk1vYXIg Z2lqIHppZXQgbWlqIG5pZSIKICAgICAgICAKCgpUaGUgR1N0cmVhbWVyIHRlYW0gaXMgcHJvdWQg dG8gYW5ub3VuY2UgYSBuZXcgcmVsZWFzZQppbiB0aGUgMC4xMC54IHN0YWJsZSBzZXJpZXMgb2Yg dGhlCkdTdHJlYW1lciBCYXNlIFBsdWctaW5zLgoKClRoZSAwLjEwLnggc2VyaWVzIGlzIGEgc3Rh YmxlIHNlcmllcyB0YXJnZXRlZCBhdCBlbmQgdXNlcnMuCkl0IGlzIG5vdCBBUEkgb3IgQUJJIGNv bXBhdGlibGUgd2l0aCB0aGUgc3RhYmxlIDAuOC54IHNlcmllcy4KSXQgaXMsIGhvd2V2ZXIsIHBh cmFsbGVsIGluc3RhbGxhYmxlIHdpdGggdGhlIDAuOC54IHNlcmllcy4KCgoKVGhpcyBtb2R1bGUg Y29udGFpbnMgYSBzZXQgb2YgcmVmZXJlbmNlIHBsdWdpbnMsIGJhc2UgY2xhc3NlcyBmb3Igb3Ro ZXIKcGx1Z2lucywgYW5kIGhlbHBlciBsaWJyYXJpZXMuCgpUaGlzIG1vZHVsZSBpcyBrZXB0IHVw LXRvLWRhdGUgdG9nZXRoZXIgd2l0aCB0aGUgY29yZSBkZXZlbG9wbWVudHMuICBFbGVtZW50Cndy aXRlcnMgc2hvdWxkIGxvb2sgYXQgdGhlIGVsZW1lbnRzIGluIHRoaXMgbW9kdWxlIGFzIGEgcmVm ZXJlbmNlIGZvcgp0aGVpciBkZXZlbG9wbWVudC4KClRoaXMgbW9kdWxlIGNvbnRhaW5zIGVsZW1l bnRzIGZvciwgYW1vbmcgb3RoZXJzOgoKICBkZXZpY2UgcGx1Z2luczogeCh2KWltYWdlc2luaywg YWxzYSwgdjRsc3JjLCBjZHBhcmFub2lhCiAgY29udGFpbmVyczogb2dnCiAgY29kZWNzOiB2b3Ji aXMsIHRoZW9yYQogIHRleHQ6IHRleHRvdmVybGF5LCBzdWJwYXJzZQogIHNvdXJjZXM6IGF1ZGlv dGVzdHNyYywgdmlkZW90ZXN0c3JjLCBnbm9tZXZmc3NyYwogIG5ldHdvcms6IHRjcAogIHR5cGVm aW5kCiAgYXVkaW8gcHJvY2Vzc2luZzogYXVkaW9jb252ZXJ0LCBhZGRlciwgYXVkaW9yYXRlLCBh dWRpb3NjYWxlLCB2b2x1bWUKICB2aXN1YWxpc2F0aW9uOiBsaWJ2aXN1YWwKICB2aWRlbyBwcm9j ZXNzaW5nOiBmZm1wZWdjb2xvcnNwYWNlCiAgYWdncmVnYXRlIGVsZW1lbnRzOiBkZWNvZGViaW4s IHBsYXliaW4KCgpPdGhlciBtb2R1bGVzIGNvbnRhaW5pbmcgcGx1Zy1pbnMgYXJlOgoKCmdzdC1w bHVnaW5zLWdvb2QKY29udGFpbnMgYSBzZXQgb2Ygd2VsbC1zdXBwb3J0ZWQgcGx1Zy1pbnMgdW5k ZXIgb3VyIHByZWZlcnJlZCBsaWNlbnNlCmdzdC1wbHVnaW5zLXVnbHkKY29udGFpbnMgYSBzZXQg b2Ygd2VsbC1zdXBwb3J0ZWQgcGx1Zy1pbnMsIGJ1dCBtaWdodCBwb3NlIHByb2JsZW1zIGZvcgog ICAgZGlzdHJpYnV0b3JzCmdzdC1wbHVnaW5zLWJhZApjb250YWlucyBhIHNldCBvZiBsZXNzIHN1 cHBvcnRlZCBwbHVnLWlucyB0aGF0IGhhdmVuJ3QgcGFzc2VkIHRoZQogICAgcmlnb3JvdXMgcXVh bGl0eSB0ZXN0aW5nIHdlIGV4cGVjdAoKCgogIApGZWF0dXJlcyBvZiB0aGlzIHJlbGVhc2UKICAg IAogICAgICAqIFBhcmFsbGVsIGluc3RhbGxhYmlsaXR5IHdpdGggMC44Lnggc2VyaWVzCiAgICAg ICogVGhyZWFkc2FmZSBkZXNpZ24gYW5kIEFQSQogICAgICAqIGFsc2FzaW5rIHByb2JpbmcgZml4 ZXMKICAgICAgKiB4dmltYWdlc2luayBlcnJvciByZXBvcnRpbmcgZml4ZXMKICAgICAgKiBzdWJ0 aXRsZSBmaXhlcwogICAgICAqIGFkZGVyIGZpeGVzCiAgICAgICogdm9yYmlzIG11bHRpY2hhbm5l bCBmaXhlcwogICAgICAqIG11bHRpZmRzaW5rIHN0cmVhbWhlYWRlciBmaXhlcwoKQnVncyBmaXhl ZCBpbiB0aGlzIHJlbGVhc2UKICAgIAogICAgICAqIDE2OTkzNiA6IFtzdWJwYXJzZV0gc3VwcG9y dCBmb3IgU0FNSSBzdWJ0aXRsZXMKICAgICAgKiAzMTUzMTIgOiBHc3RyZWFtZXIgWHYgdXNlcyBS R0IgaW5zdGVhZCBvZiBZVVYuCiAgICAgICogMzM0MDAyIDogdmlkZW80bGludXggc2hvdWxkbid0 IGRlcGVuZCBvbiBYIGluIGNvbmZpZ3VyZSBzY3JpcHQKICAgICAgKiAzMzY4ODEgOiBbbGlidmlz dWFsXSBhZGRpdGlvbmFsIHN1cHBvcnQgZm9yIGxpYnZpc3VhbC0wLjQKICAgICAgKiAzMzc1NDQg OiBbeHZpbWFnZXNpbmtdIEludGVybmFsIEVycm9yIHdoZW4gaW1hZ2UgaXMgdG9vIGxhcmdlCiAg ICAgICogMzM5NTIwIDogW3N1YnBhcnNlXSBhZGQgIiBlbmNvZGluZyAiIHByb3BlcnR5CiAgICAg ICogMzQwOTA5IDogW2Fsc2FzaW5rXSBjYW4ndCBlbmFibGUgc3BkaWYgb3V0cHV0CiAgICAgICog MzQxNTQyIDogc29tZSB1c2VycyBoYXZlIGFuIGFzc2VydGlvbiBmYWlsZWQ6IChHU1RfVklERU9f U0lOS19XSURULi4uCiAgICAgICogMzQxNTYyIDogYXVkaW9jb252ZXJ0IGRvZXNuJ3QgbGlzdCBm b3JtYXRzIGluIG9yZGVyIG9mIHByZWZlcmVuY2UKICAgICAgKiAzNDE2OTYgOiBhdWRpb2NvbnZl cnQgY3Jhc2hlcyBpZiBjb252ZXJ0aW5nIGZyb20gYSBmb3JtYXQgd2l0aCBubyAuLi4KICAgICAg KiAzNDE3MTkgOiBiaXNlY3Rpb24gYWxnb3JpdGhtIGluIG9nZyBkb2Vzbid0IGJpc2VjdCBpbiBz b21lIGNhc2VzCiAgICAgICogMzQxNzMyIDogW2Fsc2FzaW5rXSBkb2Vzbid0IHF1ZXJ5IHN1cHBv cnRlZCBzYW1wbGUgcmF0ZXMKICAgICAgKiAzNDE4NzMgOiBbYWxzYXNpbmtdIG1pbm9yIG1lbW9y eSBsZWFrLCB1c2VzIHVucHJvdGVjdGVkIHN0YXRpYyB2YXIuLi4KICAgICAgKiAzNDIxNDMgOiBb c3VicGFyc2VdIHNhbWkgcGFyc2VyIG5lZWRzIHRvIGVzY2FwZSBjaGFyYWN0ZXJzCiAgICAgICog MzQyMTgxIDogW2Fsc2FdIGFkZCBwcm9wZXJ0eSBwcm9iZSBpbnRlcmZhY2UgdG8gYWxzYXNpbmsg YW5kIGFsc2FzcmMKICAgICAgKiAzNDIyNjggOiBbcGxheWJpbl0gYWRkICdzdWJ0aXRsZS1lbmNv ZGluZycgcHJvcGVydHkKICAgICAgKiAzNDIzNDUgOiBbcmlmZl0gRWxlcGhhbnQncyBEcmVhbSBB VkkgZG9lcyBub3QgcGxheSwgSlVOSyBjaHVuayBiZWYuLi4KICAgICAgKiAzNDI1NjYgOiBCdWls ZGluZyB3aXRob3V0IEdUSysgZmFpbHMKICAgICAgKiAzNDMzOTcgOiBILjI2NC9BQUMgbW92aWUg ZGVhZGxvY2tzIHdpdGggdG90ZW0gaW4gZ3N0cmVhbWVyIGNvZGUsIHAuLi4KICAgICAgKiAzMzk5 MzUgOiBbYWRkZXJdIGRlYWQtbG9ja3Mgd2hlbiBhZGRpbmcgc2luayBwYWRzIGluIFBBVVNFRCBz dGF0ZQoKRG93bmxvYWQKCllvdSBjYW4gZmluZCBzb3VyY2UgcmVsZWFzZXMgb2YgZ3N0LXBsdWdp bnMtYmFzZSBpbiB0aGUgZG93bmxvYWQgZGlyZWN0b3J5OgpodHRwOi8vZ3N0cmVhbWVyLmZyZWVk ZXNrdG9wLm9yZy9zcmMvZ3N0LXBsdWdpbnMtYmFzZS8KCkdTdHJlYW1lciBIb21lcGFnZQoKTW9y ZSBkZXRhaWxzIGNhbiBiZSBmb3VuZCBvbiB0aGUgcHJvamVjdCdzIHdlYnNpdGU6Cmh0dHA6Ly9n c3RyZWFtZXIuZnJlZWRlc2t0b3Aub3JnLwoKU3VwcG9ydCBhbmQgQnVncwoKV2UgdXNlIEdOT01F J3MgYnVnemlsbGEgZm9yIGJ1ZyByZXBvcnRzIGFuZCBmZWF0dXJlIHJlcXVlc3RzOgpodHRwOi8v YnVnemlsbGEuZ25vbWUub3JnL2VudGVyX2J1Zy5jZ2k/cHJvZHVjdD1HU3RyZWFtZXIKCkRldmVs b3BlcnMKCkNWUyBpcyBob3N0ZWQgb24gY3ZzLmZyZWVkZXNrdG9wLm9yZy4KQWxsIGNvZGUgaXMg aW4gQ1ZTIGFuZCBjYW4gYmUgY2hlY2tlZCBvdXQgZnJvbSB0aGVyZS4KSW50ZXJlc3RlZCBkZXZl bG9wZXJzIG9mIHRoZSBjb3JlIGxpYnJhcnksIHBsdWctaW5zLCBhbmQgYXBwbGljYXRpb25zIHNo b3VsZApzdWJzY3JpYmUgdG8gdGhlIGdzdHJlYW1lci1kZXZlbCBsaXN0LiBJZiB0aGVyZSBpcyBz dWZmaWNpZW50IGludGVyZXN0IHdlCndpbGwgY3JlYXRlIG1vcmUgbGlzdHMgYXMgbmVjZXNzYXJ5 LgoKICAgICAgICAKQXBwbGljYXRpb25zCiAgCkNvbnRyaWJ1dG9ycyB0byB0aGlzIHJlbGVhc2UK ICAgIAogICAgICAqIEVkd2FyZCBIZXJ2ZXkKICAgICAgKiBKYW4gU2NobWlkdAogICAgICAqIEp1 bGllbiBNb3V0dGUKICAgICAgKiBNYXJ0aW4gU3p1bGVja2kKICAgICAgKiBNaWNoYWVsIFNtaXRo CiAgICAgICogUGV0ZXIgS2plbGxlcnN0ZWR0CiAgICAgICogU2ViYXN0aWVuIE1vdXR0ZQogICAg ICAqIFN0ZWZhbiBLb3N0CiAgICAgICogVGhvbWFzIFZhbmRlciBTdGljaGVsZQogICAgICAqIFRp bS1QaGlsaXBwIE3DvGxsZXIKICAgICAgKiBXaW0gVGF5bWFucwogICAgICAqIFlvdW5nLUhvIENo YQogICAgICAqIFphaGVlciBBYmJhcyBNZXJhbGkKwqA= --127.0.0.1.500.5548.1149880308.216.2-- From thomas@apestaart.org Sat Jun 10 13:20:04 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 77ABD3B0280 for ; Sat, 10 Jun 2006 13:20:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16793-02 for ; Sat, 10 Jun 2006 13:20:03 -0400 (EDT) Received: from core.fluendo.com (core.fluendo.com [195.10.6.237]) by menubar.gnome.org (Postfix) with ESMTP id E5DCC3B01B8 for ; Sat, 10 Jun 2006 13:20:02 -0400 (EDT) Received: from onzenbak.amantes (70.Red-81-38-184.dynamicIP.rima-tde.net [81.38.184.70]) by core.fluendo.com (Postfix) with ESMTP id 205F71DC; Sat, 10 Jun 2006 19:20:01 +0200 (CEST) Received: from otto.amantes (otto.amantes [192.168.1.10]) by onzenbak.amantes (Postfix) with ESMTP id 4680720476; Sat, 10 Jun 2006 19:19:58 +0200 (CEST) Received: from otto.amantes (otto.amantes [127.0.0.1]) by otto.amantes (Postfix) with ESMTP id 3B641EFC0D; Sat, 10 Jun 2006 19:20:01 +0200 (CEST) Content-Type: multipart/mixed; boundary="127.0.0.1.500.6078.1149960001.170.2" MIME-Version: 1.0 To: gstreamer-devel@lists.sourceforge.net, gstreamer-announce@lists.sourceforge.net, kde-multimedia@kde.org, gnome-multimedia@gnome.org Message-Id: <20060610172001.3B641EFC0D@otto.amantes> Date: Sat, 10 Jun 2006 19:20:01 +0200 (CEST) From: thomas@apestaart.org X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.991 tagged_above=-999 required=2 tests=[AWL=-1.373, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, MIME_BASE64_TEXT=1.885, NO_REAL_NAME=0.961] X-Spam-Score: -0.991 X-Spam-Level: Cc: Subject: RELEASE: GStreamer 0.10.8 'Soepeke, ik zie ou nog altijd nie' X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 17:20:04 -0000 --127.0.0.1.500.6078.1149960001.170.2 Content-Type: text/plain This mail announces the release of GStreamer 0.10.8 'Soepeke, ik zie ou nog altijd nie'. GStreamer is a streaming media framework that allows the construction of graphs of elements which operate on media data. Applications using this library can do anything from real-time sound processing over playing video to capturing audio, video, and even other types of media data. Its architecture allows for adding new data types or processing capabilities simply by installing new plug-ins. GStreamer is the core module, containing libraries, headers, the basic object hierarchy, and a set of media-agnostic core elements. For more information, see [http://gstreamer.freedesktop.org/modules/gstreamer.html] To file bugs, go to [http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer&component=gstreamer+%28core%29] --127.0.0.1.500.6078.1149960001.170.2 Content-Type: text/plain; name=RELEASE Content-Transfer-Encoding: base64 ClJlbGVhc2Ugbm90ZXMgZm9yIEdTdHJlYW1lcsKgMC4xMC44ICJTb2VwZWtlLCBpayB6aWUgb3Ug bm9nIGFsdGlqZCBuaWUiCiAgICAgICAgCgoKVGhlIEdTdHJlYW1lciB0ZWFtIGlzIHByb3VkIHRv IGFubm91bmNlIGEgbmV3IHJlbGVhc2UKaW4gdGhlIDAuMTAueCBzdGFibGUgc2VyaWVzIG9mIHRo ZQpjb3JlIG9mIHRoZSBHU3RyZWFtZXIgc3RyZWFtaW5nIG1lZGlhIGZyYW1ld29yay4KCgpUaGUg MC4xMC54IHNlcmllcyBpcyBhIHN0YWJsZSBzZXJpZXMgdGFyZ2V0ZWQgYXQgZW5kIHVzZXJzLgpJ dCBpcyBub3QgQVBJIG9yIEFCSSBjb21wYXRpYmxlIHdpdGggdGhlIHN0YWJsZSAwLjgueCBzZXJp ZXMuCkl0IGlzLCBob3dldmVyLCBwYXJhbGxlbCBpbnN0YWxsYWJsZSB3aXRoIHRoZSAwLjgueCBz ZXJpZXMuCgoKVGhlIDAuMTAueCBzZXJpZXMgaGFzIGJlZW4gcmV3b3JrZWQgZm9yIHRocmVhZHNh ZmV0eS4gIEl0IGFsc28gZmVhdHVyZXMKdmFyaW91cyBmZWF0dXJlIGFkZGl0aW9ucyBhbmQgZW5j aGFuY2VtZW50cy4KCgpUaGlzIG1vZHVsZSwgZ3N0cmVhbWVyLCBvbmx5IGNvbnRhaW5zIGNvcmUg ZnVuY3Rpb25hbGl0eS4KRm9yIGFjdHVhbCBtZWRpYSBwbGF5YmFjaywgeW91IHdpbGwgbmVlZCBv dGhlciBtb2R1bGVzLgoKZ3N0LXBsdWdpbnMtYmFzZQpjb250YWlucyBhIGJhc2ljIHNldCBvZiB3 ZWxsLXN1cHBvcnRlZCBwbHVnLWlucwpnc3QtcGx1Z2lucy1nb29kCmNvbnRhaW5zIGEgc2V0IG9m IHdlbGwtc3VwcG9ydGVkIHBsdWctaW5zIHVuZGVyIG91ciBwcmVmZXJyZWQgbGljZW5zZQpnc3Qt cGx1Z2lucy11Z2x5CmNvbnRhaW5zIGEgc2V0IG9mIHdlbGwtc3VwcG9ydGVkIHBsdWctaW5zLCBi dXQgbWlnaHQgcG9zZSBwcm9ibGVtcyBmb3IKICAgIGRpc3RyaWJ1dG9ycwpnc3QtcGx1Z2lucy1i YWQKY29udGFpbnMgYSBzZXQgb2YgbGVzcyBzdXBwb3J0ZWQgcGx1Zy1pbnMgdGhhdCBoYXZlbid0 IHBhc3NlZCB0aGUKICAgIHJpZ29yb3VzIHF1YWxpdHkgdGVzdGluZyB3ZSBleHBlY3QKCgoKICAK RmVhdHVyZXMgb2YgdGhpcyByZWxlYXNlCiAgICAKICAgICAgKiBQYXJhbGxlbCBpbnN0YWxsYWJp bGl0eSB3aXRoIDAuOC54IHNlcmllcwogICAgICAqIFRocmVhZHNhZmUgZGVzaWduIGFuZCBBUEkK ICAgICAgKiBJbXBvcnRhbnQgZml4IGZvciByZWdpc3RyeSB1cGRhdGUgY2F1c2luZyBhcHBsZXRz IG5vdCB0byBsb2FkCgpCdWdzIGZpeGVkIGluIHRoaXMgcmVsZWFzZQogICAgCiAgICAgICogMzQ0 NDc0IDogR25vbWUgTWl4ZXIgQXBwbGV0IGRvZXNuJ3Qgd2FudCB0byBsb2FkCgpEb3dubG9hZAoK WW91IGNhbiBmaW5kIHNvdXJjZSByZWxlYXNlcyBvZiBnc3RyZWFtZXIgaW4gdGhlIGRvd25sb2Fk IGRpcmVjdG9yeToKaHR0cDovL2dzdHJlYW1lci5mcmVlZGVza3RvcC5vcmcvc3JjL2dzdHJlYW1l ci8KCkdTdHJlYW1lciBIb21lcGFnZQoKTW9yZSBkZXRhaWxzIGNhbiBiZSBmb3VuZCBvbiB0aGUg cHJvamVjdCdzIHdlYnNpdGU6Cmh0dHA6Ly9nc3RyZWFtZXIuZnJlZWRlc2t0b3Aub3JnLwoKU3Vw cG9ydCBhbmQgQnVncwoKV2UgdXNlIEdOT01FJ3MgYnVnemlsbGEgZm9yIGJ1ZyByZXBvcnRzIGFu ZCBmZWF0dXJlIHJlcXVlc3RzOgpodHRwOi8vYnVnemlsbGEuZ25vbWUub3JnL2VudGVyX2J1Zy5j Z2k/cHJvZHVjdD1HU3RyZWFtZXIKCkRldmVsb3BlcnMKCkNWUyBpcyBob3N0ZWQgb24gY3ZzLmZy ZWVkZXNrdG9wLm9yZy4KQWxsIGNvZGUgaXMgaW4gQ1ZTIGFuZCBjYW4gYmUgY2hlY2tlZCBvdXQg ZnJvbSB0aGVyZS4KSW50ZXJlc3RlZCBkZXZlbG9wZXJzIG9mIHRoZSBjb3JlIGxpYnJhcnksIHBs dWctaW5zLCBhbmQgYXBwbGljYXRpb25zIHNob3VsZApzdWJzY3JpYmUgdG8gdGhlIGdzdHJlYW1l ci1kZXZlbCBsaXN0LiBJZiB0aGVyZSBpcyBzdWZmaWNpZW50IGludGVyZXN0IHdlCndpbGwgY3Jl YXRlIG1vcmUgbGlzdHMgYXMgbmVjZXNzYXJ5LgoKICAgICAgICAKQXBwbGljYXRpb25zCgpBcHBs aWNhdGlvbnMgcG9ydGVkIHRvIEdTdHJlYW1lciAwLjEwIGluY2x1ZGUgVG90ZW0sIFJoeXRobUJv eCwgU291bmQtSnVpY2VyLApHbm9tZSBNZWRpYSwgRmx1bW90aW9uLCBBbWFyb2ssIEphbWJvcmVl LCBQaXRpdmksIElzdGFuYnVsLCBBbm5vQW1wLCBFbGlzYSwgYW5kIG90aGVycy4KTGV0IHVzIGtu b3cgaWYgeW91IHdhbnQgdG8gYmUgYWRkZWQgdG8gdGhpcyBsaXN0LgoKICAKQ29udHJpYnV0b3Jz IHRvIHRoaXMgcmVsZWFzZQogICAgCiAgICAgICogRWR3YXJkIEhlcnZleQogICAgICAqIFRob21h cyBWYW5kZXIgU3RpY2hlbGUKICAgICAgKiBUaW0tUGhpbGlwcCBNw7xsbGVyCsKg --127.0.0.1.500.6078.1149960001.170.2-- From sjoeboo@sjoeboo.com Wed Jun 14 10:50:35 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CE3003B037F; Wed, 14 Jun 2006 10:50:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08478-04; Wed, 14 Jun 2006 10:50:34 -0400 (EDT) Received: from server.sjoeboo.com (unknown [64.79.192.114]) by menubar.gnome.org (Postfix) with ESMTP id D38F13B02C8; Wed, 14 Jun 2006 10:50:33 -0400 (EDT) Received: by server.sjoeboo.com (Postfix, from userid 33) id 6D37418C4F7F; Wed, 14 Jun 2006 07:50:15 -0700 (PDT) To: gnome-multimedia@gnome.org, rhythmbox-devel@gnome.org Subject: totem and goom information... MIME-Version: 1.0 Date: Wed, 14 Jun 2006 7:50:15 -0700 From: sjoeboo Organization: sjoeboo.com Message-ID: <5135b2d86e5568cedc7e8138809a3b9f@localhost> X-Sender: sjoeboo@sjoeboo.com User-Agent: RoundCube Webmail/0.1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[AWL=0.000, BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: sjoeboo@sjoeboo.com List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 14:50:36 -0000 Good "morning" everyone, So, my (and what should be everyones) favorite music player for gnome, rhythmbox, has been on a steady march of advancement for the past few months, with a whole slew of new features comming about. One thing I though of recently is visualizations, and how ncie it would be to have at least one, possibly as a plugin. I know totem uses GOOM to do this, and was wondering what I might have to do in terms of gstreamer etc to have rhythmbox use it as well. I was looking around on the Totem site for a mailing list etc, but couldn't find anything. Does anyone know where I might find more info for something like this? Thanks, and keep up the great work. -- Matthew Nicholson sjoeboo@sjoeboo.com sjoeboo.com From internalerror@gmail.com Thu Jun 22 05:25:58 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E43203B02D2 for ; Thu, 22 Jun 2006 05:25:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12537-03 for ; Thu, 22 Jun 2006 05:25:56 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.201]) by menubar.gnome.org (Postfix) with ESMTP id D48DD3B0179 for ; Thu, 22 Jun 2006 05:25:55 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so314263wxc for ; Thu, 22 Jun 2006 02:25:55 -0700 (PDT) Received: by 10.70.91.12 with SMTP id o12mr2775555wxb; Thu, 22 Jun 2006 02:25:55 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 02:25:55 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 11:25:55 +0200 From: "Milosz Derezynski" To: xdg@lists.freedesktop.org Subject: MLQ (Media Library Query) file format and mime type proposal MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3009_31371308.1150968355005" X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.255 tagged_above=-999 required=2 tests=[AWL=0.344, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.255 X-Spam-Level: Cc: gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 09:25:58 -0000 ------=_Part_3009_31371308.1150968355005 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I'm one of the main authors of BMP 2 (still being worked on), and along the way of reworking our library, i came across the idea of encoding library queries as URIs, which may look like this: "query:///?artist=Air&album=Moon%20Safari" BMP 2 has a plugin archicture which is a small VFS on it's own, and we treat certain things as "containers" (i.e. they "contain" URIs, like PLS playlists, XSPF, M3U, etc). Now i thought it might be not a bad idea to create a playlist format with these query URLs, and i've called it "MLQ" for media library query. In theory, it's not even application specific. The keys (identifiers), like artist, album, etc, are all based on GStreamer tag identifiers. (They could be maybe adapted to http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but it seems insufficient and doesn't specify certain items, like musicbrainz metadata, which GST does). So i've called this file format "MLQ", with the extension .mlq, created a mime package file for it: Media Library Query List Adding a file of this type to BMPx, or just a plain query:/// URI itself causes a library query and appending of the relevant items to the tracklist (BMP is currently mostly based on the concept of a mutable playlist to which items can be added from various sources, unlike e.g. RB which has mostly immutable "Playlists", but allows for custom queues). Another example is: query:///?artist=Air&album=Moon%20Safari&title=La%20Femme%20d'Argent query:///?artist=Air&album=Moon%20Safari&title=Sexy%20Boy query:///?artist=Air&album=Moon%20Safari&title=All%20I%20Need query:///?artist=Air&album=Moon%20Safari&title=Kelly,%20Watch%20The%20Stars! query:///?artist=Air&album=Moon%20Safari&title=Talisman query:///?artist=Air&album=Moon%20Safari&title=Remember query:///?artist=Air&album=Moon%20Safari&title=You%20Make%20It%20Easy query:///?artist=Air&album=Moon%20Safari&title=Ce%20Matin%20La query:///?artist=Air&album=Moon%20Safari&title=New%20Star%20In%20The%20Sky query:///?artist=Air&album=Moon%20Safari&title=Le%20Voyage%20De%20Penelope Or it might just be: query:///?genre=Jazz Since this is very common, and having the discussions about a common music database in mind, this seems like a useful proposal, since it is not player specific. This ships currently with BMP 2/BMPx SVN, and while i will ship this with the 0.20 release (end-July) anyway, what does everyone think of this in a broader context (common music database, etc)? -- Milosz ------=_Part_3009_31371308.1150968355005 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

I'm one of the main authors of BMP 2 (still being worked on), and along the way of reworking our library, i came across the idea of encoding library queries as URIs, which may look like this:

"query:///?artist=Air&album=Moon%20Safari"

BMP 2 has a plugin archicture which is a small VFS on it's own, and we treat certain things as "containers" (i.e. they "contain" URIs, like PLS playlists, XSPF, M3U, etc).
Now i thought it might be not a bad idea to create a playlist format with these query URLs, and i've called it "MLQ" for media library query. In theory, it's not even
application specific. The keys (identifiers), like artist, album, etc, are all based on GStreamer tag identifiers. (They could be maybe adapted to http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but it seems insufficient and doesn't specify certain items, like musicbrainz metadata, which GST does).

So i've called this file format "MLQ", with the extension .mlq, created a mime package file for it:

<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info ">
  <mime-type type="application/x-media-library-query">
         <comment xml:lang="en">Media Library Query List</comment>
         <magic priority="50">
            <match value="query:///" type="string" offset="0"/>
         </magic>
         <glob pattern="*.mlq"/>
  </mime-type>
</mime-info>

Adding a file of this type to BMPx, or just a plain query:/// URI itself causes a library query and appending of the relevant items to the tracklist (BMP is currently mostly based on the concept of a mutable playlist to which items can be added from various sources, unlike e.g. RB which has mostly immutable "Playlists", but allows for custom queues).

Another example is:

query:///?artist=Air&album=Moon%20Safari&title=La%20Femme%20d'Argent
query:///?artist=Air&album=Moon%20Safari&title=Sexy%20Boy
query:///?artist=Air&album=Moon%20Safari&title=All%20I%20Need
query:///?artist=Air&album=Moon%20Safari&title=Kelly,%20Watch%20The%20Stars!
query:///?artist=Air&album=Moon%20Safari&title=Talisman
query:///?artist=Air&album=Moon%20Safari&title=Remember
query:///?artist=Air&album=Moon%20Safari&title=You%20Make%20It%20Easy
query:///?artist=Air&album=Moon%20Safari&title=Ce%20Matin%20La
query:///?artist=Air&album=Moon%20Safari&title=New%20Star%20In%20The%20Sky
query:///?artist=Air&album=Moon%20Safari&title=Le%20Voyage%20De%20Penelope

Or it might just be:

query:///?genre=Jazz

Since this is very common, and having the discussions about a common music database in mind, this seems like a useful proposal, since it is not player specific.
This ships currently with BMP 2/BMPx SVN, and while i will ship this with the 0.20 release (end-July) anyway, what does everyone think of this in a broader context (common music database, etc)?

-- Milosz
------=_Part_3009_31371308.1150968355005-- From internalerror@gmail.com Thu Jun 22 05:32:59 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7208D3B00DE for ; Thu, 22 Jun 2006 05:32:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12916-03 for ; Thu, 22 Jun 2006 05:32:58 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.207]) by menubar.gnome.org (Postfix) with ESMTP id 6F0643B0373 for ; Thu, 22 Jun 2006 05:32:58 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so314918wxc for ; Thu, 22 Jun 2006 02:32:57 -0700 (PDT) Received: by 10.70.103.9 with SMTP id a9mr2787413wxc; Thu, 22 Jun 2006 02:32:57 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 02:32:57 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 11:32:57 +0200 From: "Milosz Derezynski" To: xdg@lists.freedesktop.org Subject: MLQ: Followup MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3081_18949182.1150968777845" X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.875 tagged_above=-999 required=2 tests=[AWL=-0.071, BAYES_00=-2.599, HTML_00_10=0.795, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -1.875 X-Spam-Level: Cc: gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 09:32:59 -0000 ------=_Part_3081_18949182.1150968777845 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline What i forgot to mention: One benefit of MLQs over 'regular' playlists at least with BMP 2 is that i've introduced a concept of keeping track of tracks across mount point changes which basically works like this: BMP stores for each file the HAL volume and device UDI, and the VRP (Volume Relative Path), that is, the path stripped off the mount point root. Whenever it seems that a file is missing, it checks whether the volume UDI of this file is still present on the system, and if so, gathers the new mount point, and adjusts the URI of this file in the library (this obiviously only works with tracks from the library only anyway since only there we can reliably store the HAL volume/device UDI and the VRP). This means practically: - Mount your music to /music - Start BMP - Add music from /music to the library - Quit BMP - Remount /music to e.g. /old_music - Start BMP - Use the library as before. Whenever BMP finds a file is missing, it will correct the URI on-the-fly as long as the volume is mounted at all on the system (and has an UDI to begin with; problem cases here are network volumes, NFS and SMBFS) So the benefit of an MLQ is that unlike a static playlist, you can be rather sure that no matter where you really move the music, BMP will always be able to find it. Downsides/doesn't-works: - There is no volume UDI available - You make a regular 'move' (mv), and not just a remount In the context of having a common music database, or something like Tracker, this seems very useful (Jamie: Hence my urge to add HAL volume/device UDI per file to the metadata). -- Milosz ------=_Part_3081_18949182.1150968777845 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline What i forgot to mention:

One benefit of MLQs over 'regular' playlists at least with BMP 2 is that i've introduced a concept of keeping track of tracks across mount point changes which basically works like this:

BMP stores for each file the HAL volume and device UDI, and the VRP (Volume Relative Path), that is, the path stripped off the mount point root.
Whenever it seems that a file is missing, it checks whether the volume UDI of this file is still present on the system, and if so, gathers the new mount point, and adjusts the URI of this
file in the library (this obiviously only works with tracks from the library only anyway since only there we can reliably store the HAL volume/device UDI and the VRP).

This means practically:

- Mount your music to /music
- Start BMP
- Add music from /music to the library
- Quit BMP
- Remount /music to e.g. /old_music
- Start BMP
- Use the library as before. Whenever BMP finds a file is missing, it will correct the URI on-the-fly as long as the volume is mounted at all on the system (and has an UDI to begin with; problem cases here are network volumes, NFS and SMBFS)

So the benefit of an MLQ is that unlike a static playlist, you can be rather sure that no matter where you really move the music, BMP will always be able to find it.

Downsides/doesn't-works:

- There is no volume UDI available
- You make a regular 'move' (mv), and not just a remount

In the context of having a common music database, or something like Tracker, this seems very useful (Jamie: Hence my urge to add HAL volume/device UDI per file to the metadata).

-- Milosz
------=_Part_3081_18949182.1150968777845-- From internalerror@gmail.com Thu Jun 22 06:23:10 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 61AE53B0403 for ; Thu, 22 Jun 2006 06:23:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15637-08 for ; Thu, 22 Jun 2006 06:23:09 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.195]) by menubar.gnome.org (Postfix) with ESMTP id 7534E3B045B for ; Thu, 22 Jun 2006 06:23:08 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so321629wxc for ; Thu, 22 Jun 2006 03:23:07 -0700 (PDT) Received: by 10.70.14.14 with SMTP id 14mr2842980wxn; Thu, 22 Jun 2006 03:23:07 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 03:23:07 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 12:23:07 +0200 From: "Milosz Derezynski" To: "Josef Spillner" Subject: Re: MLQ (Media Library Query) file format and mime type proposal In-Reply-To: <200606221139.41836.spillner@kde.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3405_33193106.1150971787566" References: <200606221139.41836.spillner@kde.org> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.443 tagged_above=-999 required=2 tests=[AWL=-0.496, BAYES_00=-2.599, HTML_10_20=1.351, HTML_MESSAGE=0.001, MIME_BASE64_NO_NAME=0.224, SPF_PASS=-0.001, TW_XD=0.077] X-Spam-Score: -1.443 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 10:23:10 -0000 ------=_Part_3405_33193106.1150971787566 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline WWVhaCB3ZWxsIGp1c3QgdG8gc3RheSB3aXRoaW4gdGhlIGZvY3VzIG9mIGEgbXVzaWMgbGlicmFy eSwgdGhlcmUgaGFzIHRvIGJlCnNvbWV0aGluZwp0aGF0IGRvZXMgdGhlIHJlc29sdXRpb24uCgpP TkUgcG9zc2libGUgb3B0aW9uIHdvdWxkIGJlIHRvIHNwZWNpZnkgYSBELUJVUyBpbnRlcmZhY2Ug bmFtZSwgYW5kIGEgaGF2ZQpzaW1wbGUgbGF1bmNoZXIuCgpBbGwgYXBwcyBzdXBwb3J0aW5nIE1M UXMgd291bGQgaGF2ZSB0byBoYXZlIGEgbWluaW1hbCBjb21tb24gc3Vic2V0Cm9mIEQtQlVTIGlu dGVyZmFjZXJ5IHRvIGFsbG93IHRoaXMga2luZCBvZiBxdWVyeSB0byBiZSBzZW50IHRvIHRoZW0g aW4gc29tZQp3YXkKKHNvbWV0aGluZyBsaWtlIGFuIEFkZFVyaSBjYWxsIG1pZ2h0IGp1c3Qgc3Vm ZmljZSksIHRoZW4gdGhlIGxhdW5jaGVyIHdvdWxkCmJhc2ljYWxseQpjb25zaXN0IG9mIHN0YXJ0 aW5nIHRoZSByZWxldmFudCBhcGxsaWNhdGlvbiB0cm91Z2ggRC1CVVMgYWN0aXZhdGlvbiwgYW5k CnRoZW4gcGFzcyBvbgp0aGUgYWN0dWFsIHF1ZXJ5IHRvIGl0LgoKKFdlIGhhdmUgYSBkdW1teSBt ZXRob2QgIlN0YXJ0dXAiIG9uIG91ciBELUJVUyBpZmFjZSB3aGljaApkb2VzIG5vdGhpbmcsIGJ1 dCBjYXVzZXMgRC1CVVMgdG8gc3RhcnQgdXAgQk1QLiBUaGUgcmVhc29uaW5nIGlzIHRoYXQgd2UK aGF2ZSBvbmUgbWFpbgpiaW5hcnkgYW5kIG9uZSAicmVtb3RlIiBiaW5hcnksIHdoaWNoIGlzIHRo b3VnaCBzZXQgc28gdGhhdCBpdCBpcyBwZXJjZWl2ZWQKYXMgYmVpbmcgdGhlIG1haW4KYmluYXJ5 LCBhcyBpbiBpdCdzIGluIC91c3IvYmluLCB3aGVyZWFzIHRoZSAtYmluIChtYWluKSBiaW5hcnkg aXMgaW4KL3Vzci9saWJleGVjLiBUaGUgcmVhc29uCmlzIHNvIHRoYXQgd2UgaGF2ZSBhIGxpZ2h0 d2VpZ2h0IHJlbW90ZSBhcHAgdGhhdCBjYW4gcGVyZm9ybSBhY3Rpb25zIG9uIHRoZQptYWluIGJp bmFyeQphbmQgZG9uJ3QgaGF2ZSB0byBoYXZlIHRoZSBtYWluIGFwcCBiZSBjYXBhYmxlIG9mIGJl aW5nIGEgY2xpZW50IHRvIGl0J3Mgb3duCnNlcnZlcgphbmQgaGF2ZSBhbGwgdGhlIHN0YXJ0dXAg c2hpenpsZSBnb2luZyBqdXN0IHRvIHBlcmZvcm0gYSBjZXJ0YWluIHJlbW90ZQpvcGVyYXRpb24p LgoKRm9yIGV4YW1wbGUgeW91J2QgaGF2ZToKcXVlcnk6Ly9vcmcuYmVlcG1lZGlhcGxheWVyLmJt cC8/YXJ0aXN0PUFpciZBbGJ1bT1Nb29uJTIwU2FmYXJpCgpUaGUgc2NyaXB0LCBvciBiZSBpdCBh IGJpbmFyeSwgbGV0J3MgY2FsbCBpdCAicGxheS1tbHEiLCB3b3VsZCBsYXVuY2ggdGhlCnBsYXll ciB3aXRoIHRoZSBzcGVjaWZpZWQgaW50ZXJmYWNlIGFuZCBwYXNzIGl0IHRoZSBhY3R1YWwgcXVl cnkuCgpfQW5vdGhlcl8gcG9zc2liaWxpdHksIGFsdGhvdWdoIHRoaXMgd291bGQgcmVxdWlyZSBw bGF5ZXJzIHRoYXQgY2FuIHdvcmsKd2l0aAptdXRhYmxlIHBsYXlsaXN0cyBsaWtlIEJNUCwgaXMg dGhhdCBpdCB3b3VsZCBwYXNzIHRoZSBxdWVyeSBvbiB0byBlLmcuCnNvbWV0aGluZwpsaWtlIFRy YWNrZXIgb3Igc29tZSBvdGhlciBpbmRleGVyLCB3aGljaCB3b3VsZCB0aGVuIGV4ZWN1dGUgdGhl IHF1ZXJ5IGFuZApfSVRfIHdvdWxkIHRoZW4gc3RhcnQgdGhlIHBsYXllciBzcGVjaWZpZWQgYnkg dGhlIGludGVyZmFjZSBhbmQgcGFzcyBpdAphbG9uZyB0aGUKcmVzdWx0aW5nIFVSSXMuCgotLSBN aWxvc3oKCk9uIDYvMjIvMDYsIEpvc2VmIFNwaWxsbmVyIDxzcGlsbG5lckBrZGUub3JnPiB3cm90 ZToKPgo+IEFsbGUgMTE6MjUsIGdpb3ZlZMOsLCAyMi4gZ2l1Z25vIDIwMDYsIE1pbG9zeiBEZXJl enluc2tpIGhhIHNjcml0dG86Cj4gPiBTaW5jZSB0aGlzIGlzIHZlcnkgY29tbW9uLCBhbmQgaGF2 aW5nIHRoZSBkaXNjdXNzaW9ucyBhYm91dCBhIGNvbW1vbgo+IG11c2ljCj4gPiBkYXRhYmFzZSBp biBtaW5kLCB0aGlzIHNlZW1zIGxpa2UgYSB1c2VmdWwgcHJvcG9zYWwsIHNpbmNlIGl0IGlzIG5v dAo+IHBsYXllcgo+ID4gc3BlY2lmaWMuCj4KPiBJdCBpcyBub3QgZXZlbiBtdXNpYyBzcGVjaWZp Yy4gSSd2ZSB1c2VkIHF1ZXJ5Oi8vIFVSSXMgZm9yIGEgbG9uZyB0aW1lCj4gd2l0aAo+IG1ldGFz ZXJ2ZXJzLCBhbHRob3VnaCBvbmx5IGluIGEgcmVhZC1vbmx5IGNvbnRleHQsIHdoZXJlYXMgZm9y IHdyaXRlCj4gYWNjZXNzCj4gdGhlIChhbHRlcm5hdGl2ZSkgZnVsbC1ibG93biBYTUwgaW50ZXJm YWNlIGlzIHVzZWQuCj4KPiBUaGUgd2F5IGl0IGlzIHVzZWQgZm9yIHRoZSBtZXRhc2VydmVyIGlz IGxpa2UgcXVlcnk6Ly90eXBlL2NhdGVnb3J5LCB3aGVyZQo+IGUuZy4gdHlwZSB3b3VsZCBiZSB0 aGUgZ2VuZXJpYyBuYW1lIGZvciBhIHNlcnZlciAoc2F5LCAnZnJlZWNpdicgb3IKPiAnY3Vwc2Qn KQo+IGFuZCBjYXRlZ29yeSB3b3VsZCBiZSAnY29ubmVjdGlvbicgKHRvIGdldCBiYWNrIGEgY29u bmVjdGlvbiBVUkkpIG9yCj4gJ21ldGEnCj4gKHRvIGdldCBiYWNrIG90aGVyIG1ldGFzZXJ2ZXIg VVJJcyBmb3IgdGhlIHNhbWUgdHlwZSkuCj4gVXNpbmcgc3VjaCBhIHNjaGVtZSBtYWtlcyBhbiBh cHBsaWNhdGlvbiByZXNpc3RhbnQgYWdhaW5zdCBob3N0IG5hbWUKPiBjaGFuZ2VzCj4gaW4gdGhl IGxvbmcgcnVuLCBpLmUuIGl0IHdpbGwgcGljayB1cCBtb3Zpbmcgc2VydmVycyBhdXRvbWF0aWNh bGx5Lgo+Cj4gVGhpcyBpcyBwcm9iYWJseSBub3QgdGhlIHNhbWUgdGhpbmcgYXMgeW91ciBxdWVy eSwgYnV0IG9idmlvdXNseSBpdCdzIGFsc28KPiB1c2VkIHRvIHF1ZXJ5IGEgZGF0YWJhc2UgYmVo aW5kIGl0ICh3aGljaCBpcyBhIFhNTCBkYXRhYmFzZSBpbiBteSBjYXNlLAo+IGJ1dAo+IGNvdWxk IGJlIFNRTCBvciBhbnl0aGluZyBlbHNlIGZvciB0aGF0IG1hdHRlcikuIFNvIG1heWJlIGl0IG1h a2VzIHNlbnNlIHRvCj4gc3RhbmRhcmRpc2UgdGhpcyBpbiBhIGJyb2FkZXIgY29udGV4dC4KPgo+ IEtERSBSYWRpbyBTdGF0aW9uIGlzIG9uZSBleGFtcGxlIHdoZXJlIHRoaXMgaXMgdXNlZCAoaGEg LSBmb3VuZCBhIHJlbGF0aW9uCj4gdG8KPiBtdXNpYyEpLCBhbmQgdGhlIEdHWiBHYW1pbmcgWm9u ZSBwcm9qZWN0IGlzIGFub3RoZXIgb25lICh3aGVyZSBpdAo+IG9yaWdpbmF0ZWQKPiBzaW5jZSBt ZXRhc2VydmVycyBhcmUgY29tbW9ucGxhY2Ugd2l0aCBnYW1lIHNlcnZlcnMpLgo+Cj4gSm9zZWYK PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IHhkZyBt YWlsaW5nIGxpc3QKPiB4ZGdAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCj4gaHR0cDovL2xpc3RzLmZy ZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hkZwo+Cg== ------=_Part_3405_33193106.1150971787566 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline WWVhaCB3ZWxsIGp1c3QgdG8gc3RheSB3aXRoaW4gdGhlIGZvY3VzIG9mIGEgbXVzaWMgbGlicmFy eSwgdGhlcmUgaGFzIHRvIGJlIHNvbWV0aGluZzxicj50aGF0IGRvZXMgdGhlIHJlc29sdXRpb24u PGJyPjxicj5PTkUgcG9zc2libGUgb3B0aW9uIHdvdWxkIGJlIHRvIHNwZWNpZnkgYSBELUJVUyBp bnRlcmZhY2UgbmFtZSwgYW5kIGEgaGF2ZSBzaW1wbGUgbGF1bmNoZXIuPGJyPjxicj5BbGwgYXBw cyBzdXBwb3J0aW5nIE1MUXMgd291bGQgaGF2ZSB0byBoYXZlIGEgbWluaW1hbCBjb21tb24gc3Vi c2V0Cjxicj5vZiBELUJVUyBpbnRlcmZhY2VyeSB0byBhbGxvdyB0aGlzIGtpbmQgb2YgcXVlcnkg dG8gYmUgc2VudCB0byB0aGVtIGluIHNvbWUgd2F5PGJyPihzb21ldGhpbmcgbGlrZSBhbiBBZGRV cmkgY2FsbCBtaWdodCBqdXN0IHN1ZmZpY2UpLCB0aGVuIHRoZSBsYXVuY2hlciB3b3VsZCBiYXNp Y2FsbHk8YnI+Y29uc2lzdCBvZiBzdGFydGluZyB0aGUgcmVsZXZhbnQgYXBsbGljYXRpb24gdHJv dWdoIEQtQlVTIGFjdGl2YXRpb24sIGFuZCB0aGVuIHBhc3Mgb24KPGJyPnRoZSBhY3R1YWwgcXVl cnkgdG8gaXQuIDxicj48YnI+KFdlIGhhdmUgYSBkdW1teSBtZXRob2QgJnF1b3Q7U3RhcnR1cCZx dW90OyBvbiBvdXIgRC1CVVMgaWZhY2Ugd2hpY2g8YnI+ZG9lcyBub3RoaW5nLCBidXQgY2F1c2Vz IEQtQlVTIHRvIHN0YXJ0IHVwIEJNUC4gVGhlIHJlYXNvbmluZyBpcyB0aGF0IHdlIGhhdmUgb25l IG1haW48YnI+YmluYXJ5IGFuZCBvbmUgJnF1b3Q7cmVtb3RlJnF1b3Q7IGJpbmFyeSwgd2hpY2gg aXMgdGhvdWdoIHNldCBzbyB0aGF0IGl0IGlzIHBlcmNlaXZlZCBhcyBiZWluZyB0aGUgbWFpbgo8 YnI+YmluYXJ5LCBhcyBpbiBpdCdzIGluIC91c3IvYmluLCB3aGVyZWFzIHRoZSAtYmluIChtYWlu KSBiaW5hcnkgaXMgaW4gL3Vzci9saWJleGVjLiBUaGUgcmVhc29uPGJyPmlzIHNvIHRoYXQgd2Ug aGF2ZSBhIGxpZ2h0d2VpZ2h0IHJlbW90ZSBhcHAgdGhhdCBjYW4gcGVyZm9ybSBhY3Rpb25zIG9u IHRoZSBtYWluIGJpbmFyeTxicj5hbmQgZG9uJ3QgaGF2ZSB0byBoYXZlIHRoZSBtYWluIGFwcCBi ZSBjYXBhYmxlIG9mIGJlaW5nIGEgY2xpZW50IHRvIGl0J3Mgb3duIHNlcnZlcgo8YnI+YW5kIGhh dmUgYWxsIHRoZSBzdGFydHVwIHNoaXp6bGUgZ29pbmcganVzdCB0byBwZXJmb3JtIGEgY2VydGFp biByZW1vdGUgb3BlcmF0aW9uKS48YnI+PGJyPkZvciBleGFtcGxlIHlvdSdkIGhhdmU6PGJyPnF1 ZXJ5Oi8vb3JnLmJlZXBtZWRpYXBsYXllci5ibXAvP2FydGlzdD1BaXImYW1wO0FsYnVtPU1vb24l MjBTYWZhcmk8YnI+PGJyPlRoZSBzY3JpcHQsIG9yIGJlIGl0IGEgYmluYXJ5LCBsZXQncyBjYWxs IGl0ICZxdW90O3BsYXktbWxxJnF1b3Q7LCB3b3VsZCBsYXVuY2ggdGhlCjxicj5wbGF5ZXIgd2l0 aCB0aGUgc3BlY2lmaWVkIGludGVyZmFjZSBhbmQgcGFzcyBpdCB0aGUgYWN0dWFsIHF1ZXJ5Ljxi cj48YnI+X0Fub3RoZXJfIHBvc3NpYmlsaXR5LCBhbHRob3VnaCB0aGlzIHdvdWxkIHJlcXVpcmUg cGxheWVycyB0aGF0IGNhbiB3b3JrIHdpdGg8YnI+bXV0YWJsZSBwbGF5bGlzdHMgbGlrZSBCTVAs IGlzIHRoYXQgaXQgd291bGQgcGFzcyB0aGUgcXVlcnkgb24gdG8gCmUuZy4gc29tZXRoaW5nPGJy Pmxpa2UgVHJhY2tlciBvciBzb21lIG90aGVyIGluZGV4ZXIsIHdoaWNoIHdvdWxkIHRoZW4gZXhl Y3V0ZSB0aGUgcXVlcnkgYW5kPGJyPl9JVF8gd291bGQgdGhlbiBzdGFydCB0aGUgcGxheWVyIHNw ZWNpZmllZCBieSB0aGUgaW50ZXJmYWNlIGFuZCBwYXNzIGl0IGFsb25nIHRoZTxicj5yZXN1bHRp bmcgVVJJcy48YnI+PGJyPi0tIE1pbG9zejxicj48YnI+CjxkaXY+PHNwYW4gY2xhc3M9ImdtYWls X3F1b3RlIj5PbiA2LzIyLzA2LCA8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+Sm9zZWYgU3Bp bGxuZXI8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86c3BpbGxuZXJAa2RlLm9yZyI+c3BpbGxuZXJA a2RlLm9yZzwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv dGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFy Z2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4KQWxsZSAxMToyNSwg Z2lvdmVkw6wsIDIyLiBnaXVnbm8gMjAwNiwgTWlsb3N6IERlcmV6eW5za2kgaGEgc2NyaXR0bzo8 YnI+Jmd0OyBTaW5jZSB0aGlzIGlzIHZlcnkgY29tbW9uLCBhbmQgaGF2aW5nIHRoZSBkaXNjdXNz aW9ucyBhYm91dCBhIGNvbW1vbiBtdXNpYzxicj4mZ3Q7IGRhdGFiYXNlIGluIG1pbmQsIHRoaXMg c2VlbXMgbGlrZSBhIHVzZWZ1bCBwcm9wb3NhbCwgc2luY2UgaXQgaXMgbm90IHBsYXllcgo8YnI+ Jmd0OyBzcGVjaWZpYy48YnI+PGJyPkl0IGlzIG5vdCBldmVuIG11c2ljIHNwZWNpZmljLiBJJ3Zl IHVzZWQgcXVlcnk6Ly8gVVJJcyBmb3IgYSBsb25nIHRpbWUgd2l0aDxicj5tZXRhc2VydmVycywg YWx0aG91Z2ggb25seSBpbiBhIHJlYWQtb25seSBjb250ZXh0LCB3aGVyZWFzIGZvciB3cml0ZSBh Y2Nlc3M8YnI+dGhlIChhbHRlcm5hdGl2ZSkgZnVsbC1ibG93biBYTUwgaW50ZXJmYWNlIGlzIHVz ZWQuCjxicj48YnI+VGhlIHdheSBpdCBpcyB1c2VkIGZvciB0aGUgbWV0YXNlcnZlciBpcyBsaWtl IHF1ZXJ5Oi8vdHlwZS9jYXRlZ29yeSwgd2hlcmU8YnI+ZS5nLiB0eXBlIHdvdWxkIGJlIHRoZSBn ZW5lcmljIG5hbWUgZm9yIGEgc2VydmVyIChzYXksICdmcmVlY2l2JyBvciAnY3Vwc2QnKTxicj5h bmQgY2F0ZWdvcnkgd291bGQgYmUgJ2Nvbm5lY3Rpb24nICh0byBnZXQgYmFjayBhIGNvbm5lY3Rp b24gVVJJKSBvciAnbWV0YScKPGJyPih0byBnZXQgYmFjayBvdGhlciBtZXRhc2VydmVyIFVSSXMg Zm9yIHRoZSBzYW1lIHR5cGUpLjxicj5Vc2luZyBzdWNoIGEgc2NoZW1lIG1ha2VzIGFuIGFwcGxp Y2F0aW9uIHJlc2lzdGFudCBhZ2FpbnN0IGhvc3QgbmFtZSBjaGFuZ2VzPGJyPmluIHRoZSBsb25n IHJ1biwgaS5lLiBpdCB3aWxsIHBpY2sgdXAgbW92aW5nIHNlcnZlcnMgYXV0b21hdGljYWxseS48 YnI+PGJyPlRoaXMgaXMgcHJvYmFibHkgbm90IHRoZSBzYW1lIHRoaW5nIGFzIHlvdXIgcXVlcnks IGJ1dCBvYnZpb3VzbHkgaXQncyBhbHNvCjxicj51c2VkIHRvIHF1ZXJ5IGEgZGF0YWJhc2UgYmVo aW5kIGl0ICh3aGljaCBpcyBhIFhNTCBkYXRhYmFzZSBpbiBteSBjYXNlLCBidXQ8YnI+Y291bGQg YmUgU1FMIG9yIGFueXRoaW5nIGVsc2UgZm9yIHRoYXQgbWF0dGVyKS4gU28gbWF5YmUgaXQgbWFr ZXMgc2Vuc2UgdG88YnI+c3RhbmRhcmRpc2UgdGhpcyBpbiBhIGJyb2FkZXIgY29udGV4dC48YnI+ PGJyPktERSBSYWRpbyBTdGF0aW9uIGlzIG9uZSBleGFtcGxlIHdoZXJlIHRoaXMgaXMgdXNlZCAo aGEgLSBmb3VuZCBhIHJlbGF0aW9uIHRvCjxicj5tdXNpYyEpLCBhbmQgdGhlIEdHWiBHYW1pbmcg Wm9uZSBwcm9qZWN0IGlzIGFub3RoZXIgb25lICh3aGVyZSBpdCBvcmlnaW5hdGVkPGJyPnNpbmNl IG1ldGFzZXJ2ZXJzIGFyZSBjb21tb25wbGFjZSB3aXRoIGdhbWUgc2VydmVycykuPGJyPjxicj5K b3NlZjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj54ZGcgbWFpbGluZyBsaXN0Cjxicj48YSBocmVmPSJtYWlsdG86eGRnQGxpc3RzLmZyZWVkZXNr dG9wLm9yZyI+eGRnQGxpc3RzLmZyZWVkZXNrdG9wLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cDov L2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hkZyI+aHR0cDovL2xpc3Rz LmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hkZzwvYT48YnI+PC9ibG9ja3F1b3Rl PjwvZGl2Pjxicj4K ------=_Part_3405_33193106.1150971787566-- From jamiemcc@blueyonder.co.uk Thu Jun 22 06:41:17 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 687D03B0251 for ; Thu, 22 Jun 2006 06:41:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17075-06 for ; Thu, 22 Jun 2006 06:41:15 -0400 (EDT) Received: from smtp-out5.blueyonder.co.uk (smtp-out5.blueyonder.co.uk [195.188.213.8]) by menubar.gnome.org (Postfix) with ESMTP id 74F7B3B021B for ; Thu, 22 Jun 2006 06:41:15 -0400 (EDT) Received: from [172.23.170.145] (helo=anti-virus03-08) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1FtMca-0004xo-T2; Thu, 22 Jun 2006 11:41:12 +0100 Received: from [62.30.198.187] (helo=[62.30.198.187]) by asmtp-out2.blueyonder.co.uk with esmtpa (Exim 4.52) id 1FtMcZ-0001pP-Rp; Thu, 22 Jun 2006 11:41:11 +0100 Message-ID: <449A73D1.6030401@blueyonder.co.uk> Date: Thu, 22 Jun 2006 11:41:21 +0100 From: Jamie McCracken User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Milosz Derezynski Subject: Re: MLQ: Followup References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.459 tagged_above=-999 required=2 tests=[AWL=0.141, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.459 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 10:41:17 -0000 Milosz Derezynski wrote: > What i forgot to mention: > > One benefit of MLQs over 'regular' playlists at least with BMP 2 is that > i've introduced a concept of keeping track of tracks across mount point > changes which basically works like this: > > BMP stores for each file the HAL volume and device UDI, and the VRP > (Volume Relative Path), that is, the path stripped off the mount point root. > Whenever it seems that a file is missing, it checks whether the volume > UDI of this file is still present on the system, and if so, gathers the > new mount point, and adjusts the URI of this > file in the library (this obiviously only works with tracks from the > library only anyway since only there we can reliably store the HAL > volume/device UDI and the VRP). > > This means practically: > > - Mount your music to /music > - Start BMP > - Add music from /music to the library > - Quit BMP > - Remount /music to e.g. /old_music > - Start BMP > - Use the library as before. Whenever BMP finds a file is missing, it > will correct the URI on-the-fly as long as the volume is mounted at all > on the system (and has an UDI to begin with; problem cases here are > network volumes, NFS and SMBFS) > > So the benefit of an MLQ is that unlike a static playlist, you can be > rather sure that no matter where you really move the music, BMP will > always be able to find it. > > Downsides/doesn't-works: > > - There is no volume UDI available > - You make a regular 'move' (mv), and not just a remount > > In the context of having a common music database, or something like > Tracker, this seems very useful (Jamie: Hence my urge to add HAL > volume/device UDI per file to the metadata). Im quite happy to add this as metadata to tracker and even get tracker to hide stuff based on it (using hal) but it still needs to be part of the uri for a music file (otherwise we wont be able to uniquely identify the files) -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ From jamiemcc@blueyonder.co.uk Thu Jun 22 06:52:34 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 93DEE3B031A for ; Thu, 22 Jun 2006 06:52:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17877-10 for ; Thu, 22 Jun 2006 06:52:32 -0400 (EDT) Received: from smtp-out5.blueyonder.co.uk (smtp-out5.blueyonder.co.uk [195.188.213.8]) by menubar.gnome.org (Postfix) with ESMTP id 66C8B3B0262 for ; Thu, 22 Jun 2006 06:52:32 -0400 (EDT) Received: from [172.23.170.140] (helo=anti-virus02-07) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1FtMnX-0007Tp-4T; Thu, 22 Jun 2006 11:52:31 +0100 Received: from [62.30.198.187] (helo=[62.30.198.187]) by asmtp-out1.blueyonder.co.uk with esmtpa (Exim 4.52) id 1FtMnU-0001TX-7r; Thu, 22 Jun 2006 11:52:28 +0100 Message-ID: <449A7676.6060309@blueyonder.co.uk> Date: Thu, 22 Jun 2006 11:52:38 +0100 From: Jamie McCracken User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Milosz Derezynski Subject: Re: MLQ (Media Library Query) file format and mime type proposal References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.422 tagged_above=-999 required=2 tests=[AWL=0.101, BAYES_00=-2.599, SPF_PASS=-0.001, TW_RQ=0.077] X-Spam-Score: -2.422 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 10:52:34 -0000 Milosz Derezynski wrote: > Hi, > > I'm one of the main authors of BMP 2 (still being worked on), and along > the way of reworking our library, i came across the idea of encoding > library queries as URIs, which may look like this: > > "query:///?artist=Air&album=Moon%20Safari" > > BMP 2 has a plugin archicture which is a small VFS on it's own, and we > treat certain things as "containers" (i.e. they "contain" URIs, like PLS > playlists, XSPF, M3U, etc). > Now i thought it might be not a bad idea to create a playlist format > with these query URLs, and i've called it "MLQ" for media library query. > In theory, it's not even > application specific. The keys (identifiers), like artist, album, etc, > are all based on GStreamer tag identifiers. (They could be maybe adapted > to http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , > but it seems insufficient and doesn't specify certain items, like > musicbrainz metadata, which GST does). Tracker's metadata spec does (http://freedesktop.org/wiki/Standards/shared-filemetadata-spec) > > So i've called this file format "MLQ", with the extension .mlq, created > a mime package file for it: > > > > > Media Library Query List > > > > > > > > Adding a file of this type to BMPx, or just a plain query:/// URI itself > causes a library query and appending of the relevant items to the > tracklist (BMP is currently mostly based on the concept of a mutable > playlist to which items can be added from various sources, unlike e.g. > RB which has mostly immutable "Playlists", but allows for custom queues). > > Another example is: > > query:///?artist=Air&album=Moon%20Safari&title=La%20Femme%20d'Argent > query:///?artist=Air&album=Moon%20Safari&title=Sexy%20Boy > query:///?artist=Air&album=Moon%20Safari&title=All%20I%20Need > query:///?artist=Air&album=Moon%20Safari&title=Kelly,%20Watch%20The%20Stars! > query:///?artist=Air&album=Moon%20Safari&title=Talisman > query:///?artist=Air&album=Moon%20Safari&title=Remember > query:///?artist=Air&album=Moon%20Safari&title=You%20Make%20It%20Easy > query:///?artist=Air&album=Moon%20Safari&title=Ce%20Matin%20La > query:///?artist=Air&album=Moon%20Safari&title=New%20Star%20In%20The%20Sky > query:///?artist=Air&album=Moon%20Safari&title=Le%20Voyage%20De%20Penelope > > Or it might just be: > > query:///?genre=Jazz > > Since this is very common, and having the discussions about a common > music database in mind, this seems like a useful proposal, since it is > not player specific. > This ships currently with BMP 2/BMPx SVN, and while i will ship this > with the 0.20 release (end-July) anyway, what does everyone think of > this in a broader context (common music database, etc)? Could be interesting as an alternative to rdf query that tracker uses but rdf query is a *standard* and is the WC3's recommended means of querying metadata. A more compact version of the xml based rdf query language is sparql (http://www.w3.org/TR/rdf-sparql-query/) and is also a candidate for standardisation. I guess its going to be fun deciding which to use (I will go with the flow) -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ From doclivingston@gmail.com Thu Jun 22 07:00:08 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 966243B038B for ; Thu, 22 Jun 2006 07:00:08 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18372-10 for ; Thu, 22 Jun 2006 07:00:05 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by menubar.gnome.org (Postfix) with ESMTP id 2DC8B3B00ED for ; Thu, 22 Jun 2006 07:00:05 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id f25so276546pyf for ; Thu, 22 Jun 2006 04:00:04 -0700 (PDT) Received: by 10.35.91.15 with SMTP id t15mr948347pyl; Thu, 22 Jun 2006 04:00:04 -0700 (PDT) Received: from alyrion.local ( [144.139.19.209]) by mx.gmail.com with ESMTP id w28sm110735pyc.2006.06.22.04.00.02; Thu, 22 Jun 2006 04:00:04 -0700 (PDT) Subject: Re: MLQ: Followup From: "James \"Doc\" Livingston" To: gnome-multimedia@gnome.org In-Reply-To: References: Content-Type: text/plain Date: Thu, 22 Jun 2006 20:59:59 +1000 Message-Id: <1150973999.5186.17.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.317 tagged_above=-999 required=2 tests=[AWL=0.283, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.317 X-Spam-Level: X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: doclivingston@gmail.com List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 11:00:08 -0000 On Thu, 2006-06-22 at 11:32 +0200, Milosz Derezynski wrote: > One benefit of MLQs over 'regular' playlists at least with BMP 2 is > that i've introduced a concept of keeping track of tracks across mount > point changes which basically works like this: > So the benefit of an MLQ is that unlike a static playlist, you can be > rather sure that no matter where you really move the music, BMP will > always be able to find it. I'm a bit confused about how "HAL UDI + partial path" is related to the MLQ idea. To me they seem fairly orthogonal. However using HAL UDIs is a good idea. Most apps currently use the URI as it's unique identifier and the method of finding the actual file, we could decide that the common db would use a as the unique id/location method. > Downsides/doesn't-works: > - There is no volume UDI available If this is a permanent thing, e.g. a non-HAL system or a http:// resource, then we could say that a null UDI and the full uri would be used instead. If it's temporary, e.g. HAL isn't running, or isn't detecting the device properly, then it's probably more complicated. Dealing with the fact that the users music is stored as and we don't know the URI would be funky. Perhaps we could say all db entries have the field, and a "last known"/non-HAL location field. > - You make a regular 'move' (mv), and not just a remount That is different again, and is probably best solved with audio fingerprinting, and/or embedding unique metadata in the file. Cheers. James "Doc" Livingston -- If USENET is anarchy, IRC is a paranoid schizophrenic after 6 days on speed. -- Chris "Saundo" Saunderson in asr. From doclivingston@gmail.com Thu Jun 22 07:04:28 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CFF783B0254 for ; Thu, 22 Jun 2006 07:04:28 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18854-05 for ; Thu, 22 Jun 2006 07:04:27 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by menubar.gnome.org (Postfix) with ESMTP id 0309C3B05B2 for ; Thu, 22 Jun 2006 07:04:26 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id f28so267516pyf for ; Thu, 22 Jun 2006 04:04:26 -0700 (PDT) Received: by 10.35.82.15 with SMTP id j15mr949278pyl; Thu, 22 Jun 2006 04:04:26 -0700 (PDT) Received: from alyrion.local ( [144.139.19.209]) by mx.gmail.com with ESMTP id w66sm860753pyw.2006.06.22.04.04.24; Thu, 22 Jun 2006 04:04:26 -0700 (PDT) Subject: Re: MLQ (Media Library Query) file format and mime type proposal From: "James \"Doc\" Livingston" To: gnome-multimedia@gnome.org In-Reply-To: References: Content-Type: text/plain Date: Thu, 22 Jun 2006 21:04:21 +1000 Message-Id: <1150974261.5186.22.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.319 tagged_above=-999 required=2 tests=[AWL=0.281, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.319 X-Spam-Level: X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: doclivingston@gmail.com List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 11:04:29 -0000 On Thu, 2006-06-22 at 11:25 +0200, Milosz Derezynski wrote: > I'm one of the main authors of BMP 2 (still being worked on), and > along the way of reworking our library, i came across the idea of > encoding library queries as URIs, which may look like this: > > "query:///?artist=Air&album=Moon%20Safari" > Adding a file of this type to BMPx, or just a plain query:/// URI > itself causes a library query and appending of the relevant items to > the tracklist (BMP is currently mostly based on the concept of a > mutable playlist to which items can be added from various sources, > unlike e.g. RB which has mostly immutable "Playlists", but allows for > custom queues). I'm a bit confused as to what this is actually for. Is it meant for saving "smart playlist"-type (or other db queries) things to disk? If so, it's probably better to use one of the existing query formats. If we want to use XML, then RDF (which is what Tracker uses for all it's queries) is probably as good as anything. James "Doc" Livingston -- "The Web brings people together because no matter what kind of a twisted sexual mutant you happen to be, you've got millions of pals out there. Type in 'Find people that have sex with goats that are on fire' and the computer will ask, 'Specify type of goat.'" -- Rich Jeni From internalerror@gmail.com Thu Jun 22 07:35:27 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BBE833B064F for ; Thu, 22 Jun 2006 07:35:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20711-02 for ; Thu, 22 Jun 2006 07:35:26 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.197]) by menubar.gnome.org (Postfix) with ESMTP id 1F4E83B0528 for ; Thu, 22 Jun 2006 07:35:26 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so334141wxc for ; Thu, 22 Jun 2006 04:35:26 -0700 (PDT) Received: by 10.70.65.10 with SMTP id n10mr2935604wxa; Thu, 22 Jun 2006 04:35:25 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 04:35:25 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 13:35:25 +0200 From: "Milosz Derezynski" To: doclivingston@gmail.com Subject: Re: MLQ: Followup In-Reply-To: <1150973999.5186.17.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3961_29338319.1150976125920" References: <1150973999.5186.17.camel@localhost.localdomain> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.246 tagged_above=-999 required=2 tests=[AWL=0.353, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.246 X-Spam-Level: Cc: gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 11:35:27 -0000 ------=_Part_3961_29338319.1150976125920 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/22/06, James Doc Livingston wrote: If it's temporary, e.g. HAL isn't running, or isn't detecting the device > properly, then it's probably more complicated. Dealing with the fact > that the users music is stored as and we don't know the URI > would be funky. Perhaps we could say all db entries have the > field, and a "last known"/non-HAL location field. > That's what i'm currently doing, i store the full URI, but also the UDI and the partial path, and in case HAL is not avaiable there is still the full URI present as a current resort. The ideal situation would be that HAL would be always available, would have UDIs for all volumes, and would run on all systems we need to run this to (Including let's say Solaris, etc), in which case it would be exactly what you said, one would need to only store the volume UDI and the partial path. Well anyway, repeating myself, just wanted to add that we also already store the full URI as a backup. ------=_Part_3961_29338319.1150976125920 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 6/22/06, James Doc Livingston <doclivingston@gmail.com> wrote:

If it's temporary, e.g. HAL isn't running, or isn't detecting the device
properly, then it's probably more complicated. Dealing with the fact
that the users music is stored as <UDI, path> and we don't know the URI
would be funky. Perhaps we could say all db entries have the <UDI, path>
field, and a "last known"/non-HAL location field.


That's what i'm currently doing, i store the full URI, but also the UDI and the partial path,
and in case HAL is not avaiable there is still the full URI present as a current resort.

The ideal situation would be that HAL would be always available, would have UDIs for all
volumes, and would run on all systems we need to run this to (Including let's say Solaris,
etc), in which case it would be exactly what you said, one would need to only store the volume
UDI and the partial path. Well anyway, repeating myself, just wanted to add that we also
already store the full URI as a backup.
------=_Part_3961_29338319.1150976125920-- From internalerror@gmail.com Thu Jun 22 12:04:05 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 802573B0830 for ; Thu, 22 Jun 2006 12:04:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07916-06 for ; Thu, 22 Jun 2006 12:04:01 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.201]) by menubar.gnome.org (Postfix) with ESMTP id 35C833B083F for ; Thu, 22 Jun 2006 12:01:33 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so373874wxc for ; Thu, 22 Jun 2006 09:01:32 -0700 (PDT) Received: by 10.70.83.20 with SMTP id g20mr3337015wxb; Thu, 22 Jun 2006 09:01:32 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 09:01:32 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 18:01:32 +0200 From: "Milosz Derezynski" To: "Frans Englich" Subject: Re: MLQ (Media Library Query) file format and mime type proposal In-Reply-To: <200606221419.00204.frans.englich@telia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7583_10781705.1150992092417" References: <200606221419.00204.frans.englich@telia.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.073 tagged_above=-999 required=2 tests=[AWL=0.152, BAYES_00=-2.599, HTML_30_40=0.374, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.073 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 16:04:05 -0000 ------=_Part_7583_10781705.1150992092417 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/22/06, Frans Englich wrote: > > On Thursday 22 June 2006 09:25, Milosz Derezynski wrote: > > Hi, > > > > I'm one of the main authors of BMP 2 (still being worked on), and along > the > > way of reworking our library, i came across the idea of encoding library > > queries as URIs, which may look like this: > > > > "query:///?artist=Air&album=Moon%20Safari" > > (Is that at all a valid URI? I'm not sure.) I think it is valid yes. First of all, one can't simply invent ones own URI scheme, because it causes > trouble. Especially, for such a generic name as "query". This document > discusses this further: > > http://developer.kde.org/policies/uri-guidelines.xhtml > > How is interoperability for "query" ensured? Is it specified? Not at all yet but because of that i'm asking on those 2 lists here now (xdg and gnome-multimedia), and furthermore i made some interoperability proposals, just 2 totally off my head but not totally out of place either. > BMP 2 has a plugin archicture which is a small VFS on it's own, and we > > treat certain things as "containers" (i.e. they "contain" URIs, like PLS > > playlists, XSPF, M3U, etc). > > Now i thought it might be not a bad idea to create a playlist format > with > > these query URLs, and i've called it "MLQ" for media library query. In > > theory, it's not even > > application specific. The keys (identifiers), like artist, album, etc, > are > > all based on GStreamer tag identifiers. (They could be maybe adapted to > > http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , > but > > it seems insufficient and doesn't specify certain items, like > musicbrainz > > metadata, which GST does). > > > > So i've called this file format "MLQ", with the extension .mlq, created > a > > mime package file for it: > > I think this highlights possible trouble. Anyone else who decides to > invent "query" will get detected as "Media Library Query List". All that's > needed to fix this is to use URIs properly. Yeah well that is problematic for them haha :P > However, I wouldn't invent a new URI scheme for this, it's too context > dependent. Music players & hardware(ipods, music players, music sharing > sites, and so on) is quite popular in western societies right now, but > next > year it's something different. Technologies, such as a URI scheme, > shouldn't > be hard coded on a specific use, it should be generic. > > Re-use existing technologies. There's plenty of work and research on meta > data > and querying data. Here's my suggestions: > > Express the format in XML. This has nothing to do with XML files("text"), > unless one wants to. It means the format is conceptually, on an "abstract" > level, described in XML which in turn opens up the door for all methods > XML > has. > > For example, one could use an XPointer fragment with an XPath scheme: > > file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album > = 'Safari')) > > If "music collections" cannot be located as files, invent a scheme which > can > identify them on this "abstract level." That is actually a very good idea (to use an XPath), but then again i would be abusing the file:/// scheme. What should it point to? Even if it would point to the physical location of the database file, in my specific case this would be ~/.local/share/bmpx/library.mlib, so file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz and @album='Safari')), then i would be basically still "making something up", as you cannot pass THIS uri to, say, a filemanager, and it would recognize it and do the correct thing. Now of course it won't recognize query:/// either, but i made 2 proposals which would spec query:/// in this way system wide. What i'm up to is that while your proposal with file seems more sane (and XPath/XPointer is certainly better than using a GET string, i might really consider changing the query:/// URI to use that), it actually is no different. Those kinds of file:/// URIs would need special treatment as well, and in fact, would cause even more headache possibly, as file:/// _IS_ already a known scheme which is already specced etc, etd. However, I would first assess RDF as suggested in this thread, since it is > designed exactly for things like this. Well RDF possibly, but i think i will never in my life use SPARQL. I took a look at it and i want these things if not neccessarily, then at least possibly, human editable, buit SPARQL is just way beyond the comprehension of taking a quick glance at the file and making some corrections. > > Cheers, > > Frans > -- Milosz ------=_Part_7583_10781705.1150992092417 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 6/22/06, Frans Englich <frans.englich@telia.com> wrote:
On Thursday 22 June 2006 09:25, Milosz Derezynski wrote:
> Hi,
>
> I'm one of the main authors of BMP 2 (still being worked on), and along the
> way of reworking our library, i came across the idea of encoding library
> queries as URIs, which may look like this:
>
> "query:///?artist=Air&album=Moon%20Safari"

(Is that at all a valid URI? I'm not sure.)

I think it is valid yes.

First of all, one can't simply invent ones own URI scheme, because it causes
trouble. Especially, for such a generic name as "query". This document
discusses this further:

http://developer.kde.org/policies/uri-guidelines.xhtml

How is interoperability for "query" ensured? Is it specified?

Not at all yet but  because of that i'm asking on those 2 lists here now (xdg
and gnome-multimedia), and furthermore i made some interoperability
proposals, just 2 totally off my head but not totally out of place either.
 

> BMP 2 has a plugin archicture which is a small VFS on it's own, and we
> treat certain things as "containers" (i.e. they "contain" URIs, like PLS
> playlists, XSPF, M3U, etc).
> Now i thought it might be not a bad idea to create a playlist format with
> these query URLs, and i've called it "MLQ" for media library query. In
> theory, it's not even
> application specific. The keys (identifiers), like artist, album, etc, are
> all based on GStreamer tag identifiers. (They could be maybe adapted to
> http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but
> it seems insufficient and doesn't specify certain items, like musicbrainz
> metadata, which GST does).
>
> So i've called this file format "MLQ", with the extension .mlq, created a
> mime package file for it:

I think this highlights possible trouble. Anyone else who decides to
invent "query" will get detected as "Media Library Query List". All that's
needed to fix this is to use URIs properly.

Yeah well that is problematic for them haha :P
 
However, I wouldn't invent a new URI scheme for this, it's too context
dependent. Music players & hardware(ipods, music players, music sharing
sites, and so on) is quite popular in western societies right now, but next
year it's something different. Technologies, such as a URI scheme, shouldn't
be hard coded on a specific use, it should be generic.

Re-use existing technologies. There's plenty of work and research on meta data
and querying data. Here's my suggestions:

Express the format in XML. This has nothing to do with XML files("text"),
unless one wants to. It means the format is conceptually, on an "abstract"
level, described in XML which in turn opens up the door for all methods XML
has.

For example, one could use an XPointer fragment with an XPath scheme:

file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album
= 'Safari'))

If "music collections" cannot be located as files, invent a scheme which can
identify them on this "abstract level."


That is actually a very good idea (to use an XPath), but then again i would be abusing
the file:/// scheme. What should it point to? Even if it would point to the physical location
of the database file, in my specific case this would be ~/.local/share/bmpx/library.mlib,
so file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz
and @album='Safari')), then i would be basically still "making something up", as you cannot
pass THIS uri to, say, a filemanager, and it would recognize it and do the correct thing.

Now of course it won't recognize query:/// either, but i made 2 proposals which would spec
query:/// in this way system wide.

What i'm up to is that while your proposal with file seems
more sane (and XPath/XPointer is certainly better than using a GET string, i might really
consider changing the query:/// URI to use that), it actually is no different. Those kinds of
file:/// URIs would need special treatment as well, and in fact, would cause even more headache
possibly, as file:/// _IS_ already a known scheme which is already specced etc, etd.
 

However, I would first assess RDF as suggested in this thread, since it is
designed exactly for things like this.

Well RDF possibly, but i think i will never in  my life use SPARQL. I took a look at it
and i want these things if not neccessarily, then at least possibly, human editable,
buit SPARQL is just way beyond the comprehension of taking a quick glance at the
file and making some corrections.
 

Cheers,

                Frans


-- Milosz
------=_Part_7583_10781705.1150992092417-- From internalerror@gmail.com Thu Jun 22 12:13:45 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5FD223B0389 for ; Thu, 22 Jun 2006 12:13:45 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08581-05 for ; Thu, 22 Jun 2006 12:13:43 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.205]) by menubar.gnome.org (Postfix) with ESMTP id B81413B01D2 for ; Thu, 22 Jun 2006 12:13:42 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so375754wxc for ; Thu, 22 Jun 2006 09:13:42 -0700 (PDT) Received: by 10.70.18.10 with SMTP id 10mr3379733wxr; Thu, 22 Jun 2006 09:13:42 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 09:13:41 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 18:13:41 +0200 From: "Milosz Derezynski" To: "Frans Englich" Subject: Re: MLQ (Media Library Query) file format and mime type proposal In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7734_19670285.1150992821952" References: <200606221419.00204.frans.englich@telia.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.079 tagged_above=-999 required=2 tests=[AWL=0.146, BAYES_00=-2.599, HTML_30_40=0.374, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.079 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 16:13:45 -0000 ------=_Part_7734_19670285.1150992821952 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I didn't know about tag URIs though, i'm taking a look at it now, thanks. On 6/22/06, Milosz Derezynski wrote: > > > > On 6/22/06, Frans Englich wrote: > > > > On Thursday 22 June 2006 09:25, Milosz Derezynski wrote: > > > Hi, > > > > > > I'm one of the main authors of BMP 2 (still being worked on), and > > along the > > > way of reworking our library, i came across the idea of encoding > > library > > > queries as URIs, which may look like this: > > > > > > "query:///?artist=Air&album=Moon%20Safari" > > > > (Is that at all a valid URI? I'm not sure.) > > > I think it is valid yes. > > First of all, one can't simply invent ones own URI scheme, because it > > causes > > trouble. Especially, for such a generic name as "query". This document > > discusses this further: > > > > http://developer.kde.org/policies/uri-guidelines.xhtml > > > > How is interoperability for "query" ensured? Is it specified? > > > Not at all yet but because of that i'm asking on those 2 lists here now > (xdg > and gnome-multimedia), and furthermore i made some interoperability > proposals, just 2 totally off my head but not totally out of place either. > > > > BMP 2 has a plugin archicture which is a small VFS on it's own, and we > > > treat certain things as "containers" (i.e. they "contain" URIs, like > > PLS > > > playlists, XSPF, M3U, etc). > > > Now i thought it might be not a bad idea to create a playlist format > > with > > > these query URLs, and i've called it "MLQ" for media library query. In > > > theory, it's not even > > > application specific. The keys (identifiers), like artist, album, etc, > > are > > > all based on GStreamer tag identifiers. (They could be maybe adapted > > to > > > http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , > > but > > > it seems insufficient and doesn't specify certain items, like > > musicbrainz > > > metadata, which GST does). > > > > > > So i've called this file format "MLQ", with the extension .mlq, > > created a > > > mime package file for it: > > > > I think this highlights possible trouble. Anyone else who decides to > > invent "query" will get detected as "Media Library Query List". All > > that's > > needed to fix this is to use URIs properly. > > > Yeah well that is problematic for them haha :P > > > > However, I wouldn't invent a new URI scheme for this, it's too context > > dependent. Music players & hardware(ipods, music players, music sharing > > sites, and so on) is quite popular in western societies right now, but > > next > > year it's something different. Technologies, such as a URI scheme, > > shouldn't > > be hard coded on a specific use, it should be generic. > > > > Re-use existing technologies. There's plenty of work and research on > > meta data > > and querying data. Here's my suggestions: > > > > Express the format in XML. This has nothing to do with XML > > files("text"), > > unless one wants to. It means the format is conceptually, on an > > "abstract" > > level, described in XML which in turn opens up the door for all methods > > XML > > has. > > > > For example, one could use an XPointer fragment with an XPath scheme: > > > > file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album > > = 'Safari')) > > > > If "music collections" cannot be located as files, invent a scheme which > > can > > identify them on this "abstract level." > > > > That is actually a very good idea (to use an XPath), but then again i > would be abusing > the file:/// scheme. What should it point to? Even if it would point to > the physical location > of the database file, in my specific case this would be > ~/.local/share/bmpx/library.mlib, > so file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz > > and @album='Safari')), then i would be basically still "making something > up", as you cannot > pass THIS uri to, say, a filemanager, and it would recognize it and do the > correct thing. > > Now of course it won't recognize query:/// either, but i made 2 proposals > which would spec > query:/// in this way system wide. > > What i'm up to is that while your proposal with file seems > more sane (and XPath/XPointer is certainly better than using a GET string, > i might really > consider changing the query:/// URI to use that), it actually is no > different. Those kinds of > file:/// URIs would need special treatment as well, and in fact, would > cause even more headache > possibly, as file:/// _IS_ already a known scheme which is already specced > etc, etd. > > > However, I would first assess RDF as suggested in this thread, since it is > > designed exactly for things like this. > > > Well RDF possibly, but i think i will never in my life use SPARQL. I took > a look at it > and i want these things if not neccessarily, then at least possibly, human > editable, > buit SPARQL is just way beyond the comprehension of taking a quick glance > at the > file and making some corrections. > > > > > > Cheers, > > > > Frans > > > > > -- Milosz > ------=_Part_7734_19670285.1150992821952 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I didn't know about tag URIs though, i'm taking a look at it now, thanks.

On 6/22/06, Milosz Derezynski <internalerror@gmail.com > wrote:


On 6/22/06, Frans Englich <frans.englich@telia.com> wrote:
On Thursday 22 June 2006 09:25, Milosz Derezynski wrote:
> Hi,
>
> I'm one of the main authors of BMP 2 (still being worked on), and along the
> way of reworking our library, i came across the idea of encoding library
> queries as URIs, which may look like this:
>
> "query:///?artist=Air&album=Moon%20Safari"

(Is that at all a valid URI? I'm not sure.)

I think it is valid yes.

First of all, one can't simply invent ones own URI scheme, because it causes
trouble. Especially, for such a generic name as "query". This document
discusses this further:

http://developer.kde.org/policies/uri-guidelines.xhtml

How is interoperability for "query" ensured? Is it specified?

Not at all yet but  because of that i'm asking on those 2 lists here now (xdg
and gnome-multimedia), and furthermore i made some interoperability
proposals, just 2 totally off my head but not totally out of place either.
 

> BMP 2 has a plugin archicture which is a small VFS on it's own, and we
> treat certain things as "containers" (i.e. they "contain" URIs, like PLS
> playlists, XSPF, M3U, etc).
> Now i thought it might be not a bad idea to create a playlist format with
> these query URLs, and i've called it "MLQ" for media library query. In
> theory, it's not even
> application specific. The keys (identifiers), like artist, album, etc, are
> all based on GStreamer tag identifiers. (They could be maybe adapted to
> http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but
> it seems insufficient and doesn't specify certain items, like musicbrainz
> metadata, which GST does).
>
> So i've called this file format "MLQ", with the extension .mlq, created a
> mime package file for it:

I think this highlights possible trouble. Anyone else who decides to
invent "query" will get detected as "Media Library Query List". All that's
needed to fix this is to use URIs properly.

Yeah well that is problematic for them haha :P
 
However, I wouldn't invent a new URI scheme for this, it's too context
dependent. Music players & hardware(ipods, music players, music sharing
sites, and so on) is quite popular in western societies right now, but next
year it's something different. Technologies, such as a URI scheme, shouldn't
be hard coded on a specific use, it should be generic.

Re-use existing technologies. There's plenty of work and research on meta data
and querying data. Here's my suggestions:

Express the format in XML. This has nothing to do with XML files("text"),
unless one wants to. It means the format is conceptually, on an "abstract"
level, described in XML which in turn opens up the door for all methods XML
has.

For example, one could use an XPointer fragment with an XPath scheme:

file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album
= 'Safari'))

If "music collections" cannot be located as files, invent a scheme which can
identify them on this "abstract level."


That is actually a very good idea (to use an XPath), but then again i would be abusing
the file:/// scheme. What should it point to? Even if it would point to the physical location
of the database file, in my specific case this would be ~/.local/share/bmpx/library.mlib,
so file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz
and @album='Safari')), then i would be basically still "making something up", as you cannot
pass THIS uri to, say, a filemanager, and it would recognize it and do the correct thing.

Now of course it won't recognize query:/// either, but i made 2 proposals which would spec
query:/// in this way system wide.

What i'm up to is that while your proposal with file seems
more sane (and XPath/XPointer is certainly better than using a GET string, i might really
consider changing the query:/// URI to use that), it actually is no different. Those kinds of
file:/// URIs would need special treatment as well, and in fact, would cause even more headache
possibly, as file:/// _IS_ already a known scheme which is already specced etc, etd.
 

However, I would first assess RDF as suggested in this thread, since it is
designed exactly for things like this.

Well RDF possibly, but i think i will never in  my life use SPARQL. I took a look at it
and i want these things if not neccessarily, then at least possibly, human editable,
buit SPARQL is just way beyond the comprehension of taking a quick glance at the
file and making some corrections.
 

Cheers,

                Frans


-- Milosz

------=_Part_7734_19670285.1150992821952-- From frans.englich@telia.com Thu Jun 22 10:05:56 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 164263B085B for ; Thu, 22 Jun 2006 10:05:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00797-01 for ; Thu, 22 Jun 2006 10:05:48 -0400 (EDT) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by menubar.gnome.org (Postfix) with ESMTP id 4FFD63B081B for ; Thu, 22 Jun 2006 10:05:38 -0400 (EDT) X-T2-Posting-ID: 2yF4ydxc0UI9xI7FHZPfog== X-Cloudmark-Score: 0.000000 [] Received: from 83.72.134.122.ip.tele2adsl.dk ([83.72.134.122] verified) by mailfe08.swip.net (CommuniGate Pro SMTP 5.0.8) with ESMTP id 217821068; Thu, 22 Jun 2006 16:05:36 +0200 From: Frans Englich To: xdg@lists.freedesktop.org Subject: Re: MLQ (Media Library Query) file format and mime type proposal Date: Thu, 22 Jun 2006 14:18:59 +0000 User-Agent: KMail/1.8.50 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606221419.00204.frans.englich@telia.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.051 tagged_above=-999 required=2 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_NUMERIC_HELO=1.5] X-Spam-Score: -1.051 X-Spam-Level: X-Mailman-Approved-At: Thu, 22 Jun 2006 12:45:56 -0400 Cc: gnome-multimedia@gnome.org, Milosz Derezynski X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 14:05:56 -0000 On Thursday 22 June 2006 09:25, Milosz Derezynski wrote: > Hi, > > I'm one of the main authors of BMP 2 (still being worked on), and along the > way of reworking our library, i came across the idea of encoding library > queries as URIs, which may look like this: > > "query:///?artist=Air&album=Moon%20Safari" (Is that at all a valid URI? I'm not sure.) First of all, one can't simply invent ones own URI scheme, because it causes trouble. Especially, for such a generic name as "query". This document discusses this further: http://developer.kde.org/policies/uri-guidelines.xhtml How is interoperability for "query" ensured? Is it specified? > BMP 2 has a plugin archicture which is a small VFS on it's own, and we > treat certain things as "containers" (i.e. they "contain" URIs, like PLS > playlists, XSPF, M3U, etc). > Now i thought it might be not a bad idea to create a playlist format with > these query URLs, and i've called it "MLQ" for media library query. In > theory, it's not even > application specific. The keys (identifiers), like artist, album, etc, are > all based on GStreamer tag identifiers. (They could be maybe adapted to > http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but > it seems insufficient and doesn't specify certain items, like musicbrainz > metadata, which GST does). > > So i've called this file format "MLQ", with the extension .mlq, created a > mime package file for it: I think this highlights possible trouble. Anyone else who decides to invent "query" will get detected as "Media Library Query List". All that's needed to fix this is to use URIs properly. However, I wouldn't invent a new URI scheme for this, it's too context dependent. Music players & hardware(ipods, music players, music sharing sites, and so on) is quite popular in western societies right now, but next year it's something different. Technologies, such as a URI scheme, shouldn't be hard coded on a specific use, it should be generic. Re-use existing technologies. There's plenty of work and research on meta data and querying data. Here's my suggestions: Express the format in XML. This has nothing to do with XML files("text"), unless one wants to. It means the format is conceptually, on an "abstract" level, described in XML which in turn opens up the door for all methods XML has. For example, one could use an XPointer fragment with an XPath scheme: file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album = 'Safari')) If "music collections" cannot be located as files, invent a scheme which can identify them on this "abstract level." However, I would first assess RDF as suggested in this thread, since it is designed exactly for things like this. In this way one doesn't have to invent a whole query language for music files. That's like inventing C++ for writing games, C++ for fixing bugs in word processors, C++ for writing editors, and so on. Cheers, Frans From internalerror@gmail.com Thu Jun 22 13:17:35 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 614C33B0693 for ; Thu, 22 Jun 2006 13:17:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12677-02 for ; Thu, 22 Jun 2006 13:17:34 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.201]) by menubar.gnome.org (Postfix) with ESMTP id 0CBD83B06C8 for ; Thu, 22 Jun 2006 13:17:33 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so385228wxc for ; Thu, 22 Jun 2006 10:17:33 -0700 (PDT) Received: by 10.70.110.18 with SMTP id i18mr3484207wxc; Thu, 22 Jun 2006 10:17:33 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 10:17:33 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 19:17:33 +0200 From: "Milosz Derezynski" To: "Frans Englich" Subject: Re: MLQ (Media Library Query) file format and mime type proposal In-Reply-To: <200606221419.00204.frans.englich@telia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8538_10618378.1150996653355" References: <200606221419.00204.frans.englich@telia.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.272 tagged_above=-999 required=2 tests=[AWL=0.327, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.272 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 17:17:35 -0000 ------=_Part_8538_10618378.1150996653355 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/22/06, Frans Englich wrote: > > On Thursday 22 June 2006 09:25, Milosz Derezynski wrote: > > I think this highlights possible trouble. Anyone else who decides to > invent "query" will get detected as "Media Library Query List". All that's > needed to fix this is to use URIs properly. > I've changed the file magic so that the first line has to be "#MLQ", and our MLQ exporter writes them like that and recognizes them only like that, and i've updated the mime XML spec to recognize them this way. This is no better or worse than "#EXTM3U" for .m3u playlists, so i don't think there is any problem here now. As for the URIs themselves, i wasn't yet speaking of "open" use of them (outside of .mlq files), but only within them, so this change of the file magic should prevent problems with anything else that might use a query:/// URI in their file formats. -- Milosz ------=_Part_8538_10618378.1150996653355 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 6/22/06, Frans Englich <frans.englich@telia.com> wrote:
On Thursday 22 June 2006 09:25, Milosz Derezynski wrote:

I think this highlights possible trouble. Anyone else who decides to
invent "query" will get detected as "Media Library Query List". All that's
needed to fix this is to use URIs properly.

I've changed the file magic so that the first line has to be "#MLQ", and our
MLQ exporter writes them like that and recognizes them only like that, and i've
updated the mime XML spec to recognize them this way.  This is no better or worse than
"#EXTM3U" for .m3u playlists, so i don't think there is any problem here now.
As for the URIs themselves, i wasn't yet speaking of "open" use of them (outside of .mlq files),
but only within them, so this change of the file magic should prevent problems with
anything else that might use a query:/// URI in their file formats.

-- Milosz
------=_Part_8538_10618378.1150996653355-- From doclivingston@gmail.com Wed Jun 7 10:49:16 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6DFBE3B0CC1 for ; Wed, 7 Jun 2006 10:49:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21939-01 for ; Wed, 7 Jun 2006 10:49:15 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.229]) by menubar.gnome.org (Postfix) with ESMTP id D14723B03C1 for ; Wed, 7 Jun 2006 10:49:14 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id 50so195010wri for ; Wed, 07 Jun 2006 07:49:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:reply-to:to:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=D3/oYUbzoxrxaC8A9PmKhslTLvhndfLfj1yY1UbjWdxPLOVTGGtYcu0ciGotAkdC9rpqkdcPnVZMxJ6dpbOroKn3+pabYkPihqGfxJAljTjii14F9PbbIilMLHmiNyw9SX693UyHiryeZOKfQoct7i10NaO3a8zimwOM5qcjmis= Received: by 10.65.232.13 with SMTP id j13mr502626qbr; Wed, 07 Jun 2006 07:49:14 -0700 (PDT) Received: from alyrion.local ( [144.139.19.99]) by mx.gmail.com with ESMTP id e14sm242982qba.2006.06.07.07.49.12; Wed, 07 Jun 2006 07:49:14 -0700 (PDT) From: "James \"Doc\" Livingston" To: gnome-multimedia@gnome.org Content-Type: text/plain Date: Thu, 08 Jun 2006 00:49:05 +1000 Message-Id: <1149691745.5417.19.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.309 tagged_above=-999 required=2 tests=[AWL=0.291, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.309 X-Spam-Level: Subject: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: doclivingston@gmail.com List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 14:49:16 -0000 G'day everyone, Currently various multi-media application behave differently when the "scrolling" (up/down arrow, page up/down mouse wheel) actions are performed on their seek slider. There have been bugs (at least 164351 and 330570) filed against several applications asking that they behave like others, and it would be good to have consistent behaviour. Essentially the questions is what should happen when the user performs these actions? Should the "up" actions seek forward in time, seek back in time, or do nothing? Currently Totem and Gnome Sound Recorder map "up" to seek forwards in time, Sound-Juicer and Rhythmbox map "up" to seek back in time, and Banshee and Muine don't seek when the user does this. Which is correct is a matter of debate, and when I started a discussion about this on #gnome-hackers (which obviously isn't filled with "average users") a while back, people seemed to be split roughly equally between the options. Some of the point for up=forwards are: * people associate up with increasing the time from the start Some of the point for up=backwards are: * people associate up with increasing the time remaining (only applicable if it's shown to the user) * people associate up with "going towards the start", like for documents/web pages Some of the point for taking no action: * these are "vertical" scroll events and the slider is horizontal, so should do nothing Regardless of which is generally considered "best", I think having it consistent between application is important. Cheers, James "Doc" Livingston -- [Request for the names of the kings who became Nazgul] Dashur, Daensir, Prantsur, Vicksinn, Comuet, Cupuid, Dondor, Blitsun, and Rodulf, Witch-King of Angmar. -- Joseph Michael Bay From hadess@hadess.net Wed Jun 7 10:58:17 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 067753B0272 for ; Wed, 7 Jun 2006 10:58:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22613-04 for ; Wed, 7 Jun 2006 10:58:16 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id EA5A23B03C4 for ; Wed, 7 Jun 2006 10:58:15 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57EwBfm003839; Wed, 7 Jun 2006 10:58:11 -0400 Received: from pobox.surrey.redhat.com (pobox.surrey.redhat.com [172.16.10.17]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57EwASg001552; Wed, 7 Jun 2006 10:58:10 -0400 Received: from bnocera.surrey.redhat.com (bnocera.surrey.redhat.com [172.16.10.53]) by pobox.surrey.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57Ew9om000601; Wed, 7 Jun 2006 15:58:09 +0100 From: Bastien Nocera To: doclivingston@gmail.com In-Reply-To: <1149691745.5417.19.camel@localhost.localdomain> References: <1149691745.5417.19.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8 Date: Wed, 07 Jun 2006 15:58:09 +0100 Message-Id: <1149692289.14668.24.camel@bnocera.surrey.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-27) Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.954 tagged_above=-999 required=2 tests=[AWL=-0.496, BAYES_00=-2.599, SPF_FAIL=1.142, SPF_HELO_PASS=-0.001] X-Spam-Score: -1.954 X-Spam-Level: Cc: gnome-multimedia@gnome.org Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 14:58:17 -0000 On Thu, 2006-06-08 at 00:49 +1000, James "Doc" Livingston wrote: > G'day everyone, > Essentially the questions is what should happen when the user performs > these actions? Should the "up" actions seek forward in time, seek back > in time, or do nothing? Same problem for the volume sliders by default. Obviously, I think that apps should seek forward in time with up, and backwards with down. And I also think that when scrolling down, the step should be shorter than when moving forward (because it makes it easier to find precise points in the timeline). Maybe we need to move things like the volume widget, and some "seek sliders" to a library like gnome-media? -- Bastien Nocera If I'm not challenged, I can do nothing. Maybe my next film will be in Japanese. -- Alejandro González Iñárittu From abockover@novell.com Wed Jun 7 11:08:04 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C6EB33B022D for ; Wed, 7 Jun 2006 11:08:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23164-09 for ; Wed, 7 Jun 2006 11:08:04 -0400 (EDT) Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.25.9.101]) by menubar.gnome.org (Postfix) with ESMTP id B3F5E3B0127 for ; Wed, 7 Jun 2006 11:08:03 -0400 (EDT) Received: from [192.168.0.101] (cpe-024-162-230-116.nc.res.rr.com [24.162.230.116]) by ms-smtp-02.southeast.rr.com (8.13.6/8.13.6) with ESMTP id k57F7xLC012187; Wed, 7 Jun 2006 11:07:59 -0400 (EDT) From: Aaron Bockover To: doclivingston@gmail.com In-Reply-To: <1149691745.5417.19.camel@localhost.localdomain> References: <1149691745.5417.19.camel@localhost.localdomain> Content-Type: text/plain Date: Wed, 07 Jun 2006 11:04:47 -0400 Message-Id: <1149692687.14205.10.camel@sledipus.rex> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.472 tagged_above=-999 required=2 tests=[AWL=-0.073, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2] X-Spam-Score: -2.472 X-Spam-Level: Cc: gnome-multimedia@gnome.org Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 15:08:05 -0000 On Thu, 2006-06-08 at 00:49 +1000, James "Doc" Livingston wrote: > Currently various multi-media application behave differently when the > "scrolling" (up/down arrow, page up/down mouse wheel) actions are > performed on their seek slider. There have been bugs (at least 164351 > and 330570) filed against several applications asking that they behave > like others, and it would be good to have consistent behaviour. Agreed. > Currently Totem and Gnome Sound Recorder map "up" to seek forwards in > time, Sound-Juicer and Rhythmbox map "up" to seek back in time, and > Banshee and Muine don't seek when the user does this. Banshee (and Muine?) seeks on CTRL+Left/Right. > Some of the point for up=forwards are: > * people associate up with increasing the time from the start > Time is usually displayed on the X axis... sliders for seeking are usually horizontal... so Up/Down keys for this mess with my mind > Some of the point for up=backwards are: > * people associate up with increasing the time remaining (only > applicable if it's shown to the user) > * people associate up with "going towards the start", like for > documents/web pages Again, for me it's more literal connection with visual objects... if I press the right arrow, I am scrolling my time graph "into the future." Volume is my Y axis. > Some of the point for taking no action: > * these are "vertical" scroll events and the slider is horizontal, so > should do nothing I don't think this is should be a no-action case. I think representations just should be "on-axis" (of course feelings are going to differ, this are just how I interpret position) >From a more technical (and possibly usability) standpoint, my objection to up/down is that it's used by and is more important to other widgets (our track views in Banshee/RB), meaning the slider needs focus for the keys to actually seek. In Banshee you can press CTRL+Left/Right anywhere and it seeks. Cheers, Aaron From rbultje@ronald.bitfreak.net Wed Jun 7 11:46:19 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3D92F3B04A2 for ; Wed, 7 Jun 2006 11:46:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26037-06 for ; Wed, 7 Jun 2006 11:46:15 -0400 (EDT) Received: from ms-smtp-01.rdc-nyc.rr.com (ms-smtp-01.rdc-nyc.rr.com [24.29.109.5]) by menubar.gnome.org (Postfix) with ESMTP id 8B1693B022D for ; Wed, 7 Jun 2006 11:46:15 -0400 (EDT) Received: from [192.168.0.103] (cpe-66-65-0-167.nyc.res.rr.com [66.65.0.167]) by ms-smtp-01.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id k57Fk2jY021579; Wed, 7 Jun 2006 11:46:13 -0400 (EDT) From: "Ronald S. Bultje" To: Bastien Nocera In-Reply-To: <1149692289.14668.24.camel@bnocera.surrey.redhat.com> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> Content-Type: text/plain Date: Wed, 07 Jun 2006 11:44:22 -0400 Message-Id: <1149695062.2855.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.561 tagged_above=-999 required=2 tests=[AWL=0.038, BAYES_00=-2.599] X-Spam-Score: -2.561 X-Spam-Level: Cc: gnome-multimedia@gnome.org Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 15:46:19 -0000 On Wed, 2006-06-07 at 15:58 +0100, Bastien Nocera wrote: > Maybe we need to move things like the volume widget, and some "seek > sliders" to a library like gnome-media? I would personally prefer libegg (or bacon, where the volume widget resides). I've never really seen gnome-media as a widget-library, but more like a bunch of applications and utilities. I totally don't mind each app making their own copy if such widgets, as long as they update their copy reasonably often. Cheers, Ronald From abockover@novell.com Wed Jun 7 11:58:56 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D43973B0411 for ; Wed, 7 Jun 2006 11:58:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26954-08 for ; Wed, 7 Jun 2006 11:58:56 -0400 (EDT) Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.25.9.101]) by menubar.gnome.org (Postfix) with ESMTP id 120B23B0D4B for ; Wed, 7 Jun 2006 11:58:56 -0400 (EDT) Received: from [192.168.0.101] (cpe-024-162-230-116.nc.res.rr.com [24.162.230.116]) by ms-smtp-02.southeast.rr.com (8.13.6/8.13.6) with ESMTP id k57FwrFL000910; Wed, 7 Jun 2006 11:58:54 -0400 (EDT) From: Aaron Bockover To: "Ronald S. Bultje" In-Reply-To: <1149695062.2855.2.camel@localhost.localdomain> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> <1149695062.2855.2.camel@localhost.localdomain> Content-Type: text/plain Date: Wed, 07 Jun 2006 11:55:41 -0400 Message-Id: <1149695742.15592.1.camel@sledipus.rex> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.473 tagged_above=-999 required=2 tests=[AWL=-0.074, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2] X-Spam-Score: -2.473 X-Spam-Level: Cc: gnome-multimedia@gnome.org, Bastien Nocera Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 15:58:57 -0000 On Wed, 2006-06-07 at 11:44 -0400, Ronald S. Bultje wrote: > On Wed, 2006-06-07 at 15:58 +0100, Bastien Nocera wrote: > > Maybe we need to move things like the volume widget, and some "seek > > sliders" to a library like gnome-media? > > I would personally prefer libegg (or bacon, where the volume widget > resides). I've never really seen gnome-media as a widget-library, but > more like a bunch of applications and utilities. > > I totally don't mind each app making their own copy if such widgets, as > long as they update their copy reasonably often. I agree here; bacon would probably be best if it were to be in a library, but I think applications providing copies is fine too. I wouldn't want to depend on bacon (or gnome-media) for a widget. --Aaron From hadess@hadess.net Wed Jun 7 12:02:02 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 001A03B0DF9 for ; Wed, 7 Jun 2006 12:02:02 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27399-05 for ; Wed, 7 Jun 2006 12:01:59 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 9822B3B0E10 for ; Wed, 7 Jun 2006 12:00:49 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57G0nE9001971; Wed, 7 Jun 2006 12:00:49 -0400 Received: from pobox.surrey.redhat.com (pobox.surrey.redhat.com [172.16.10.17]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57G0mZE021228; Wed, 7 Jun 2006 12:00:48 -0400 Received: from bnocera.surrey.redhat.com (bnocera.surrey.redhat.com [172.16.10.53]) by pobox.surrey.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57G0lTo006172; Wed, 7 Jun 2006 17:00:47 +0100 From: Bastien Nocera To: Aaron Bockover In-Reply-To: <1149695742.15592.1.camel@sledipus.rex> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> <1149695062.2855.2.camel@localhost.localdomain> <1149695742.15592.1.camel@sledipus.rex> Content-Type: text/plain Date: Wed, 07 Jun 2006 17:00:47 +0100 Message-Id: <1149696047.14668.35.camel@bnocera.surrey.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-27) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.953 tagged_above=-999 required=2 tests=[AWL=-0.495, BAYES_00=-2.599, SPF_FAIL=1.142, SPF_HELO_PASS=-0.001] X-Spam-Score: -1.953 X-Spam-Level: Cc: "Ronald S. Bultje" , gnome-multimedia@gnome.org Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 16:02:02 -0000 On Wed, 2006-06-07 at 11:55 -0400, Aaron Bockover wrote: > On Wed, 2006-06-07 at 11:44 -0400, Ronald S. Bultje wrote: > > On Wed, 2006-06-07 at 15:58 +0100, Bastien Nocera wrote: > > > Maybe we need to move things like the volume widget, and some "seek > > > sliders" to a library like gnome-media? > > > > I would personally prefer libegg (or bacon, where the volume widget > > resides). I've never really seen gnome-media as a widget-library, but > > more like a bunch of applications and utilities. > > > > I totally don't mind each app making their own copy if such widgets, as > > long as they update their copy reasonably often. > > I agree here; bacon would probably be best if it were to be in a > library, but I think applications providing copies is fine too. I > wouldn't want to depend on bacon (or gnome-media) for a widget. libbacon is a cut'n'paste library like libegg, so not a problem. -- Bastien Nocera Lucas has made a vacuous, boring, pretentious, retroactively destructive sequel. He has lost the plot. The man is a fool. -- Simon Pegg (on the Phantom Menace) From uraeus@linuxrising.org Fri Jun 9 10:13:15 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 91BCF3B01D8 for ; Fri, 9 Jun 2006 10:13:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29942-03 for ; Fri, 9 Jun 2006 10:13:14 -0400 (EDT) Received: from mx1.es6.egwn.net (server02.es6.egwn.net [195.10.6.12]) by menubar.gnome.org (Postfix) with ESMTP id E0C263B01BE for ; Fri, 9 Jun 2006 10:13:13 -0400 (EDT) Received: from [192.168.1.235] (core.fluendo.com [195.10.6.237]) by mx1.es6.egwn.net (Postfix) with ESMTP id 9E4AC4F81BC; Fri, 9 Jun 2006 16:13:11 +0200 (CEST) From: Christian Fredrik Kalager Schaller To: Bastien Nocera In-Reply-To: <1149696047.14668.35.camel@bnocera.surrey.redhat.com> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> <1149695062.2855.2.camel@localhost.localdomain> <1149695742.15592.1.camel@sledipus.rex> <1149696047.14668.35.camel@bnocera.surrey.redhat.com> Content-Type: text/plain Date: Fri, 09 Jun 2006 16:11:58 +0200 Message-Id: <1149862318.2356.36.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.397 tagged_above=-999 required=2 tests=[AWL=1.202, BAYES_00=-2.599] X-Spam-Score: -1.397 X-Spam-Level: Cc: "Ronald S. Bultje" , gnome-multimedia@gnome.org Subject: a general multimedia library - Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 14:13:15 -0000 Well the topic of having a multimedia widget library has been discussed multiple times and maybe now is the time to move on it? Currently there are multiple things I see that would be natural to put into such a library: a) the gconf schemas in gnome-media b) the playlist parser library in totem c) the seek sliders widgets mentioned here d) a simple to use GStreamer GTK+ video widget e) others things? Basically this library would/could contain things which are higher level our not directly in the scope of GStreamer. Or which is very GTK+/GNOME related. Christian On Wed, 2006-06-07 at 17:00 +0100, Bastien Nocera wrote: > On Wed, 2006-06-07 at 11:55 -0400, Aaron Bockover wrote: > > On Wed, 2006-06-07 at 11:44 -0400, Ronald S. Bultje wrote: > > > On Wed, 2006-06-07 at 15:58 +0100, Bastien Nocera wrote: > > > > Maybe we need to move things like the volume widget, and some "seek > > > > sliders" to a library like gnome-media? > > > > > > I would personally prefer libegg (or bacon, where the volume widget > > > resides). I've never really seen gnome-media as a widget-library, but > > > more like a bunch of applications and utilities. > > > > > > I totally don't mind each app making their own copy if such widgets, as > > > long as they update their copy reasonably often. > > > > I agree here; bacon would probably be best if it were to be in a > > library, but I think applications providing copies is fine too. I > > wouldn't want to depend on bacon (or gnome-media) for a widget. > > libbacon is a cut'n'paste library like libegg, so not a problem. > From rbultje@ronald.bitfreak.net Fri Jun 9 10:47:45 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B71663B0413 for ; Fri, 9 Jun 2006 10:47:45 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32342-10 for ; Fri, 9 Jun 2006 10:47:42 -0400 (EDT) Received: from ms-smtp-03.rdc-nyc.rr.com (ms-smtp-03.rdc-nyc.rr.com [24.29.109.7]) by menubar.gnome.org (Postfix) with ESMTP id 215673B0FF1 for ; Fri, 9 Jun 2006 10:47:42 -0400 (EDT) Received: from [192.168.0.103] (cpe-66-65-0-167.nyc.res.rr.com [66.65.0.167]) by ms-smtp-03.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id k59Eld9O019647; Fri, 9 Jun 2006 10:47:40 -0400 (EDT) From: "Ronald S. Bultje" To: Christian Fredrik Kalager Schaller In-Reply-To: <1149862318.2356.36.camel@localhost.localdomain> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> <1149695062.2855.2.camel@localhost.localdomain> <1149695742.15592.1.camel@sledipus.rex> <1149696047.14668.35.camel@bnocera.surrey.redhat.com> <1149862318.2356.36.camel@localhost.localdomain> Content-Type: text/plain Date: Fri, 09 Jun 2006 10:46:01 -0400 Message-Id: <1149864361.2869.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.563 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599] X-Spam-Score: -2.563 X-Spam-Level: Cc: gnome-multimedia@gnome.org, Bastien Nocera Subject: Re: a general multimedia library - Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 14:47:45 -0000 Hi, On Fri, 2006-06-09 at 16:11 +0200, Christian Fredrik Kalager Schaller wrote: > Well the topic of having a multimedia widget library has been discussed > multiple times and maybe now is the time to move on it? If someone believes that this would be useful and should be done, then that person should go ahead and do it. Ronald From thomas@apestaart.org Fri Jun 9 15:11:02 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 78FFA3B00E9 for ; Fri, 9 Jun 2006 15:11:02 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15077-08 for ; Fri, 9 Jun 2006 15:11:01 -0400 (EDT) Received: from mx1.es6.egwn.net (server02.es6.egwn.net [195.10.6.12]) by menubar.gnome.org (Postfix) with ESMTP id E94F03B0149 for ; Fri, 9 Jun 2006 15:11:00 -0400 (EDT) Received: from mx1.fr4.egwn.net (server07.fr4.egwn.net [62.39.85.77]) by mx1.es6.egwn.net (Postfix) with ESMTP id 0FC914F822C; Fri, 9 Jun 2006 21:10:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mx1.fr4.egwn.net (spiffy mail daemon) with ESMTP id CB4CC83BFD; Fri, 9 Jun 2006 21:10:47 +0200 (CEST) Received: from mx1.fr4.egwn.net ([127.0.0.1]) by localhost (server07.fr4.egwn.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22095-43; Fri, 9 Jun 2006 21:10:47 +0200 (CEST) Received: from thread.fluendo.lan (core.fluendo.com [195.10.6.237]) by mx1.fr4.egwn.net (spiffy mail daemon) with ESMTP id D8A3283BF8; Fri, 9 Jun 2006 21:10:46 +0200 (CEST) Received: from otto.amantes (thomas.fluendo.lan [192.168.1.10]) by thread.fluendo.lan (Postfix) with ESMTP id 8DDD1FE93; Fri, 9 Jun 2006 21:10:57 +0200 (CEST) Received: from otto.amantes (otto.amantes [127.0.0.1]) by otto.amantes (Postfix) with ESMTP id 9B95DEFC0D; Fri, 9 Jun 2006 21:11:00 +0200 (CEST) Content-Type: multipart/mixed; boundary="127.0.0.1.500.4863.1149880260.533.2" MIME-Version: 1.0 To: gstreamer-devel@lists.sourceforge.net, gstreamer-announce@lists.sourceforge.net, kde-multimedia@kde.org, gnome-multimedia@gnome.org Message-Id: <20060609191100.9B95DEFC0D@otto.amantes> Date: Fri, 9 Jun 2006 21:11:00 +0200 (CEST) From: thomas@apestaart.org X-Scanned: By amavis at egwn.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: Yes, score=2.06 tagged_above=-999 required=2 tests=[AWL=-1.482, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, MIME_BASE64_TEXT=1.885, NO_REAL_NAME=0.961, RCVD_IN_SBL=3.16] X-Spam-Score: 2.06 X-Spam-Level: ** X-Spam-Flag: YES Cc: Subject: RELEASE: GStreamer 0.10.7 'Soepeke, ik zie ou' X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 19:11:02 -0000 --127.0.0.1.500.4863.1149880260.533.2 Content-Type: text/plain This mail announces the release of GStreamer 0.10.7 'Soepeke, ik zie ou'. GStreamer is a streaming media framework that allows the construction of graphs of elements which operate on media data. Applications using this library can do anything from real-time sound processing over playing video to capturing audio, video, and even other types of media data. Its architecture allows for adding new data types or processing capabilities simply by installing new plug-ins. GStreamer is the core module, containing libraries, headers, the basic object hierarchy, and a set of media-agnostic core elements. For more information, see [http://gstreamer.freedesktop.org/modules/gstreamer.html] To file bugs, go to [http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer&component=gstreamer+%28core%29] --127.0.0.1.500.4863.1149880260.533.2 Content-Type: text/plain; name=RELEASE Content-Transfer-Encoding: base64 ClJlbGVhc2Ugbm90ZXMgZm9yIEdTdHJlYW1lcsKgMC4xMC43ICJTb2VwZWtlLCBpayB6aWUgb3Ui CiAgICAgICAgCgoKVGhlIEdTdHJlYW1lciB0ZWFtIGlzIHByb3VkIHRvIGFubm91bmNlIGEgbmV3 IHJlbGVhc2UKaW4gdGhlIDAuMTAueCBzdGFibGUgc2VyaWVzIG9mIHRoZQpjb3JlIG9mIHRoZSBH U3RyZWFtZXIgc3RyZWFtaW5nIG1lZGlhIGZyYW1ld29yay4KCgpUaGUgMC4xMC54IHNlcmllcyBp cyBhIHN0YWJsZSBzZXJpZXMgdGFyZ2V0ZWQgYXQgZW5kIHVzZXJzLgpJdCBpcyBub3QgQVBJIG9y IEFCSSBjb21wYXRpYmxlIHdpdGggdGhlIHN0YWJsZSAwLjgueCBzZXJpZXMuCkl0IGlzLCBob3dl dmVyLCBwYXJhbGxlbCBpbnN0YWxsYWJsZSB3aXRoIHRoZSAwLjgueCBzZXJpZXMuCgoKVGhlIDAu MTAueCBzZXJpZXMgaGFzIGJlZW4gcmV3b3JrZWQgZm9yIHRocmVhZHNhZmV0eS4gIEl0IGFsc28g ZmVhdHVyZXMKdmFyaW91cyBmZWF0dXJlIGFkZGl0aW9ucyBhbmQgZW5jaGFuY2VtZW50cy4KCgpU aGlzIG1vZHVsZSwgZ3N0cmVhbWVyLCBvbmx5IGNvbnRhaW5zIGNvcmUgZnVuY3Rpb25hbGl0eS4K Rm9yIGFjdHVhbCBtZWRpYSBwbGF5YmFjaywgeW91IHdpbGwgbmVlZCBvdGhlciBtb2R1bGVzLgoK Z3N0LXBsdWdpbnMtYmFzZQpjb250YWlucyBhIGJhc2ljIHNldCBvZiB3ZWxsLXN1cHBvcnRlZCBw bHVnLWlucwpnc3QtcGx1Z2lucy1nb29kCmNvbnRhaW5zIGEgc2V0IG9mIHdlbGwtc3VwcG9ydGVk IHBsdWctaW5zIHVuZGVyIG91ciBwcmVmZXJyZWQgbGljZW5zZQpnc3QtcGx1Z2lucy11Z2x5CmNv bnRhaW5zIGEgc2V0IG9mIHdlbGwtc3VwcG9ydGVkIHBsdWctaW5zLCBidXQgbWlnaHQgcG9zZSBw cm9ibGVtcyBmb3IKICAgIGRpc3RyaWJ1dG9ycwpnc3QtcGx1Z2lucy1iYWQKY29udGFpbnMgYSBz ZXQgb2YgbGVzcyBzdXBwb3J0ZWQgcGx1Zy1pbnMgdGhhdCBoYXZlbid0IHBhc3NlZCB0aGUKICAg IHJpZ29yb3VzIHF1YWxpdHkgdGVzdGluZyB3ZSBleHBlY3QKCgoKICAKRmVhdHVyZXMgb2YgdGhp cyByZWxlYXNlCiAgICAKICAgICAgKiBQYXJhbGxlbCBpbnN0YWxsYWJpbGl0eSB3aXRoIDAuOC54 IHNlcmllcwogICAgICAqIFRocmVhZHNhZmUgZGVzaWduIGFuZCBBUEkKICAgICAgKiBSZWdpc3Ry eSBjYWNoZSB1cGRhdGluZyBpcyBub3cgZG9uZSBpbiBhIGZvcmssIHNvIG5vIHBsdWdpbnMgYXJl IGxlZnQgb3BlbmVkCiAgICAgICogTmV3IHZlcnNpb24gb2YgZGF0YSBwcm90b2NvbCBub3cgc2Vy aWFsaXplcyBldmVudHMKICAgICAgKiBxdWV1ZSBmaXhlcwogICAgICAqIHdpbjMyIGZpeGVzCgpC dWdzIGZpeGVkIGluIHRoaXMgcmVsZWFzZQogICAgCiAgICAgICogMzM4MzM1IDogW3BhdGNoXSBt ZW1sZWFrIGluIGdzdC11dGlscy5jIChsZWFrIHBhZHMgZnJvbSBpdGVyYXRvcikKICAgICAgKiAz NDM1OTggOiB1bmRlZmluZWQgc3ltYm9sIGluIGNvcmVpbmRleGVycyB3aGVuIHVzaW5nIC0tZGlz YWJsZS1sb2EuLi4KICAgICAgKiAzMzY5MjkgOiBHc3RDb2xsZWN0UGFkcyBkb2VzIG5vdCBjbGVh ci9yZXNldCBzZWdtZW50IGluZm8gYWZ0ZXIgZmwuLi4KICAgICAgKiAzMzcxMDAgOiBbZmFrZXNp bmtdIGFkZCAiIHByZXJvbGwtaGFuZG9mZiAiIHNpZ25hbAogICAgICAqIDMzOTkxOCA6IEdzdFRh Z1NldHRlciBtZXJnZS1tb2RlIGRlc2NyaXB0aW9uIHVuY2xlYXIsIGFuZCBpbXBsZW1lbi4uLgog ICAgICAqIDM0MDUwMSA6IFtmaWxlc3JjXSBnaXZlIHByaW1hcnkgcmFuawogICAgICAqIDM0MTY2 MiA6IGdzdC1sYXVuY2ggcHJpbnRfdGFncygpIGZpeAogICAgICAqIDM0MjIzOCA6IEFQSTogZ3N0 X2VsZW1lbnRfc2Vla19zaW1wbGUKICAgICAgKiAzNDIzMjEgOiBHU1RfUVVFUllfUE9TSVRJT04g ZmFpbHMgaWYgR3N0QmFzZVNyYyBpbiBnZXRfcmFuZ2UgbW9kZQogICAgICAqIDM0Mjc3NyA6IHJl YnVpbGRpbmcgdGhlIHJlZ2lzdHJ5IGxlYXZlcyBhbGwgcGx1Z2lucyBpbiBtZW1vcnkKICAgICAg KiAzNDI4MjAgOiBnc3RuZXRjbGllbnRjbG9jay5jKDQ1Myk6IHNlcnZhZGRyIHVzZWQgYmVmb3Jl IHNldAogICAgICAqIDM0MzA1NyA6IGdzdC1sYXVuY2gtMC4xMCBzZWdmYXVsdHMgd2hlbiBwYXNz ZWQgZ3N0LXBsdWdpbi1wYXRoIGFuZC4uLgogICAgICAqIDM0MzM0MSA6IFtBUEldIGFkZCBHU1Rf VEFHX1BSRVZJRVdfSU1BR0UKICAgICAgKiAzNDM4MjcgOiBsZWFrIGluIGdzdF9pbmRleF9ndHlw ZV9yZXNvbHZlcgogICAgICAqIDM0MzkyOSA6IFVzZSBvZiAvLyBpbiBwdWJsaWMgaGVhZGVyCiAg ICAgICogMzQzOTg4IDogZGF0YSBwcm90b2NvbCBuZWVkcyBleHRlbmRpbmcgdG8gaGFuZGxlIGV2 ZW50cyBiZXR0ZXIKICAgICAgKiAzNDE0NzkgOiBUb28gbWFueSBwbHVnaW5zIGxvYWRlZCBldmVu IGZvciB1cC10by1kYXRlIHJlZ2lzdHJ5CiAgICAgICogMzQzMzM0IDogR3N0Q29sbGVjdFBhZHMg dGVzdHN1aXRlIGFuZCBmaXhlcwogICAgICAqIDM0MzUzOCA6IEdzdENvbGxlY3RQYWRzIGRvZXNu J3QgcmVzZXQgRU9TIGZpZWxkcyB3aGVuIHN0b3BwZWQKCkFQSSBjaGFuZ2VkIGluIHRoaXMgcmVs ZWFzZQogICAgIAoKLSBBUEkgYWRkaXRpb25zOgogICAgCiogZ3N0X2VsZW1lbnRfc2Vla19zaW1w bGUoKQoqIEdTVF9GTE9XX0NVU1RPTV9TVUNDRVNTCiogR1NUX0ZMT1dfQ1VTVE9NX0VSUk9SCiog R1NUX0ZMT1dfSVNfU1VDQ0VTUwoqIGdzdF9jb2xsZWN0X3BhZHNfc2V0X2ZsdXNoaW5nKCkKKiBH U1RfVEFHX1BSRVZJRVdfSU1BR0UKKiBnc3RfZHBfY3JjKCkKKiBHc3REUFBhY2tldGl6ZXIKKiBH c3REUFZlcnNpb24KKiBHc3RGYWtlU2luazo6cHJlcm9sbC1oYW5kb2ZmCiogR3N0RmFrZVNpbms6 OnVzZS1tbWFwCgpEb3dubG9hZAoKWW91IGNhbiBmaW5kIHNvdXJjZSByZWxlYXNlcyBvZiBnc3Ry ZWFtZXIgaW4gdGhlIGRvd25sb2FkIGRpcmVjdG9yeToKaHR0cDovL2dzdHJlYW1lci5mcmVlZGVz a3RvcC5vcmcvc3JjL2dzdHJlYW1lci8KCkdTdHJlYW1lciBIb21lcGFnZQoKTW9yZSBkZXRhaWxz IGNhbiBiZSBmb3VuZCBvbiB0aGUgcHJvamVjdCdzIHdlYnNpdGU6Cmh0dHA6Ly9nc3RyZWFtZXIu ZnJlZWRlc2t0b3Aub3JnLwoKU3VwcG9ydCBhbmQgQnVncwoKV2UgdXNlIEdOT01FJ3MgYnVnemls bGEgZm9yIGJ1ZyByZXBvcnRzIGFuZCBmZWF0dXJlIHJlcXVlc3RzOgpodHRwOi8vYnVnemlsbGEu Z25vbWUub3JnL2VudGVyX2J1Zy5jZ2k/cHJvZHVjdD1HU3RyZWFtZXIKCkRldmVsb3BlcnMKCkNW UyBpcyBob3N0ZWQgb24gY3ZzLmZyZWVkZXNrdG9wLm9yZy4KQWxsIGNvZGUgaXMgaW4gQ1ZTIGFu ZCBjYW4gYmUgY2hlY2tlZCBvdXQgZnJvbSB0aGVyZS4KSW50ZXJlc3RlZCBkZXZlbG9wZXJzIG9m IHRoZSBjb3JlIGxpYnJhcnksIHBsdWctaW5zLCBhbmQgYXBwbGljYXRpb25zIHNob3VsZApzdWJz Y3JpYmUgdG8gdGhlIGdzdHJlYW1lci1kZXZlbCBsaXN0LiBJZiB0aGVyZSBpcyBzdWZmaWNpZW50 IGludGVyZXN0IHdlCndpbGwgY3JlYXRlIG1vcmUgbGlzdHMgYXMgbmVjZXNzYXJ5LgoKICAgICAg ICAKQXBwbGljYXRpb25zCgpBcHBsaWNhdGlvbnMgcG9ydGVkIHRvIEdTdHJlYW1lciAwLjEwIGlu Y2x1ZGUgVG90ZW0sIFJoeXRobUJveCwgU291bmQtSnVpY2VyLApHbm9tZSBNZWRpYSwgRmx1bW90 aW9uLCBBbWFyb2ssIEphbWJvcmVlLCBQaXRpdmksIElzdGFuYnVsLCBBbm5vQW1wLCBFbGlzYSwg YW5kIG90aGVycy4KTGV0IHVzIGtub3cgaWYgeW91IHdhbnQgdG8gYmUgYWRkZWQgdG8gdGhpcyBs aXN0LgoKICAKQ29udHJpYnV0b3JzIHRvIHRoaXMgcmVsZWFzZQogICAgCiAgICAgICogQWxlc3Nh bmRybyBEZWNpbmEKICAgICAgKiBFZHdhcmQgSGVydmV5CiAgICAgICogSmFuIFNjaG1pZHQKICAg ICAgKiBKdWxpZW4gTW91dHRlCiAgICAgICogTHV0eiBNdWVsbGVyCiAgICAgICogTWFyayBOYXV3 ZWxhZXJ0cwogICAgICAqIE1pY2hhZWwgU21pdGgKICAgICAgKiBTZWJhc3RpZW4gTW91dHRlCiAg ICAgICogU3RlZmFuIEtvc3QKICAgICAgKiBUaG9tYXMgVmFuZGVyIFN0aWNoZWxlCiAgICAgICog VGltLVBoaWxpcHAgTcO8bGxlcgogICAgICAqIFdpbSBUYXltYW5zCiAgICAgICogWmFoZWVyIEFi YmFzIE1lcmFsaQrCoA== --127.0.0.1.500.4863.1149880260.533.2-- From thomas@apestaart.org Fri Jun 9 15:11:49 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5C75C3B00E9 for ; Fri, 9 Jun 2006 15:11:49 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15136-05 for ; Fri, 9 Jun 2006 15:11:48 -0400 (EDT) Received: from mx1.es6.egwn.net (server02.es6.egwn.net [195.10.6.12]) by menubar.gnome.org (Postfix) with ESMTP id 0A9E03B0149 for ; Fri, 9 Jun 2006 15:11:47 -0400 (EDT) Received: from mx1.fr4.egwn.net (server07.fr4.egwn.net [62.39.85.77]) by mx1.es6.egwn.net (Postfix) with ESMTP id 5C5134F822C; Fri, 9 Jun 2006 21:11:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mx1.fr4.egwn.net (spiffy mail daemon) with ESMTP id 20D9883BFD; Fri, 9 Jun 2006 21:11:35 +0200 (CEST) Received: from mx1.fr4.egwn.net ([127.0.0.1]) by localhost (server07.fr4.egwn.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23574-43; Fri, 9 Jun 2006 21:11:34 +0200 (CEST) Received: from thread.fluendo.lan (core.fluendo.com [195.10.6.237]) by mx1.fr4.egwn.net (spiffy mail daemon) with ESMTP id 33DE383BF8; Fri, 9 Jun 2006 21:11:34 +0200 (CEST) Received: from otto.amantes (thomas.fluendo.lan [192.168.1.10]) by thread.fluendo.lan (Postfix) with ESMTP id 071AFFE93; Fri, 9 Jun 2006 21:11:45 +0200 (CEST) Received: from otto.amantes (otto.amantes [127.0.0.1]) by otto.amantes (Postfix) with ESMTP id 35F55EFC0D; Fri, 9 Jun 2006 21:11:48 +0200 (CEST) Content-Type: multipart/mixed; boundary="127.0.0.1.500.5548.1149880308.216.2" MIME-Version: 1.0 To: gstreamer-devel@lists.sourceforge.net, gstreamer-announce@lists.sourceforge.net, kde-multimedia@kde.org, gnome-multimedia@gnome.org Message-Id: <20060609191148.35F55EFC0D@otto.amantes> Date: Fri, 9 Jun 2006 21:11:48 +0200 (CEST) From: thomas@apestaart.org X-Scanned: By amavis at egwn.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: Yes, score=2.198 tagged_above=-999 required=2 tests=[AWL=-1.575, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, MIME_BASE64_TEXT=1.885, NO_REAL_NAME=0.961, RCVD_IN_SBL=3.16, TW_EG=0.077, TW_EV=0.077, TW_FD=0.077] X-Spam-Score: 2.198 X-Spam-Level: ** X-Spam-Flag: YES Cc: Subject: RELEASE: GStreamer Base Plug-ins 0.10.8 'Moar gij zie mij nie' X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 19:11:49 -0000 --127.0.0.1.500.5548.1149880308.216.2 Content-Type: text/plain This mail announces the release of GStreamer Base Plug-ins 0.10.8 'Moar gij zie mij nie'. GStreamer Base Plug-ins is a well-groomed and well-maintained collection of GStreamer plug-ins and elements, spanning the range of possible types of elements one would want to write for GStreamer. It also contains helper libraries and base classes useful for writing elements. A wide range of video and audio decoders, encoders, and filters are included. For more information, see [http://gstreamer.freedesktop.org/modules/gst-plugins-base.html] To file bugs, go to [http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer&component=gst-plugins-base] --127.0.0.1.500.5548.1149880308.216.2 Content-Type: text/plain; name=RELEASE Content-Transfer-Encoding: base64 ClJlbGVhc2Ugbm90ZXMgZm9yIEdTdHJlYW1lciBCYXNlIFBsdWctaW5zwqAwLjEwLjggIk1vYXIg Z2lqIHppZXQgbWlqIG5pZSIKICAgICAgICAKCgpUaGUgR1N0cmVhbWVyIHRlYW0gaXMgcHJvdWQg dG8gYW5ub3VuY2UgYSBuZXcgcmVsZWFzZQppbiB0aGUgMC4xMC54IHN0YWJsZSBzZXJpZXMgb2Yg dGhlCkdTdHJlYW1lciBCYXNlIFBsdWctaW5zLgoKClRoZSAwLjEwLnggc2VyaWVzIGlzIGEgc3Rh YmxlIHNlcmllcyB0YXJnZXRlZCBhdCBlbmQgdXNlcnMuCkl0IGlzIG5vdCBBUEkgb3IgQUJJIGNv bXBhdGlibGUgd2l0aCB0aGUgc3RhYmxlIDAuOC54IHNlcmllcy4KSXQgaXMsIGhvd2V2ZXIsIHBh cmFsbGVsIGluc3RhbGxhYmxlIHdpdGggdGhlIDAuOC54IHNlcmllcy4KCgoKVGhpcyBtb2R1bGUg Y29udGFpbnMgYSBzZXQgb2YgcmVmZXJlbmNlIHBsdWdpbnMsIGJhc2UgY2xhc3NlcyBmb3Igb3Ro ZXIKcGx1Z2lucywgYW5kIGhlbHBlciBsaWJyYXJpZXMuCgpUaGlzIG1vZHVsZSBpcyBrZXB0IHVw LXRvLWRhdGUgdG9nZXRoZXIgd2l0aCB0aGUgY29yZSBkZXZlbG9wbWVudHMuICBFbGVtZW50Cndy aXRlcnMgc2hvdWxkIGxvb2sgYXQgdGhlIGVsZW1lbnRzIGluIHRoaXMgbW9kdWxlIGFzIGEgcmVm ZXJlbmNlIGZvcgp0aGVpciBkZXZlbG9wbWVudC4KClRoaXMgbW9kdWxlIGNvbnRhaW5zIGVsZW1l bnRzIGZvciwgYW1vbmcgb3RoZXJzOgoKICBkZXZpY2UgcGx1Z2luczogeCh2KWltYWdlc2luaywg YWxzYSwgdjRsc3JjLCBjZHBhcmFub2lhCiAgY29udGFpbmVyczogb2dnCiAgY29kZWNzOiB2b3Ji aXMsIHRoZW9yYQogIHRleHQ6IHRleHRvdmVybGF5LCBzdWJwYXJzZQogIHNvdXJjZXM6IGF1ZGlv dGVzdHNyYywgdmlkZW90ZXN0c3JjLCBnbm9tZXZmc3NyYwogIG5ldHdvcms6IHRjcAogIHR5cGVm aW5kCiAgYXVkaW8gcHJvY2Vzc2luZzogYXVkaW9jb252ZXJ0LCBhZGRlciwgYXVkaW9yYXRlLCBh dWRpb3NjYWxlLCB2b2x1bWUKICB2aXN1YWxpc2F0aW9uOiBsaWJ2aXN1YWwKICB2aWRlbyBwcm9j ZXNzaW5nOiBmZm1wZWdjb2xvcnNwYWNlCiAgYWdncmVnYXRlIGVsZW1lbnRzOiBkZWNvZGViaW4s IHBsYXliaW4KCgpPdGhlciBtb2R1bGVzIGNvbnRhaW5pbmcgcGx1Zy1pbnMgYXJlOgoKCmdzdC1w bHVnaW5zLWdvb2QKY29udGFpbnMgYSBzZXQgb2Ygd2VsbC1zdXBwb3J0ZWQgcGx1Zy1pbnMgdW5k ZXIgb3VyIHByZWZlcnJlZCBsaWNlbnNlCmdzdC1wbHVnaW5zLXVnbHkKY29udGFpbnMgYSBzZXQg b2Ygd2VsbC1zdXBwb3J0ZWQgcGx1Zy1pbnMsIGJ1dCBtaWdodCBwb3NlIHByb2JsZW1zIGZvcgog ICAgZGlzdHJpYnV0b3JzCmdzdC1wbHVnaW5zLWJhZApjb250YWlucyBhIHNldCBvZiBsZXNzIHN1 cHBvcnRlZCBwbHVnLWlucyB0aGF0IGhhdmVuJ3QgcGFzc2VkIHRoZQogICAgcmlnb3JvdXMgcXVh bGl0eSB0ZXN0aW5nIHdlIGV4cGVjdAoKCgogIApGZWF0dXJlcyBvZiB0aGlzIHJlbGVhc2UKICAg IAogICAgICAqIFBhcmFsbGVsIGluc3RhbGxhYmlsaXR5IHdpdGggMC44Lnggc2VyaWVzCiAgICAg ICogVGhyZWFkc2FmZSBkZXNpZ24gYW5kIEFQSQogICAgICAqIGFsc2FzaW5rIHByb2JpbmcgZml4 ZXMKICAgICAgKiB4dmltYWdlc2luayBlcnJvciByZXBvcnRpbmcgZml4ZXMKICAgICAgKiBzdWJ0 aXRsZSBmaXhlcwogICAgICAqIGFkZGVyIGZpeGVzCiAgICAgICogdm9yYmlzIG11bHRpY2hhbm5l bCBmaXhlcwogICAgICAqIG11bHRpZmRzaW5rIHN0cmVhbWhlYWRlciBmaXhlcwoKQnVncyBmaXhl ZCBpbiB0aGlzIHJlbGVhc2UKICAgIAogICAgICAqIDE2OTkzNiA6IFtzdWJwYXJzZV0gc3VwcG9y dCBmb3IgU0FNSSBzdWJ0aXRsZXMKICAgICAgKiAzMTUzMTIgOiBHc3RyZWFtZXIgWHYgdXNlcyBS R0IgaW5zdGVhZCBvZiBZVVYuCiAgICAgICogMzM0MDAyIDogdmlkZW80bGludXggc2hvdWxkbid0 IGRlcGVuZCBvbiBYIGluIGNvbmZpZ3VyZSBzY3JpcHQKICAgICAgKiAzMzY4ODEgOiBbbGlidmlz dWFsXSBhZGRpdGlvbmFsIHN1cHBvcnQgZm9yIGxpYnZpc3VhbC0wLjQKICAgICAgKiAzMzc1NDQg OiBbeHZpbWFnZXNpbmtdIEludGVybmFsIEVycm9yIHdoZW4gaW1hZ2UgaXMgdG9vIGxhcmdlCiAg ICAgICogMzM5NTIwIDogW3N1YnBhcnNlXSBhZGQgIiBlbmNvZGluZyAiIHByb3BlcnR5CiAgICAg ICogMzQwOTA5IDogW2Fsc2FzaW5rXSBjYW4ndCBlbmFibGUgc3BkaWYgb3V0cHV0CiAgICAgICog MzQxNTQyIDogc29tZSB1c2VycyBoYXZlIGFuIGFzc2VydGlvbiBmYWlsZWQ6IChHU1RfVklERU9f U0lOS19XSURULi4uCiAgICAgICogMzQxNTYyIDogYXVkaW9jb252ZXJ0IGRvZXNuJ3QgbGlzdCBm b3JtYXRzIGluIG9yZGVyIG9mIHByZWZlcmVuY2UKICAgICAgKiAzNDE2OTYgOiBhdWRpb2NvbnZl cnQgY3Jhc2hlcyBpZiBjb252ZXJ0aW5nIGZyb20gYSBmb3JtYXQgd2l0aCBubyAuLi4KICAgICAg KiAzNDE3MTkgOiBiaXNlY3Rpb24gYWxnb3JpdGhtIGluIG9nZyBkb2Vzbid0IGJpc2VjdCBpbiBz b21lIGNhc2VzCiAgICAgICogMzQxNzMyIDogW2Fsc2FzaW5rXSBkb2Vzbid0IHF1ZXJ5IHN1cHBv cnRlZCBzYW1wbGUgcmF0ZXMKICAgICAgKiAzNDE4NzMgOiBbYWxzYXNpbmtdIG1pbm9yIG1lbW9y eSBsZWFrLCB1c2VzIHVucHJvdGVjdGVkIHN0YXRpYyB2YXIuLi4KICAgICAgKiAzNDIxNDMgOiBb c3VicGFyc2VdIHNhbWkgcGFyc2VyIG5lZWRzIHRvIGVzY2FwZSBjaGFyYWN0ZXJzCiAgICAgICog MzQyMTgxIDogW2Fsc2FdIGFkZCBwcm9wZXJ0eSBwcm9iZSBpbnRlcmZhY2UgdG8gYWxzYXNpbmsg YW5kIGFsc2FzcmMKICAgICAgKiAzNDIyNjggOiBbcGxheWJpbl0gYWRkICdzdWJ0aXRsZS1lbmNv ZGluZycgcHJvcGVydHkKICAgICAgKiAzNDIzNDUgOiBbcmlmZl0gRWxlcGhhbnQncyBEcmVhbSBB VkkgZG9lcyBub3QgcGxheSwgSlVOSyBjaHVuayBiZWYuLi4KICAgICAgKiAzNDI1NjYgOiBCdWls ZGluZyB3aXRob3V0IEdUSysgZmFpbHMKICAgICAgKiAzNDMzOTcgOiBILjI2NC9BQUMgbW92aWUg ZGVhZGxvY2tzIHdpdGggdG90ZW0gaW4gZ3N0cmVhbWVyIGNvZGUsIHAuLi4KICAgICAgKiAzMzk5 MzUgOiBbYWRkZXJdIGRlYWQtbG9ja3Mgd2hlbiBhZGRpbmcgc2luayBwYWRzIGluIFBBVVNFRCBz dGF0ZQoKRG93bmxvYWQKCllvdSBjYW4gZmluZCBzb3VyY2UgcmVsZWFzZXMgb2YgZ3N0LXBsdWdp bnMtYmFzZSBpbiB0aGUgZG93bmxvYWQgZGlyZWN0b3J5OgpodHRwOi8vZ3N0cmVhbWVyLmZyZWVk ZXNrdG9wLm9yZy9zcmMvZ3N0LXBsdWdpbnMtYmFzZS8KCkdTdHJlYW1lciBIb21lcGFnZQoKTW9y ZSBkZXRhaWxzIGNhbiBiZSBmb3VuZCBvbiB0aGUgcHJvamVjdCdzIHdlYnNpdGU6Cmh0dHA6Ly9n c3RyZWFtZXIuZnJlZWRlc2t0b3Aub3JnLwoKU3VwcG9ydCBhbmQgQnVncwoKV2UgdXNlIEdOT01F J3MgYnVnemlsbGEgZm9yIGJ1ZyByZXBvcnRzIGFuZCBmZWF0dXJlIHJlcXVlc3RzOgpodHRwOi8v YnVnemlsbGEuZ25vbWUub3JnL2VudGVyX2J1Zy5jZ2k/cHJvZHVjdD1HU3RyZWFtZXIKCkRldmVs b3BlcnMKCkNWUyBpcyBob3N0ZWQgb24gY3ZzLmZyZWVkZXNrdG9wLm9yZy4KQWxsIGNvZGUgaXMg aW4gQ1ZTIGFuZCBjYW4gYmUgY2hlY2tlZCBvdXQgZnJvbSB0aGVyZS4KSW50ZXJlc3RlZCBkZXZl bG9wZXJzIG9mIHRoZSBjb3JlIGxpYnJhcnksIHBsdWctaW5zLCBhbmQgYXBwbGljYXRpb25zIHNo b3VsZApzdWJzY3JpYmUgdG8gdGhlIGdzdHJlYW1lci1kZXZlbCBsaXN0LiBJZiB0aGVyZSBpcyBz dWZmaWNpZW50IGludGVyZXN0IHdlCndpbGwgY3JlYXRlIG1vcmUgbGlzdHMgYXMgbmVjZXNzYXJ5 LgoKICAgICAgICAKQXBwbGljYXRpb25zCiAgCkNvbnRyaWJ1dG9ycyB0byB0aGlzIHJlbGVhc2UK ICAgIAogICAgICAqIEVkd2FyZCBIZXJ2ZXkKICAgICAgKiBKYW4gU2NobWlkdAogICAgICAqIEp1 bGllbiBNb3V0dGUKICAgICAgKiBNYXJ0aW4gU3p1bGVja2kKICAgICAgKiBNaWNoYWVsIFNtaXRo CiAgICAgICogUGV0ZXIgS2plbGxlcnN0ZWR0CiAgICAgICogU2ViYXN0aWVuIE1vdXR0ZQogICAg ICAqIFN0ZWZhbiBLb3N0CiAgICAgICogVGhvbWFzIFZhbmRlciBTdGljaGVsZQogICAgICAqIFRp bS1QaGlsaXBwIE3DvGxsZXIKICAgICAgKiBXaW0gVGF5bWFucwogICAgICAqIFlvdW5nLUhvIENo YQogICAgICAqIFphaGVlciBBYmJhcyBNZXJhbGkKwqA= --127.0.0.1.500.5548.1149880308.216.2-- From thomas@apestaart.org Sat Jun 10 13:20:04 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 77ABD3B0280 for ; Sat, 10 Jun 2006 13:20:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16793-02 for ; Sat, 10 Jun 2006 13:20:03 -0400 (EDT) Received: from core.fluendo.com (core.fluendo.com [195.10.6.237]) by menubar.gnome.org (Postfix) with ESMTP id E5DCC3B01B8 for ; Sat, 10 Jun 2006 13:20:02 -0400 (EDT) Received: from onzenbak.amantes (70.Red-81-38-184.dynamicIP.rima-tde.net [81.38.184.70]) by core.fluendo.com (Postfix) with ESMTP id 205F71DC; Sat, 10 Jun 2006 19:20:01 +0200 (CEST) Received: from otto.amantes (otto.amantes [192.168.1.10]) by onzenbak.amantes (Postfix) with ESMTP id 4680720476; Sat, 10 Jun 2006 19:19:58 +0200 (CEST) Received: from otto.amantes (otto.amantes [127.0.0.1]) by otto.amantes (Postfix) with ESMTP id 3B641EFC0D; Sat, 10 Jun 2006 19:20:01 +0200 (CEST) Content-Type: multipart/mixed; boundary="127.0.0.1.500.6078.1149960001.170.2" MIME-Version: 1.0 To: gstreamer-devel@lists.sourceforge.net, gstreamer-announce@lists.sourceforge.net, kde-multimedia@kde.org, gnome-multimedia@gnome.org Message-Id: <20060610172001.3B641EFC0D@otto.amantes> Date: Sat, 10 Jun 2006 19:20:01 +0200 (CEST) From: thomas@apestaart.org X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.991 tagged_above=-999 required=2 tests=[AWL=-1.373, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, MIME_BASE64_TEXT=1.885, NO_REAL_NAME=0.961] X-Spam-Score: -0.991 X-Spam-Level: Cc: Subject: RELEASE: GStreamer 0.10.8 'Soepeke, ik zie ou nog altijd nie' X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 17:20:04 -0000 --127.0.0.1.500.6078.1149960001.170.2 Content-Type: text/plain This mail announces the release of GStreamer 0.10.8 'Soepeke, ik zie ou nog altijd nie'. GStreamer is a streaming media framework that allows the construction of graphs of elements which operate on media data. Applications using this library can do anything from real-time sound processing over playing video to capturing audio, video, and even other types of media data. Its architecture allows for adding new data types or processing capabilities simply by installing new plug-ins. GStreamer is the core module, containing libraries, headers, the basic object hierarchy, and a set of media-agnostic core elements. For more information, see [http://gstreamer.freedesktop.org/modules/gstreamer.html] To file bugs, go to [http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer&component=gstreamer+%28core%29] --127.0.0.1.500.6078.1149960001.170.2 Content-Type: text/plain; name=RELEASE Content-Transfer-Encoding: base64 ClJlbGVhc2Ugbm90ZXMgZm9yIEdTdHJlYW1lcsKgMC4xMC44ICJTb2VwZWtlLCBpayB6aWUgb3Ug bm9nIGFsdGlqZCBuaWUiCiAgICAgICAgCgoKVGhlIEdTdHJlYW1lciB0ZWFtIGlzIHByb3VkIHRv IGFubm91bmNlIGEgbmV3IHJlbGVhc2UKaW4gdGhlIDAuMTAueCBzdGFibGUgc2VyaWVzIG9mIHRo ZQpjb3JlIG9mIHRoZSBHU3RyZWFtZXIgc3RyZWFtaW5nIG1lZGlhIGZyYW1ld29yay4KCgpUaGUg MC4xMC54IHNlcmllcyBpcyBhIHN0YWJsZSBzZXJpZXMgdGFyZ2V0ZWQgYXQgZW5kIHVzZXJzLgpJ dCBpcyBub3QgQVBJIG9yIEFCSSBjb21wYXRpYmxlIHdpdGggdGhlIHN0YWJsZSAwLjgueCBzZXJp ZXMuCkl0IGlzLCBob3dldmVyLCBwYXJhbGxlbCBpbnN0YWxsYWJsZSB3aXRoIHRoZSAwLjgueCBz ZXJpZXMuCgoKVGhlIDAuMTAueCBzZXJpZXMgaGFzIGJlZW4gcmV3b3JrZWQgZm9yIHRocmVhZHNh ZmV0eS4gIEl0IGFsc28gZmVhdHVyZXMKdmFyaW91cyBmZWF0dXJlIGFkZGl0aW9ucyBhbmQgZW5j aGFuY2VtZW50cy4KCgpUaGlzIG1vZHVsZSwgZ3N0cmVhbWVyLCBvbmx5IGNvbnRhaW5zIGNvcmUg ZnVuY3Rpb25hbGl0eS4KRm9yIGFjdHVhbCBtZWRpYSBwbGF5YmFjaywgeW91IHdpbGwgbmVlZCBv dGhlciBtb2R1bGVzLgoKZ3N0LXBsdWdpbnMtYmFzZQpjb250YWlucyBhIGJhc2ljIHNldCBvZiB3 ZWxsLXN1cHBvcnRlZCBwbHVnLWlucwpnc3QtcGx1Z2lucy1nb29kCmNvbnRhaW5zIGEgc2V0IG9m IHdlbGwtc3VwcG9ydGVkIHBsdWctaW5zIHVuZGVyIG91ciBwcmVmZXJyZWQgbGljZW5zZQpnc3Qt cGx1Z2lucy11Z2x5CmNvbnRhaW5zIGEgc2V0IG9mIHdlbGwtc3VwcG9ydGVkIHBsdWctaW5zLCBi dXQgbWlnaHQgcG9zZSBwcm9ibGVtcyBmb3IKICAgIGRpc3RyaWJ1dG9ycwpnc3QtcGx1Z2lucy1i YWQKY29udGFpbnMgYSBzZXQgb2YgbGVzcyBzdXBwb3J0ZWQgcGx1Zy1pbnMgdGhhdCBoYXZlbid0 IHBhc3NlZCB0aGUKICAgIHJpZ29yb3VzIHF1YWxpdHkgdGVzdGluZyB3ZSBleHBlY3QKCgoKICAK RmVhdHVyZXMgb2YgdGhpcyByZWxlYXNlCiAgICAKICAgICAgKiBQYXJhbGxlbCBpbnN0YWxsYWJp bGl0eSB3aXRoIDAuOC54IHNlcmllcwogICAgICAqIFRocmVhZHNhZmUgZGVzaWduIGFuZCBBUEkK ICAgICAgKiBJbXBvcnRhbnQgZml4IGZvciByZWdpc3RyeSB1cGRhdGUgY2F1c2luZyBhcHBsZXRz IG5vdCB0byBsb2FkCgpCdWdzIGZpeGVkIGluIHRoaXMgcmVsZWFzZQogICAgCiAgICAgICogMzQ0 NDc0IDogR25vbWUgTWl4ZXIgQXBwbGV0IGRvZXNuJ3Qgd2FudCB0byBsb2FkCgpEb3dubG9hZAoK WW91IGNhbiBmaW5kIHNvdXJjZSByZWxlYXNlcyBvZiBnc3RyZWFtZXIgaW4gdGhlIGRvd25sb2Fk IGRpcmVjdG9yeToKaHR0cDovL2dzdHJlYW1lci5mcmVlZGVza3RvcC5vcmcvc3JjL2dzdHJlYW1l ci8KCkdTdHJlYW1lciBIb21lcGFnZQoKTW9yZSBkZXRhaWxzIGNhbiBiZSBmb3VuZCBvbiB0aGUg cHJvamVjdCdzIHdlYnNpdGU6Cmh0dHA6Ly9nc3RyZWFtZXIuZnJlZWRlc2t0b3Aub3JnLwoKU3Vw cG9ydCBhbmQgQnVncwoKV2UgdXNlIEdOT01FJ3MgYnVnemlsbGEgZm9yIGJ1ZyByZXBvcnRzIGFu ZCBmZWF0dXJlIHJlcXVlc3RzOgpodHRwOi8vYnVnemlsbGEuZ25vbWUub3JnL2VudGVyX2J1Zy5j Z2k/cHJvZHVjdD1HU3RyZWFtZXIKCkRldmVsb3BlcnMKCkNWUyBpcyBob3N0ZWQgb24gY3ZzLmZy ZWVkZXNrdG9wLm9yZy4KQWxsIGNvZGUgaXMgaW4gQ1ZTIGFuZCBjYW4gYmUgY2hlY2tlZCBvdXQg ZnJvbSB0aGVyZS4KSW50ZXJlc3RlZCBkZXZlbG9wZXJzIG9mIHRoZSBjb3JlIGxpYnJhcnksIHBs dWctaW5zLCBhbmQgYXBwbGljYXRpb25zIHNob3VsZApzdWJzY3JpYmUgdG8gdGhlIGdzdHJlYW1l ci1kZXZlbCBsaXN0LiBJZiB0aGVyZSBpcyBzdWZmaWNpZW50IGludGVyZXN0IHdlCndpbGwgY3Jl YXRlIG1vcmUgbGlzdHMgYXMgbmVjZXNzYXJ5LgoKICAgICAgICAKQXBwbGljYXRpb25zCgpBcHBs aWNhdGlvbnMgcG9ydGVkIHRvIEdTdHJlYW1lciAwLjEwIGluY2x1ZGUgVG90ZW0sIFJoeXRobUJv eCwgU291bmQtSnVpY2VyLApHbm9tZSBNZWRpYSwgRmx1bW90aW9uLCBBbWFyb2ssIEphbWJvcmVl LCBQaXRpdmksIElzdGFuYnVsLCBBbm5vQW1wLCBFbGlzYSwgYW5kIG90aGVycy4KTGV0IHVzIGtu b3cgaWYgeW91IHdhbnQgdG8gYmUgYWRkZWQgdG8gdGhpcyBsaXN0LgoKICAKQ29udHJpYnV0b3Jz IHRvIHRoaXMgcmVsZWFzZQogICAgCiAgICAgICogRWR3YXJkIEhlcnZleQogICAgICAqIFRob21h cyBWYW5kZXIgU3RpY2hlbGUKICAgICAgKiBUaW0tUGhpbGlwcCBNw7xsbGVyCsKg --127.0.0.1.500.6078.1149960001.170.2-- From sjoeboo@sjoeboo.com Wed Jun 14 10:50:35 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CE3003B037F; Wed, 14 Jun 2006 10:50:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08478-04; Wed, 14 Jun 2006 10:50:34 -0400 (EDT) Received: from server.sjoeboo.com (unknown [64.79.192.114]) by menubar.gnome.org (Postfix) with ESMTP id D38F13B02C8; Wed, 14 Jun 2006 10:50:33 -0400 (EDT) Received: by server.sjoeboo.com (Postfix, from userid 33) id 6D37418C4F7F; Wed, 14 Jun 2006 07:50:15 -0700 (PDT) To: gnome-multimedia@gnome.org, rhythmbox-devel@gnome.org Subject: totem and goom information... MIME-Version: 1.0 Date: Wed, 14 Jun 2006 7:50:15 -0700 From: sjoeboo Organization: sjoeboo.com Message-ID: <5135b2d86e5568cedc7e8138809a3b9f@localhost> X-Sender: sjoeboo@sjoeboo.com User-Agent: RoundCube Webmail/0.1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[AWL=0.000, BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: sjoeboo@sjoeboo.com List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 14:50:36 -0000 Good "morning" everyone, So, my (and what should be everyones) favorite music player for gnome, rhythmbox, has been on a steady march of advancement for the past few months, with a whole slew of new features comming about. One thing I though of recently is visualizations, and how ncie it would be to have at least one, possibly as a plugin. I know totem uses GOOM to do this, and was wondering what I might have to do in terms of gstreamer etc to have rhythmbox use it as well. I was looking around on the Totem site for a mailing list etc, but couldn't find anything. Does anyone know where I might find more info for something like this? Thanks, and keep up the great work. -- Matthew Nicholson sjoeboo@sjoeboo.com sjoeboo.com From internalerror@gmail.com Thu Jun 22 05:25:58 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E43203B02D2 for ; Thu, 22 Jun 2006 05:25:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12537-03 for ; Thu, 22 Jun 2006 05:25:56 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.201]) by menubar.gnome.org (Postfix) with ESMTP id D48DD3B0179 for ; Thu, 22 Jun 2006 05:25:55 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so314263wxc for ; Thu, 22 Jun 2006 02:25:55 -0700 (PDT) Received: by 10.70.91.12 with SMTP id o12mr2775555wxb; Thu, 22 Jun 2006 02:25:55 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 02:25:55 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 11:25:55 +0200 From: "Milosz Derezynski" To: xdg@lists.freedesktop.org Subject: MLQ (Media Library Query) file format and mime type proposal MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3009_31371308.1150968355005" X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.255 tagged_above=-999 required=2 tests=[AWL=0.344, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.255 X-Spam-Level: Cc: gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 09:25:58 -0000 ------=_Part_3009_31371308.1150968355005 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I'm one of the main authors of BMP 2 (still being worked on), and along the way of reworking our library, i came across the idea of encoding library queries as URIs, which may look like this: "query:///?artist=Air&album=Moon%20Safari" BMP 2 has a plugin archicture which is a small VFS on it's own, and we treat certain things as "containers" (i.e. they "contain" URIs, like PLS playlists, XSPF, M3U, etc). Now i thought it might be not a bad idea to create a playlist format with these query URLs, and i've called it "MLQ" for media library query. In theory, it's not even application specific. The keys (identifiers), like artist, album, etc, are all based on GStreamer tag identifiers. (They could be maybe adapted to http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but it seems insufficient and doesn't specify certain items, like musicbrainz metadata, which GST does). So i've called this file format "MLQ", with the extension .mlq, created a mime package file for it: Media Library Query List Adding a file of this type to BMPx, or just a plain query:/// URI itself causes a library query and appending of the relevant items to the tracklist (BMP is currently mostly based on the concept of a mutable playlist to which items can be added from various sources, unlike e.g. RB which has mostly immutable "Playlists", but allows for custom queues). Another example is: query:///?artist=Air&album=Moon%20Safari&title=La%20Femme%20d'Argent query:///?artist=Air&album=Moon%20Safari&title=Sexy%20Boy query:///?artist=Air&album=Moon%20Safari&title=All%20I%20Need query:///?artist=Air&album=Moon%20Safari&title=Kelly,%20Watch%20The%20Stars! query:///?artist=Air&album=Moon%20Safari&title=Talisman query:///?artist=Air&album=Moon%20Safari&title=Remember query:///?artist=Air&album=Moon%20Safari&title=You%20Make%20It%20Easy query:///?artist=Air&album=Moon%20Safari&title=Ce%20Matin%20La query:///?artist=Air&album=Moon%20Safari&title=New%20Star%20In%20The%20Sky query:///?artist=Air&album=Moon%20Safari&title=Le%20Voyage%20De%20Penelope Or it might just be: query:///?genre=Jazz Since this is very common, and having the discussions about a common music database in mind, this seems like a useful proposal, since it is not player specific. This ships currently with BMP 2/BMPx SVN, and while i will ship this with the 0.20 release (end-July) anyway, what does everyone think of this in a broader context (common music database, etc)? -- Milosz ------=_Part_3009_31371308.1150968355005 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

I'm one of the main authors of BMP 2 (still being worked on), and along the way of reworking our library, i came across the idea of encoding library queries as URIs, which may look like this:

"query:///?artist=Air&album=Moon%20Safari"

BMP 2 has a plugin archicture which is a small VFS on it's own, and we treat certain things as "containers" (i.e. they "contain" URIs, like PLS playlists, XSPF, M3U, etc).
Now i thought it might be not a bad idea to create a playlist format with these query URLs, and i've called it "MLQ" for media library query. In theory, it's not even
application specific. The keys (identifiers), like artist, album, etc, are all based on GStreamer tag identifiers. (They could be maybe adapted to http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but it seems insufficient and doesn't specify certain items, like musicbrainz metadata, which GST does).

So i've called this file format "MLQ", with the extension .mlq, created a mime package file for it:

<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info ">
  <mime-type type="application/x-media-library-query">
         <comment xml:lang="en">Media Library Query List</comment>
         <magic priority="50">
            <match value="query:///" type="string" offset="0"/>
         </magic>
         <glob pattern="*.mlq"/>
  </mime-type>
</mime-info>

Adding a file of this type to BMPx, or just a plain query:/// URI itself causes a library query and appending of the relevant items to the tracklist (BMP is currently mostly based on the concept of a mutable playlist to which items can be added from various sources, unlike e.g. RB which has mostly immutable "Playlists", but allows for custom queues).

Another example is:

query:///?artist=Air&album=Moon%20Safari&title=La%20Femme%20d'Argent
query:///?artist=Air&album=Moon%20Safari&title=Sexy%20Boy
query:///?artist=Air&album=Moon%20Safari&title=All%20I%20Need
query:///?artist=Air&album=Moon%20Safari&title=Kelly,%20Watch%20The%20Stars!
query:///?artist=Air&album=Moon%20Safari&title=Talisman
query:///?artist=Air&album=Moon%20Safari&title=Remember
query:///?artist=Air&album=Moon%20Safari&title=You%20Make%20It%20Easy
query:///?artist=Air&album=Moon%20Safari&title=Ce%20Matin%20La
query:///?artist=Air&album=Moon%20Safari&title=New%20Star%20In%20The%20Sky
query:///?artist=Air&album=Moon%20Safari&title=Le%20Voyage%20De%20Penelope

Or it might just be:

query:///?genre=Jazz

Since this is very common, and having the discussions about a common music database in mind, this seems like a useful proposal, since it is not player specific.
This ships currently with BMP 2/BMPx SVN, and while i will ship this with the 0.20 release (end-July) anyway, what does everyone think of this in a broader context (common music database, etc)?

-- Milosz
------=_Part_3009_31371308.1150968355005-- From internalerror@gmail.com Thu Jun 22 05:32:59 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7208D3B00DE for ; Thu, 22 Jun 2006 05:32:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12916-03 for ; Thu, 22 Jun 2006 05:32:58 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.207]) by menubar.gnome.org (Postfix) with ESMTP id 6F0643B0373 for ; Thu, 22 Jun 2006 05:32:58 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so314918wxc for ; Thu, 22 Jun 2006 02:32:57 -0700 (PDT) Received: by 10.70.103.9 with SMTP id a9mr2787413wxc; Thu, 22 Jun 2006 02:32:57 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 02:32:57 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 11:32:57 +0200 From: "Milosz Derezynski" To: xdg@lists.freedesktop.org Subject: MLQ: Followup MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3081_18949182.1150968777845" X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.875 tagged_above=-999 required=2 tests=[AWL=-0.071, BAYES_00=-2.599, HTML_00_10=0.795, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -1.875 X-Spam-Level: Cc: gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 09:32:59 -0000 ------=_Part_3081_18949182.1150968777845 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline What i forgot to mention: One benefit of MLQs over 'regular' playlists at least with BMP 2 is that i've introduced a concept of keeping track of tracks across mount point changes which basically works like this: BMP stores for each file the HAL volume and device UDI, and the VRP (Volume Relative Path), that is, the path stripped off the mount point root. Whenever it seems that a file is missing, it checks whether the volume UDI of this file is still present on the system, and if so, gathers the new mount point, and adjusts the URI of this file in the library (this obiviously only works with tracks from the library only anyway since only there we can reliably store the HAL volume/device UDI and the VRP). This means practically: - Mount your music to /music - Start BMP - Add music from /music to the library - Quit BMP - Remount /music to e.g. /old_music - Start BMP - Use the library as before. Whenever BMP finds a file is missing, it will correct the URI on-the-fly as long as the volume is mounted at all on the system (and has an UDI to begin with; problem cases here are network volumes, NFS and SMBFS) So the benefit of an MLQ is that unlike a static playlist, you can be rather sure that no matter where you really move the music, BMP will always be able to find it. Downsides/doesn't-works: - There is no volume UDI available - You make a regular 'move' (mv), and not just a remount In the context of having a common music database, or something like Tracker, this seems very useful (Jamie: Hence my urge to add HAL volume/device UDI per file to the metadata). -- Milosz ------=_Part_3081_18949182.1150968777845 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline What i forgot to mention:

One benefit of MLQs over 'regular' playlists at least with BMP 2 is that i've introduced a concept of keeping track of tracks across mount point changes which basically works like this:

BMP stores for each file the HAL volume and device UDI, and the VRP (Volume Relative Path), that is, the path stripped off the mount point root.
Whenever it seems that a file is missing, it checks whether the volume UDI of this file is still present on the system, and if so, gathers the new mount point, and adjusts the URI of this
file in the library (this obiviously only works with tracks from the library only anyway since only there we can reliably store the HAL volume/device UDI and the VRP).

This means practically:

- Mount your music to /music
- Start BMP
- Add music from /music to the library
- Quit BMP
- Remount /music to e.g. /old_music
- Start BMP
- Use the library as before. Whenever BMP finds a file is missing, it will correct the URI on-the-fly as long as the volume is mounted at all on the system (and has an UDI to begin with; problem cases here are network volumes, NFS and SMBFS)

So the benefit of an MLQ is that unlike a static playlist, you can be rather sure that no matter where you really move the music, BMP will always be able to find it.

Downsides/doesn't-works:

- There is no volume UDI available
- You make a regular 'move' (mv), and not just a remount

In the context of having a common music database, or something like Tracker, this seems very useful (Jamie: Hence my urge to add HAL volume/device UDI per file to the metadata).

-- Milosz
------=_Part_3081_18949182.1150968777845-- From internalerror@gmail.com Thu Jun 22 06:23:10 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 61AE53B0403 for ; Thu, 22 Jun 2006 06:23:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15637-08 for ; Thu, 22 Jun 2006 06:23:09 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.195]) by menubar.gnome.org (Postfix) with ESMTP id 7534E3B045B for ; Thu, 22 Jun 2006 06:23:08 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so321629wxc for ; Thu, 22 Jun 2006 03:23:07 -0700 (PDT) Received: by 10.70.14.14 with SMTP id 14mr2842980wxn; Thu, 22 Jun 2006 03:23:07 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 03:23:07 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 12:23:07 +0200 From: "Milosz Derezynski" To: "Josef Spillner" Subject: Re: MLQ (Media Library Query) file format and mime type proposal In-Reply-To: <200606221139.41836.spillner@kde.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3405_33193106.1150971787566" References: <200606221139.41836.spillner@kde.org> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.443 tagged_above=-999 required=2 tests=[AWL=-0.496, BAYES_00=-2.599, HTML_10_20=1.351, HTML_MESSAGE=0.001, MIME_BASE64_NO_NAME=0.224, SPF_PASS=-0.001, TW_XD=0.077] X-Spam-Score: -1.443 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 10:23:10 -0000 ------=_Part_3405_33193106.1150971787566 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline WWVhaCB3ZWxsIGp1c3QgdG8gc3RheSB3aXRoaW4gdGhlIGZvY3VzIG9mIGEgbXVzaWMgbGlicmFy eSwgdGhlcmUgaGFzIHRvIGJlCnNvbWV0aGluZwp0aGF0IGRvZXMgdGhlIHJlc29sdXRpb24uCgpP TkUgcG9zc2libGUgb3B0aW9uIHdvdWxkIGJlIHRvIHNwZWNpZnkgYSBELUJVUyBpbnRlcmZhY2Ug bmFtZSwgYW5kIGEgaGF2ZQpzaW1wbGUgbGF1bmNoZXIuCgpBbGwgYXBwcyBzdXBwb3J0aW5nIE1M UXMgd291bGQgaGF2ZSB0byBoYXZlIGEgbWluaW1hbCBjb21tb24gc3Vic2V0Cm9mIEQtQlVTIGlu dGVyZmFjZXJ5IHRvIGFsbG93IHRoaXMga2luZCBvZiBxdWVyeSB0byBiZSBzZW50IHRvIHRoZW0g aW4gc29tZQp3YXkKKHNvbWV0aGluZyBsaWtlIGFuIEFkZFVyaSBjYWxsIG1pZ2h0IGp1c3Qgc3Vm ZmljZSksIHRoZW4gdGhlIGxhdW5jaGVyIHdvdWxkCmJhc2ljYWxseQpjb25zaXN0IG9mIHN0YXJ0 aW5nIHRoZSByZWxldmFudCBhcGxsaWNhdGlvbiB0cm91Z2ggRC1CVVMgYWN0aXZhdGlvbiwgYW5k CnRoZW4gcGFzcyBvbgp0aGUgYWN0dWFsIHF1ZXJ5IHRvIGl0LgoKKFdlIGhhdmUgYSBkdW1teSBt ZXRob2QgIlN0YXJ0dXAiIG9uIG91ciBELUJVUyBpZmFjZSB3aGljaApkb2VzIG5vdGhpbmcsIGJ1 dCBjYXVzZXMgRC1CVVMgdG8gc3RhcnQgdXAgQk1QLiBUaGUgcmVhc29uaW5nIGlzIHRoYXQgd2UK aGF2ZSBvbmUgbWFpbgpiaW5hcnkgYW5kIG9uZSAicmVtb3RlIiBiaW5hcnksIHdoaWNoIGlzIHRo b3VnaCBzZXQgc28gdGhhdCBpdCBpcyBwZXJjZWl2ZWQKYXMgYmVpbmcgdGhlIG1haW4KYmluYXJ5 LCBhcyBpbiBpdCdzIGluIC91c3IvYmluLCB3aGVyZWFzIHRoZSAtYmluIChtYWluKSBiaW5hcnkg aXMgaW4KL3Vzci9saWJleGVjLiBUaGUgcmVhc29uCmlzIHNvIHRoYXQgd2UgaGF2ZSBhIGxpZ2h0 d2VpZ2h0IHJlbW90ZSBhcHAgdGhhdCBjYW4gcGVyZm9ybSBhY3Rpb25zIG9uIHRoZQptYWluIGJp bmFyeQphbmQgZG9uJ3QgaGF2ZSB0byBoYXZlIHRoZSBtYWluIGFwcCBiZSBjYXBhYmxlIG9mIGJl aW5nIGEgY2xpZW50IHRvIGl0J3Mgb3duCnNlcnZlcgphbmQgaGF2ZSBhbGwgdGhlIHN0YXJ0dXAg c2hpenpsZSBnb2luZyBqdXN0IHRvIHBlcmZvcm0gYSBjZXJ0YWluIHJlbW90ZQpvcGVyYXRpb24p LgoKRm9yIGV4YW1wbGUgeW91J2QgaGF2ZToKcXVlcnk6Ly9vcmcuYmVlcG1lZGlhcGxheWVyLmJt cC8/YXJ0aXN0PUFpciZBbGJ1bT1Nb29uJTIwU2FmYXJpCgpUaGUgc2NyaXB0LCBvciBiZSBpdCBh IGJpbmFyeSwgbGV0J3MgY2FsbCBpdCAicGxheS1tbHEiLCB3b3VsZCBsYXVuY2ggdGhlCnBsYXll ciB3aXRoIHRoZSBzcGVjaWZpZWQgaW50ZXJmYWNlIGFuZCBwYXNzIGl0IHRoZSBhY3R1YWwgcXVl cnkuCgpfQW5vdGhlcl8gcG9zc2liaWxpdHksIGFsdGhvdWdoIHRoaXMgd291bGQgcmVxdWlyZSBw bGF5ZXJzIHRoYXQgY2FuIHdvcmsKd2l0aAptdXRhYmxlIHBsYXlsaXN0cyBsaWtlIEJNUCwgaXMg dGhhdCBpdCB3b3VsZCBwYXNzIHRoZSBxdWVyeSBvbiB0byBlLmcuCnNvbWV0aGluZwpsaWtlIFRy YWNrZXIgb3Igc29tZSBvdGhlciBpbmRleGVyLCB3aGljaCB3b3VsZCB0aGVuIGV4ZWN1dGUgdGhl IHF1ZXJ5IGFuZApfSVRfIHdvdWxkIHRoZW4gc3RhcnQgdGhlIHBsYXllciBzcGVjaWZpZWQgYnkg dGhlIGludGVyZmFjZSBhbmQgcGFzcyBpdAphbG9uZyB0aGUKcmVzdWx0aW5nIFVSSXMuCgotLSBN aWxvc3oKCk9uIDYvMjIvMDYsIEpvc2VmIFNwaWxsbmVyIDxzcGlsbG5lckBrZGUub3JnPiB3cm90 ZToKPgo+IEFsbGUgMTE6MjUsIGdpb3ZlZMOsLCAyMi4gZ2l1Z25vIDIwMDYsIE1pbG9zeiBEZXJl enluc2tpIGhhIHNjcml0dG86Cj4gPiBTaW5jZSB0aGlzIGlzIHZlcnkgY29tbW9uLCBhbmQgaGF2 aW5nIHRoZSBkaXNjdXNzaW9ucyBhYm91dCBhIGNvbW1vbgo+IG11c2ljCj4gPiBkYXRhYmFzZSBp biBtaW5kLCB0aGlzIHNlZW1zIGxpa2UgYSB1c2VmdWwgcHJvcG9zYWwsIHNpbmNlIGl0IGlzIG5v dAo+IHBsYXllcgo+ID4gc3BlY2lmaWMuCj4KPiBJdCBpcyBub3QgZXZlbiBtdXNpYyBzcGVjaWZp Yy4gSSd2ZSB1c2VkIHF1ZXJ5Oi8vIFVSSXMgZm9yIGEgbG9uZyB0aW1lCj4gd2l0aAo+IG1ldGFz ZXJ2ZXJzLCBhbHRob3VnaCBvbmx5IGluIGEgcmVhZC1vbmx5IGNvbnRleHQsIHdoZXJlYXMgZm9y IHdyaXRlCj4gYWNjZXNzCj4gdGhlIChhbHRlcm5hdGl2ZSkgZnVsbC1ibG93biBYTUwgaW50ZXJm YWNlIGlzIHVzZWQuCj4KPiBUaGUgd2F5IGl0IGlzIHVzZWQgZm9yIHRoZSBtZXRhc2VydmVyIGlz IGxpa2UgcXVlcnk6Ly90eXBlL2NhdGVnb3J5LCB3aGVyZQo+IGUuZy4gdHlwZSB3b3VsZCBiZSB0 aGUgZ2VuZXJpYyBuYW1lIGZvciBhIHNlcnZlciAoc2F5LCAnZnJlZWNpdicgb3IKPiAnY3Vwc2Qn KQo+IGFuZCBjYXRlZ29yeSB3b3VsZCBiZSAnY29ubmVjdGlvbicgKHRvIGdldCBiYWNrIGEgY29u bmVjdGlvbiBVUkkpIG9yCj4gJ21ldGEnCj4gKHRvIGdldCBiYWNrIG90aGVyIG1ldGFzZXJ2ZXIg VVJJcyBmb3IgdGhlIHNhbWUgdHlwZSkuCj4gVXNpbmcgc3VjaCBhIHNjaGVtZSBtYWtlcyBhbiBh cHBsaWNhdGlvbiByZXNpc3RhbnQgYWdhaW5zdCBob3N0IG5hbWUKPiBjaGFuZ2VzCj4gaW4gdGhl IGxvbmcgcnVuLCBpLmUuIGl0IHdpbGwgcGljayB1cCBtb3Zpbmcgc2VydmVycyBhdXRvbWF0aWNh bGx5Lgo+Cj4gVGhpcyBpcyBwcm9iYWJseSBub3QgdGhlIHNhbWUgdGhpbmcgYXMgeW91ciBxdWVy eSwgYnV0IG9idmlvdXNseSBpdCdzIGFsc28KPiB1c2VkIHRvIHF1ZXJ5IGEgZGF0YWJhc2UgYmVo aW5kIGl0ICh3aGljaCBpcyBhIFhNTCBkYXRhYmFzZSBpbiBteSBjYXNlLAo+IGJ1dAo+IGNvdWxk IGJlIFNRTCBvciBhbnl0aGluZyBlbHNlIGZvciB0aGF0IG1hdHRlcikuIFNvIG1heWJlIGl0IG1h a2VzIHNlbnNlIHRvCj4gc3RhbmRhcmRpc2UgdGhpcyBpbiBhIGJyb2FkZXIgY29udGV4dC4KPgo+ IEtERSBSYWRpbyBTdGF0aW9uIGlzIG9uZSBleGFtcGxlIHdoZXJlIHRoaXMgaXMgdXNlZCAoaGEg LSBmb3VuZCBhIHJlbGF0aW9uCj4gdG8KPiBtdXNpYyEpLCBhbmQgdGhlIEdHWiBHYW1pbmcgWm9u ZSBwcm9qZWN0IGlzIGFub3RoZXIgb25lICh3aGVyZSBpdAo+IG9yaWdpbmF0ZWQKPiBzaW5jZSBt ZXRhc2VydmVycyBhcmUgY29tbW9ucGxhY2Ugd2l0aCBnYW1lIHNlcnZlcnMpLgo+Cj4gSm9zZWYK PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IHhkZyBt YWlsaW5nIGxpc3QKPiB4ZGdAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCj4gaHR0cDovL2xpc3RzLmZy ZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hkZwo+Cg== ------=_Part_3405_33193106.1150971787566 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline WWVhaCB3ZWxsIGp1c3QgdG8gc3RheSB3aXRoaW4gdGhlIGZvY3VzIG9mIGEgbXVzaWMgbGlicmFy eSwgdGhlcmUgaGFzIHRvIGJlIHNvbWV0aGluZzxicj50aGF0IGRvZXMgdGhlIHJlc29sdXRpb24u PGJyPjxicj5PTkUgcG9zc2libGUgb3B0aW9uIHdvdWxkIGJlIHRvIHNwZWNpZnkgYSBELUJVUyBp bnRlcmZhY2UgbmFtZSwgYW5kIGEgaGF2ZSBzaW1wbGUgbGF1bmNoZXIuPGJyPjxicj5BbGwgYXBw cyBzdXBwb3J0aW5nIE1MUXMgd291bGQgaGF2ZSB0byBoYXZlIGEgbWluaW1hbCBjb21tb24gc3Vi c2V0Cjxicj5vZiBELUJVUyBpbnRlcmZhY2VyeSB0byBhbGxvdyB0aGlzIGtpbmQgb2YgcXVlcnkg dG8gYmUgc2VudCB0byB0aGVtIGluIHNvbWUgd2F5PGJyPihzb21ldGhpbmcgbGlrZSBhbiBBZGRV cmkgY2FsbCBtaWdodCBqdXN0IHN1ZmZpY2UpLCB0aGVuIHRoZSBsYXVuY2hlciB3b3VsZCBiYXNp Y2FsbHk8YnI+Y29uc2lzdCBvZiBzdGFydGluZyB0aGUgcmVsZXZhbnQgYXBsbGljYXRpb24gdHJv dWdoIEQtQlVTIGFjdGl2YXRpb24sIGFuZCB0aGVuIHBhc3Mgb24KPGJyPnRoZSBhY3R1YWwgcXVl cnkgdG8gaXQuIDxicj48YnI+KFdlIGhhdmUgYSBkdW1teSBtZXRob2QgJnF1b3Q7U3RhcnR1cCZx dW90OyBvbiBvdXIgRC1CVVMgaWZhY2Ugd2hpY2g8YnI+ZG9lcyBub3RoaW5nLCBidXQgY2F1c2Vz IEQtQlVTIHRvIHN0YXJ0IHVwIEJNUC4gVGhlIHJlYXNvbmluZyBpcyB0aGF0IHdlIGhhdmUgb25l IG1haW48YnI+YmluYXJ5IGFuZCBvbmUgJnF1b3Q7cmVtb3RlJnF1b3Q7IGJpbmFyeSwgd2hpY2gg aXMgdGhvdWdoIHNldCBzbyB0aGF0IGl0IGlzIHBlcmNlaXZlZCBhcyBiZWluZyB0aGUgbWFpbgo8 YnI+YmluYXJ5LCBhcyBpbiBpdCdzIGluIC91c3IvYmluLCB3aGVyZWFzIHRoZSAtYmluIChtYWlu KSBiaW5hcnkgaXMgaW4gL3Vzci9saWJleGVjLiBUaGUgcmVhc29uPGJyPmlzIHNvIHRoYXQgd2Ug aGF2ZSBhIGxpZ2h0d2VpZ2h0IHJlbW90ZSBhcHAgdGhhdCBjYW4gcGVyZm9ybSBhY3Rpb25zIG9u IHRoZSBtYWluIGJpbmFyeTxicj5hbmQgZG9uJ3QgaGF2ZSB0byBoYXZlIHRoZSBtYWluIGFwcCBi ZSBjYXBhYmxlIG9mIGJlaW5nIGEgY2xpZW50IHRvIGl0J3Mgb3duIHNlcnZlcgo8YnI+YW5kIGhh dmUgYWxsIHRoZSBzdGFydHVwIHNoaXp6bGUgZ29pbmcganVzdCB0byBwZXJmb3JtIGEgY2VydGFp biByZW1vdGUgb3BlcmF0aW9uKS48YnI+PGJyPkZvciBleGFtcGxlIHlvdSdkIGhhdmU6PGJyPnF1 ZXJ5Oi8vb3JnLmJlZXBtZWRpYXBsYXllci5ibXAvP2FydGlzdD1BaXImYW1wO0FsYnVtPU1vb24l MjBTYWZhcmk8YnI+PGJyPlRoZSBzY3JpcHQsIG9yIGJlIGl0IGEgYmluYXJ5LCBsZXQncyBjYWxs IGl0ICZxdW90O3BsYXktbWxxJnF1b3Q7LCB3b3VsZCBsYXVuY2ggdGhlCjxicj5wbGF5ZXIgd2l0 aCB0aGUgc3BlY2lmaWVkIGludGVyZmFjZSBhbmQgcGFzcyBpdCB0aGUgYWN0dWFsIHF1ZXJ5Ljxi cj48YnI+X0Fub3RoZXJfIHBvc3NpYmlsaXR5LCBhbHRob3VnaCB0aGlzIHdvdWxkIHJlcXVpcmUg cGxheWVycyB0aGF0IGNhbiB3b3JrIHdpdGg8YnI+bXV0YWJsZSBwbGF5bGlzdHMgbGlrZSBCTVAs IGlzIHRoYXQgaXQgd291bGQgcGFzcyB0aGUgcXVlcnkgb24gdG8gCmUuZy4gc29tZXRoaW5nPGJy Pmxpa2UgVHJhY2tlciBvciBzb21lIG90aGVyIGluZGV4ZXIsIHdoaWNoIHdvdWxkIHRoZW4gZXhl Y3V0ZSB0aGUgcXVlcnkgYW5kPGJyPl9JVF8gd291bGQgdGhlbiBzdGFydCB0aGUgcGxheWVyIHNw ZWNpZmllZCBieSB0aGUgaW50ZXJmYWNlIGFuZCBwYXNzIGl0IGFsb25nIHRoZTxicj5yZXN1bHRp bmcgVVJJcy48YnI+PGJyPi0tIE1pbG9zejxicj48YnI+CjxkaXY+PHNwYW4gY2xhc3M9ImdtYWls X3F1b3RlIj5PbiA2LzIyLzA2LCA8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+Sm9zZWYgU3Bp bGxuZXI8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86c3BpbGxuZXJAa2RlLm9yZyI+c3BpbGxuZXJA a2RlLm9yZzwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv dGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFy Z2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4KQWxsZSAxMToyNSwg Z2lvdmVkw6wsIDIyLiBnaXVnbm8gMjAwNiwgTWlsb3N6IERlcmV6eW5za2kgaGEgc2NyaXR0bzo8 YnI+Jmd0OyBTaW5jZSB0aGlzIGlzIHZlcnkgY29tbW9uLCBhbmQgaGF2aW5nIHRoZSBkaXNjdXNz aW9ucyBhYm91dCBhIGNvbW1vbiBtdXNpYzxicj4mZ3Q7IGRhdGFiYXNlIGluIG1pbmQsIHRoaXMg c2VlbXMgbGlrZSBhIHVzZWZ1bCBwcm9wb3NhbCwgc2luY2UgaXQgaXMgbm90IHBsYXllcgo8YnI+ Jmd0OyBzcGVjaWZpYy48YnI+PGJyPkl0IGlzIG5vdCBldmVuIG11c2ljIHNwZWNpZmljLiBJJ3Zl IHVzZWQgcXVlcnk6Ly8gVVJJcyBmb3IgYSBsb25nIHRpbWUgd2l0aDxicj5tZXRhc2VydmVycywg YWx0aG91Z2ggb25seSBpbiBhIHJlYWQtb25seSBjb250ZXh0LCB3aGVyZWFzIGZvciB3cml0ZSBh Y2Nlc3M8YnI+dGhlIChhbHRlcm5hdGl2ZSkgZnVsbC1ibG93biBYTUwgaW50ZXJmYWNlIGlzIHVz ZWQuCjxicj48YnI+VGhlIHdheSBpdCBpcyB1c2VkIGZvciB0aGUgbWV0YXNlcnZlciBpcyBsaWtl IHF1ZXJ5Oi8vdHlwZS9jYXRlZ29yeSwgd2hlcmU8YnI+ZS5nLiB0eXBlIHdvdWxkIGJlIHRoZSBn ZW5lcmljIG5hbWUgZm9yIGEgc2VydmVyIChzYXksICdmcmVlY2l2JyBvciAnY3Vwc2QnKTxicj5h bmQgY2F0ZWdvcnkgd291bGQgYmUgJ2Nvbm5lY3Rpb24nICh0byBnZXQgYmFjayBhIGNvbm5lY3Rp b24gVVJJKSBvciAnbWV0YScKPGJyPih0byBnZXQgYmFjayBvdGhlciBtZXRhc2VydmVyIFVSSXMg Zm9yIHRoZSBzYW1lIHR5cGUpLjxicj5Vc2luZyBzdWNoIGEgc2NoZW1lIG1ha2VzIGFuIGFwcGxp Y2F0aW9uIHJlc2lzdGFudCBhZ2FpbnN0IGhvc3QgbmFtZSBjaGFuZ2VzPGJyPmluIHRoZSBsb25n IHJ1biwgaS5lLiBpdCB3aWxsIHBpY2sgdXAgbW92aW5nIHNlcnZlcnMgYXV0b21hdGljYWxseS48 YnI+PGJyPlRoaXMgaXMgcHJvYmFibHkgbm90IHRoZSBzYW1lIHRoaW5nIGFzIHlvdXIgcXVlcnks IGJ1dCBvYnZpb3VzbHkgaXQncyBhbHNvCjxicj51c2VkIHRvIHF1ZXJ5IGEgZGF0YWJhc2UgYmVo aW5kIGl0ICh3aGljaCBpcyBhIFhNTCBkYXRhYmFzZSBpbiBteSBjYXNlLCBidXQ8YnI+Y291bGQg YmUgU1FMIG9yIGFueXRoaW5nIGVsc2UgZm9yIHRoYXQgbWF0dGVyKS4gU28gbWF5YmUgaXQgbWFr ZXMgc2Vuc2UgdG88YnI+c3RhbmRhcmRpc2UgdGhpcyBpbiBhIGJyb2FkZXIgY29udGV4dC48YnI+ PGJyPktERSBSYWRpbyBTdGF0aW9uIGlzIG9uZSBleGFtcGxlIHdoZXJlIHRoaXMgaXMgdXNlZCAo aGEgLSBmb3VuZCBhIHJlbGF0aW9uIHRvCjxicj5tdXNpYyEpLCBhbmQgdGhlIEdHWiBHYW1pbmcg Wm9uZSBwcm9qZWN0IGlzIGFub3RoZXIgb25lICh3aGVyZSBpdCBvcmlnaW5hdGVkPGJyPnNpbmNl IG1ldGFzZXJ2ZXJzIGFyZSBjb21tb25wbGFjZSB3aXRoIGdhbWUgc2VydmVycykuPGJyPjxicj5K b3NlZjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj54ZGcgbWFpbGluZyBsaXN0Cjxicj48YSBocmVmPSJtYWlsdG86eGRnQGxpc3RzLmZyZWVkZXNr dG9wLm9yZyI+eGRnQGxpc3RzLmZyZWVkZXNrdG9wLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cDov L2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hkZyI+aHR0cDovL2xpc3Rz LmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hkZzwvYT48YnI+PC9ibG9ja3F1b3Rl PjwvZGl2Pjxicj4K ------=_Part_3405_33193106.1150971787566-- From jamiemcc@blueyonder.co.uk Thu Jun 22 06:41:17 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 687D03B0251 for ; Thu, 22 Jun 2006 06:41:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17075-06 for ; Thu, 22 Jun 2006 06:41:15 -0400 (EDT) Received: from smtp-out5.blueyonder.co.uk (smtp-out5.blueyonder.co.uk [195.188.213.8]) by menubar.gnome.org (Postfix) with ESMTP id 74F7B3B021B for ; Thu, 22 Jun 2006 06:41:15 -0400 (EDT) Received: from [172.23.170.145] (helo=anti-virus03-08) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1FtMca-0004xo-T2; Thu, 22 Jun 2006 11:41:12 +0100 Received: from [62.30.198.187] (helo=[62.30.198.187]) by asmtp-out2.blueyonder.co.uk with esmtpa (Exim 4.52) id 1FtMcZ-0001pP-Rp; Thu, 22 Jun 2006 11:41:11 +0100 Message-ID: <449A73D1.6030401@blueyonder.co.uk> Date: Thu, 22 Jun 2006 11:41:21 +0100 From: Jamie McCracken User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Milosz Derezynski Subject: Re: MLQ: Followup References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.459 tagged_above=-999 required=2 tests=[AWL=0.141, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.459 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 10:41:17 -0000 Milosz Derezynski wrote: > What i forgot to mention: > > One benefit of MLQs over 'regular' playlists at least with BMP 2 is that > i've introduced a concept of keeping track of tracks across mount point > changes which basically works like this: > > BMP stores for each file the HAL volume and device UDI, and the VRP > (Volume Relative Path), that is, the path stripped off the mount point root. > Whenever it seems that a file is missing, it checks whether the volume > UDI of this file is still present on the system, and if so, gathers the > new mount point, and adjusts the URI of this > file in the library (this obiviously only works with tracks from the > library only anyway since only there we can reliably store the HAL > volume/device UDI and the VRP). > > This means practically: > > - Mount your music to /music > - Start BMP > - Add music from /music to the library > - Quit BMP > - Remount /music to e.g. /old_music > - Start BMP > - Use the library as before. Whenever BMP finds a file is missing, it > will correct the URI on-the-fly as long as the volume is mounted at all > on the system (and has an UDI to begin with; problem cases here are > network volumes, NFS and SMBFS) > > So the benefit of an MLQ is that unlike a static playlist, you can be > rather sure that no matter where you really move the music, BMP will > always be able to find it. > > Downsides/doesn't-works: > > - There is no volume UDI available > - You make a regular 'move' (mv), and not just a remount > > In the context of having a common music database, or something like > Tracker, this seems very useful (Jamie: Hence my urge to add HAL > volume/device UDI per file to the metadata). Im quite happy to add this as metadata to tracker and even get tracker to hide stuff based on it (using hal) but it still needs to be part of the uri for a music file (otherwise we wont be able to uniquely identify the files) -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ From jamiemcc@blueyonder.co.uk Thu Jun 22 06:52:34 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 93DEE3B031A for ; Thu, 22 Jun 2006 06:52:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17877-10 for ; Thu, 22 Jun 2006 06:52:32 -0400 (EDT) Received: from smtp-out5.blueyonder.co.uk (smtp-out5.blueyonder.co.uk [195.188.213.8]) by menubar.gnome.org (Postfix) with ESMTP id 66C8B3B0262 for ; Thu, 22 Jun 2006 06:52:32 -0400 (EDT) Received: from [172.23.170.140] (helo=anti-virus02-07) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1FtMnX-0007Tp-4T; Thu, 22 Jun 2006 11:52:31 +0100 Received: from [62.30.198.187] (helo=[62.30.198.187]) by asmtp-out1.blueyonder.co.uk with esmtpa (Exim 4.52) id 1FtMnU-0001TX-7r; Thu, 22 Jun 2006 11:52:28 +0100 Message-ID: <449A7676.6060309@blueyonder.co.uk> Date: Thu, 22 Jun 2006 11:52:38 +0100 From: Jamie McCracken User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Milosz Derezynski Subject: Re: MLQ (Media Library Query) file format and mime type proposal References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.422 tagged_above=-999 required=2 tests=[AWL=0.101, BAYES_00=-2.599, SPF_PASS=-0.001, TW_RQ=0.077] X-Spam-Score: -2.422 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 10:52:34 -0000 Milosz Derezynski wrote: > Hi, > > I'm one of the main authors of BMP 2 (still being worked on), and along > the way of reworking our library, i came across the idea of encoding > library queries as URIs, which may look like this: > > "query:///?artist=Air&album=Moon%20Safari" > > BMP 2 has a plugin archicture which is a small VFS on it's own, and we > treat certain things as "containers" (i.e. they "contain" URIs, like PLS > playlists, XSPF, M3U, etc). > Now i thought it might be not a bad idea to create a playlist format > with these query URLs, and i've called it "MLQ" for media library query. > In theory, it's not even > application specific. The keys (identifiers), like artist, album, etc, > are all based on GStreamer tag identifiers. (They could be maybe adapted > to http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , > but it seems insufficient and doesn't specify certain items, like > musicbrainz metadata, which GST does). Tracker's metadata spec does (http://freedesktop.org/wiki/Standards/shared-filemetadata-spec) > > So i've called this file format "MLQ", with the extension .mlq, created > a mime package file for it: > > > > > Media Library Query List > > > > > > > > Adding a file of this type to BMPx, or just a plain query:/// URI itself > causes a library query and appending of the relevant items to the > tracklist (BMP is currently mostly based on the concept of a mutable > playlist to which items can be added from various sources, unlike e.g. > RB which has mostly immutable "Playlists", but allows for custom queues). > > Another example is: > > query:///?artist=Air&album=Moon%20Safari&title=La%20Femme%20d'Argent > query:///?artist=Air&album=Moon%20Safari&title=Sexy%20Boy > query:///?artist=Air&album=Moon%20Safari&title=All%20I%20Need > query:///?artist=Air&album=Moon%20Safari&title=Kelly,%20Watch%20The%20Stars! > query:///?artist=Air&album=Moon%20Safari&title=Talisman > query:///?artist=Air&album=Moon%20Safari&title=Remember > query:///?artist=Air&album=Moon%20Safari&title=You%20Make%20It%20Easy > query:///?artist=Air&album=Moon%20Safari&title=Ce%20Matin%20La > query:///?artist=Air&album=Moon%20Safari&title=New%20Star%20In%20The%20Sky > query:///?artist=Air&album=Moon%20Safari&title=Le%20Voyage%20De%20Penelope > > Or it might just be: > > query:///?genre=Jazz > > Since this is very common, and having the discussions about a common > music database in mind, this seems like a useful proposal, since it is > not player specific. > This ships currently with BMP 2/BMPx SVN, and while i will ship this > with the 0.20 release (end-July) anyway, what does everyone think of > this in a broader context (common music database, etc)? Could be interesting as an alternative to rdf query that tracker uses but rdf query is a *standard* and is the WC3's recommended means of querying metadata. A more compact version of the xml based rdf query language is sparql (http://www.w3.org/TR/rdf-sparql-query/) and is also a candidate for standardisation. I guess its going to be fun deciding which to use (I will go with the flow) -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ From doclivingston@gmail.com Thu Jun 22 07:00:08 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 966243B038B for ; Thu, 22 Jun 2006 07:00:08 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18372-10 for ; Thu, 22 Jun 2006 07:00:05 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by menubar.gnome.org (Postfix) with ESMTP id 2DC8B3B00ED for ; Thu, 22 Jun 2006 07:00:05 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id f25so276546pyf for ; Thu, 22 Jun 2006 04:00:04 -0700 (PDT) Received: by 10.35.91.15 with SMTP id t15mr948347pyl; Thu, 22 Jun 2006 04:00:04 -0700 (PDT) Received: from alyrion.local ( [144.139.19.209]) by mx.gmail.com with ESMTP id w28sm110735pyc.2006.06.22.04.00.02; Thu, 22 Jun 2006 04:00:04 -0700 (PDT) Subject: Re: MLQ: Followup From: "James \"Doc\" Livingston" To: gnome-multimedia@gnome.org In-Reply-To: References: Content-Type: text/plain Date: Thu, 22 Jun 2006 20:59:59 +1000 Message-Id: <1150973999.5186.17.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.317 tagged_above=-999 required=2 tests=[AWL=0.283, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.317 X-Spam-Level: X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: doclivingston@gmail.com List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 11:00:08 -0000 On Thu, 2006-06-22 at 11:32 +0200, Milosz Derezynski wrote: > One benefit of MLQs over 'regular' playlists at least with BMP 2 is > that i've introduced a concept of keeping track of tracks across mount > point changes which basically works like this: > So the benefit of an MLQ is that unlike a static playlist, you can be > rather sure that no matter where you really move the music, BMP will > always be able to find it. I'm a bit confused about how "HAL UDI + partial path" is related to the MLQ idea. To me they seem fairly orthogonal. However using HAL UDIs is a good idea. Most apps currently use the URI as it's unique identifier and the method of finding the actual file, we could decide that the common db would use a as the unique id/location method. > Downsides/doesn't-works: > - There is no volume UDI available If this is a permanent thing, e.g. a non-HAL system or a http:// resource, then we could say that a null UDI and the full uri would be used instead. If it's temporary, e.g. HAL isn't running, or isn't detecting the device properly, then it's probably more complicated. Dealing with the fact that the users music is stored as and we don't know the URI would be funky. Perhaps we could say all db entries have the field, and a "last known"/non-HAL location field. > - You make a regular 'move' (mv), and not just a remount That is different again, and is probably best solved with audio fingerprinting, and/or embedding unique metadata in the file. Cheers. James "Doc" Livingston -- If USENET is anarchy, IRC is a paranoid schizophrenic after 6 days on speed. -- Chris "Saundo" Saunderson in asr. From doclivingston@gmail.com Thu Jun 22 07:04:28 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CFF783B0254 for ; Thu, 22 Jun 2006 07:04:28 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18854-05 for ; Thu, 22 Jun 2006 07:04:27 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by menubar.gnome.org (Postfix) with ESMTP id 0309C3B05B2 for ; Thu, 22 Jun 2006 07:04:26 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id f28so267516pyf for ; Thu, 22 Jun 2006 04:04:26 -0700 (PDT) Received: by 10.35.82.15 with SMTP id j15mr949278pyl; Thu, 22 Jun 2006 04:04:26 -0700 (PDT) Received: from alyrion.local ( [144.139.19.209]) by mx.gmail.com with ESMTP id w66sm860753pyw.2006.06.22.04.04.24; Thu, 22 Jun 2006 04:04:26 -0700 (PDT) Subject: Re: MLQ (Media Library Query) file format and mime type proposal From: "James \"Doc\" Livingston" To: gnome-multimedia@gnome.org In-Reply-To: References: Content-Type: text/plain Date: Thu, 22 Jun 2006 21:04:21 +1000 Message-Id: <1150974261.5186.22.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.319 tagged_above=-999 required=2 tests=[AWL=0.281, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.319 X-Spam-Level: X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: doclivingston@gmail.com List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 11:04:29 -0000 On Thu, 2006-06-22 at 11:25 +0200, Milosz Derezynski wrote: > I'm one of the main authors of BMP 2 (still being worked on), and > along the way of reworking our library, i came across the idea of > encoding library queries as URIs, which may look like this: > > "query:///?artist=Air&album=Moon%20Safari" > Adding a file of this type to BMPx, or just a plain query:/// URI > itself causes a library query and appending of the relevant items to > the tracklist (BMP is currently mostly based on the concept of a > mutable playlist to which items can be added from various sources, > unlike e.g. RB which has mostly immutable "Playlists", but allows for > custom queues). I'm a bit confused as to what this is actually for. Is it meant for saving "smart playlist"-type (or other db queries) things to disk? If so, it's probably better to use one of the existing query formats. If we want to use XML, then RDF (which is what Tracker uses for all it's queries) is probably as good as anything. James "Doc" Livingston -- "The Web brings people together because no matter what kind of a twisted sexual mutant you happen to be, you've got millions of pals out there. Type in 'Find people that have sex with goats that are on fire' and the computer will ask, 'Specify type of goat.'" -- Rich Jeni From internalerror@gmail.com Thu Jun 22 07:35:27 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BBE833B064F for ; Thu, 22 Jun 2006 07:35:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20711-02 for ; Thu, 22 Jun 2006 07:35:26 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.197]) by menubar.gnome.org (Postfix) with ESMTP id 1F4E83B0528 for ; Thu, 22 Jun 2006 07:35:26 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so334141wxc for ; Thu, 22 Jun 2006 04:35:26 -0700 (PDT) Received: by 10.70.65.10 with SMTP id n10mr2935604wxa; Thu, 22 Jun 2006 04:35:25 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 04:35:25 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 13:35:25 +0200 From: "Milosz Derezynski" To: doclivingston@gmail.com Subject: Re: MLQ: Followup In-Reply-To: <1150973999.5186.17.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3961_29338319.1150976125920" References: <1150973999.5186.17.camel@localhost.localdomain> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.246 tagged_above=-999 required=2 tests=[AWL=0.353, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.246 X-Spam-Level: Cc: gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 11:35:27 -0000 ------=_Part_3961_29338319.1150976125920 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/22/06, James Doc Livingston wrote: If it's temporary, e.g. HAL isn't running, or isn't detecting the device > properly, then it's probably more complicated. Dealing with the fact > that the users music is stored as and we don't know the URI > would be funky. Perhaps we could say all db entries have the > field, and a "last known"/non-HAL location field. > That's what i'm currently doing, i store the full URI, but also the UDI and the partial path, and in case HAL is not avaiable there is still the full URI present as a current resort. The ideal situation would be that HAL would be always available, would have UDIs for all volumes, and would run on all systems we need to run this to (Including let's say Solaris, etc), in which case it would be exactly what you said, one would need to only store the volume UDI and the partial path. Well anyway, repeating myself, just wanted to add that we also already store the full URI as a backup. ------=_Part_3961_29338319.1150976125920 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 6/22/06, James Doc Livingston <doclivingston@gmail.com> wrote:

If it's temporary, e.g. HAL isn't running, or isn't detecting the device
properly, then it's probably more complicated. Dealing with the fact
that the users music is stored as <UDI, path> and we don't know the URI
would be funky. Perhaps we could say all db entries have the <UDI, path>
field, and a "last known"/non-HAL location field.


That's what i'm currently doing, i store the full URI, but also the UDI and the partial path,
and in case HAL is not avaiable there is still the full URI present as a current resort.

The ideal situation would be that HAL would be always available, would have UDIs for all
volumes, and would run on all systems we need to run this to (Including let's say Solaris,
etc), in which case it would be exactly what you said, one would need to only store the volume
UDI and the partial path. Well anyway, repeating myself, just wanted to add that we also
already store the full URI as a backup.
------=_Part_3961_29338319.1150976125920-- From internalerror@gmail.com Thu Jun 22 12:04:05 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 802573B0830 for ; Thu, 22 Jun 2006 12:04:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07916-06 for ; Thu, 22 Jun 2006 12:04:01 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.201]) by menubar.gnome.org (Postfix) with ESMTP id 35C833B083F for ; Thu, 22 Jun 2006 12:01:33 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so373874wxc for ; Thu, 22 Jun 2006 09:01:32 -0700 (PDT) Received: by 10.70.83.20 with SMTP id g20mr3337015wxb; Thu, 22 Jun 2006 09:01:32 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 09:01:32 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 18:01:32 +0200 From: "Milosz Derezynski" To: "Frans Englich" Subject: Re: MLQ (Media Library Query) file format and mime type proposal In-Reply-To: <200606221419.00204.frans.englich@telia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7583_10781705.1150992092417" References: <200606221419.00204.frans.englich@telia.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.073 tagged_above=-999 required=2 tests=[AWL=0.152, BAYES_00=-2.599, HTML_30_40=0.374, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.073 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 16:04:05 -0000 ------=_Part_7583_10781705.1150992092417 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/22/06, Frans Englich wrote: > > On Thursday 22 June 2006 09:25, Milosz Derezynski wrote: > > Hi, > > > > I'm one of the main authors of BMP 2 (still being worked on), and along > the > > way of reworking our library, i came across the idea of encoding library > > queries as URIs, which may look like this: > > > > "query:///?artist=Air&album=Moon%20Safari" > > (Is that at all a valid URI? I'm not sure.) I think it is valid yes. First of all, one can't simply invent ones own URI scheme, because it causes > trouble. Especially, for such a generic name as "query". This document > discusses this further: > > http://developer.kde.org/policies/uri-guidelines.xhtml > > How is interoperability for "query" ensured? Is it specified? Not at all yet but because of that i'm asking on those 2 lists here now (xdg and gnome-multimedia), and furthermore i made some interoperability proposals, just 2 totally off my head but not totally out of place either. > BMP 2 has a plugin archicture which is a small VFS on it's own, and we > > treat certain things as "containers" (i.e. they "contain" URIs, like PLS > > playlists, XSPF, M3U, etc). > > Now i thought it might be not a bad idea to create a playlist format > with > > these query URLs, and i've called it "MLQ" for media library query. In > > theory, it's not even > > application specific. The keys (identifiers), like artist, album, etc, > are > > all based on GStreamer tag identifiers. (They could be maybe adapted to > > http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , > but > > it seems insufficient and doesn't specify certain items, like > musicbrainz > > metadata, which GST does). > > > > So i've called this file format "MLQ", with the extension .mlq, created > a > > mime package file for it: > > I think this highlights possible trouble. Anyone else who decides to > invent "query" will get detected as "Media Library Query List". All that's > needed to fix this is to use URIs properly. Yeah well that is problematic for them haha :P > However, I wouldn't invent a new URI scheme for this, it's too context > dependent. Music players & hardware(ipods, music players, music sharing > sites, and so on) is quite popular in western societies right now, but > next > year it's something different. Technologies, such as a URI scheme, > shouldn't > be hard coded on a specific use, it should be generic. > > Re-use existing technologies. There's plenty of work and research on meta > data > and querying data. Here's my suggestions: > > Express the format in XML. This has nothing to do with XML files("text"), > unless one wants to. It means the format is conceptually, on an "abstract" > level, described in XML which in turn opens up the door for all methods > XML > has. > > For example, one could use an XPointer fragment with an XPath scheme: > > file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album > = 'Safari')) > > If "music collections" cannot be located as files, invent a scheme which > can > identify them on this "abstract level." That is actually a very good idea (to use an XPath), but then again i would be abusing the file:/// scheme. What should it point to? Even if it would point to the physical location of the database file, in my specific case this would be ~/.local/share/bmpx/library.mlib, so file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz and @album='Safari')), then i would be basically still "making something up", as you cannot pass THIS uri to, say, a filemanager, and it would recognize it and do the correct thing. Now of course it won't recognize query:/// either, but i made 2 proposals which would spec query:/// in this way system wide. What i'm up to is that while your proposal with file seems more sane (and XPath/XPointer is certainly better than using a GET string, i might really consider changing the query:/// URI to use that), it actually is no different. Those kinds of file:/// URIs would need special treatment as well, and in fact, would cause even more headache possibly, as file:/// _IS_ already a known scheme which is already specced etc, etd. However, I would first assess RDF as suggested in this thread, since it is > designed exactly for things like this. Well RDF possibly, but i think i will never in my life use SPARQL. I took a look at it and i want these things if not neccessarily, then at least possibly, human editable, buit SPARQL is just way beyond the comprehension of taking a quick glance at the file and making some corrections. > > Cheers, > > Frans > -- Milosz ------=_Part_7583_10781705.1150992092417 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 6/22/06, Frans Englich <frans.englich@telia.com> wrote:
On Thursday 22 June 2006 09:25, Milosz Derezynski wrote:
> Hi,
>
> I'm one of the main authors of BMP 2 (still being worked on), and along the
> way of reworking our library, i came across the idea of encoding library
> queries as URIs, which may look like this:
>
> "query:///?artist=Air&album=Moon%20Safari"

(Is that at all a valid URI? I'm not sure.)

I think it is valid yes.

First of all, one can't simply invent ones own URI scheme, because it causes
trouble. Especially, for such a generic name as "query". This document
discusses this further:

http://developer.kde.org/policies/uri-guidelines.xhtml

How is interoperability for "query" ensured? Is it specified?

Not at all yet but  because of that i'm asking on those 2 lists here now (xdg
and gnome-multimedia), and furthermore i made some interoperability
proposals, just 2 totally off my head but not totally out of place either.
 

> BMP 2 has a plugin archicture which is a small VFS on it's own, and we
> treat certain things as "containers" (i.e. they "contain" URIs, like PLS
> playlists, XSPF, M3U, etc).
> Now i thought it might be not a bad idea to create a playlist format with
> these query URLs, and i've called it "MLQ" for media library query. In
> theory, it's not even
> application specific. The keys (identifiers), like artist, album, etc, are
> all based on GStreamer tag identifiers. (They could be maybe adapted to
> http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but
> it seems insufficient and doesn't specify certain items, like musicbrainz
> metadata, which GST does).
>
> So i've called this file format "MLQ", with the extension .mlq, created a
> mime package file for it:

I think this highlights possible trouble. Anyone else who decides to
invent "query" will get detected as "Media Library Query List". All that's
needed to fix this is to use URIs properly.

Yeah well that is problematic for them haha :P
 
However, I wouldn't invent a new URI scheme for this, it's too context
dependent. Music players & hardware(ipods, music players, music sharing
sites, and so on) is quite popular in western societies right now, but next
year it's something different. Technologies, such as a URI scheme, shouldn't
be hard coded on a specific use, it should be generic.

Re-use existing technologies. There's plenty of work and research on meta data
and querying data. Here's my suggestions:

Express the format in XML. This has nothing to do with XML files("text"),
unless one wants to. It means the format is conceptually, on an "abstract"
level, described in XML which in turn opens up the door for all methods XML
has.

For example, one could use an XPointer fragment with an XPath scheme:

file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album
= 'Safari'))

If "music collections" cannot be located as files, invent a scheme which can
identify them on this "abstract level."


That is actually a very good idea (to use an XPath), but then again i would be abusing
the file:/// scheme. What should it point to? Even if it would point to the physical location
of the database file, in my specific case this would be ~/.local/share/bmpx/library.mlib,
so file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz
and @album='Safari')), then i would be basically still "making something up", as you cannot
pass THIS uri to, say, a filemanager, and it would recognize it and do the correct thing.

Now of course it won't recognize query:/// either, but i made 2 proposals which would spec
query:/// in this way system wide.

What i'm up to is that while your proposal with file seems
more sane (and XPath/XPointer is certainly better than using a GET string, i might really
consider changing the query:/// URI to use that), it actually is no different. Those kinds of
file:/// URIs would need special treatment as well, and in fact, would cause even more headache
possibly, as file:/// _IS_ already a known scheme which is already specced etc, etd.
 

However, I would first assess RDF as suggested in this thread, since it is
designed exactly for things like this.

Well RDF possibly, but i think i will never in  my life use SPARQL. I took a look at it
and i want these things if not neccessarily, then at least possibly, human editable,
buit SPARQL is just way beyond the comprehension of taking a quick glance at the
file and making some corrections.
 

Cheers,

                Frans


-- Milosz
------=_Part_7583_10781705.1150992092417-- From internalerror@gmail.com Thu Jun 22 12:13:45 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5FD223B0389 for ; Thu, 22 Jun 2006 12:13:45 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08581-05 for ; Thu, 22 Jun 2006 12:13:43 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.205]) by menubar.gnome.org (Postfix) with ESMTP id B81413B01D2 for ; Thu, 22 Jun 2006 12:13:42 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so375754wxc for ; Thu, 22 Jun 2006 09:13:42 -0700 (PDT) Received: by 10.70.18.10 with SMTP id 10mr3379733wxr; Thu, 22 Jun 2006 09:13:42 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 09:13:41 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 18:13:41 +0200 From: "Milosz Derezynski" To: "Frans Englich" Subject: Re: MLQ (Media Library Query) file format and mime type proposal In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7734_19670285.1150992821952" References: <200606221419.00204.frans.englich@telia.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.079 tagged_above=-999 required=2 tests=[AWL=0.146, BAYES_00=-2.599, HTML_30_40=0.374, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.079 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 16:13:45 -0000 ------=_Part_7734_19670285.1150992821952 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I didn't know about tag URIs though, i'm taking a look at it now, thanks. On 6/22/06, Milosz Derezynski wrote: > > > > On 6/22/06, Frans Englich wrote: > > > > On Thursday 22 June 2006 09:25, Milosz Derezynski wrote: > > > Hi, > > > > > > I'm one of the main authors of BMP 2 (still being worked on), and > > along the > > > way of reworking our library, i came across the idea of encoding > > library > > > queries as URIs, which may look like this: > > > > > > "query:///?artist=Air&album=Moon%20Safari" > > > > (Is that at all a valid URI? I'm not sure.) > > > I think it is valid yes. > > First of all, one can't simply invent ones own URI scheme, because it > > causes > > trouble. Especially, for such a generic name as "query". This document > > discusses this further: > > > > http://developer.kde.org/policies/uri-guidelines.xhtml > > > > How is interoperability for "query" ensured? Is it specified? > > > Not at all yet but because of that i'm asking on those 2 lists here now > (xdg > and gnome-multimedia), and furthermore i made some interoperability > proposals, just 2 totally off my head but not totally out of place either. > > > > BMP 2 has a plugin archicture which is a small VFS on it's own, and we > > > treat certain things as "containers" (i.e. they "contain" URIs, like > > PLS > > > playlists, XSPF, M3U, etc). > > > Now i thought it might be not a bad idea to create a playlist format > > with > > > these query URLs, and i've called it "MLQ" for media library query. In > > > theory, it's not even > > > application specific. The keys (identifiers), like artist, album, etc, > > are > > > all based on GStreamer tag identifiers. (They could be maybe adapted > > to > > > http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , > > but > > > it seems insufficient and doesn't specify certain items, like > > musicbrainz > > > metadata, which GST does). > > > > > > So i've called this file format "MLQ", with the extension .mlq, > > created a > > > mime package file for it: > > > > I think this highlights possible trouble. Anyone else who decides to > > invent "query" will get detected as "Media Library Query List". All > > that's > > needed to fix this is to use URIs properly. > > > Yeah well that is problematic for them haha :P > > > > However, I wouldn't invent a new URI scheme for this, it's too context > > dependent. Music players & hardware(ipods, music players, music sharing > > sites, and so on) is quite popular in western societies right now, but > > next > > year it's something different. Technologies, such as a URI scheme, > > shouldn't > > be hard coded on a specific use, it should be generic. > > > > Re-use existing technologies. There's plenty of work and research on > > meta data > > and querying data. Here's my suggestions: > > > > Express the format in XML. This has nothing to do with XML > > files("text"), > > unless one wants to. It means the format is conceptually, on an > > "abstract" > > level, described in XML which in turn opens up the door for all methods > > XML > > has. > > > > For example, one could use an XPointer fragment with an XPath scheme: > > > > file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album > > = 'Safari')) > > > > If "music collections" cannot be located as files, invent a scheme which > > can > > identify them on this "abstract level." > > > > That is actually a very good idea (to use an XPath), but then again i > would be abusing > the file:/// scheme. What should it point to? Even if it would point to > the physical location > of the database file, in my specific case this would be > ~/.local/share/bmpx/library.mlib, > so file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz > > and @album='Safari')), then i would be basically still "making something > up", as you cannot > pass THIS uri to, say, a filemanager, and it would recognize it and do the > correct thing. > > Now of course it won't recognize query:/// either, but i made 2 proposals > which would spec > query:/// in this way system wide. > > What i'm up to is that while your proposal with file seems > more sane (and XPath/XPointer is certainly better than using a GET string, > i might really > consider changing the query:/// URI to use that), it actually is no > different. Those kinds of > file:/// URIs would need special treatment as well, and in fact, would > cause even more headache > possibly, as file:/// _IS_ already a known scheme which is already specced > etc, etd. > > > However, I would first assess RDF as suggested in this thread, since it is > > designed exactly for things like this. > > > Well RDF possibly, but i think i will never in my life use SPARQL. I took > a look at it > and i want these things if not neccessarily, then at least possibly, human > editable, > buit SPARQL is just way beyond the comprehension of taking a quick glance > at the > file and making some corrections. > > > > > > Cheers, > > > > Frans > > > > > -- Milosz > ------=_Part_7734_19670285.1150992821952 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I didn't know about tag URIs though, i'm taking a look at it now, thanks.

On 6/22/06, Milosz Derezynski <internalerror@gmail.com > wrote:


On 6/22/06, Frans Englich <frans.englich@telia.com> wrote:
On Thursday 22 June 2006 09:25, Milosz Derezynski wrote:
> Hi,
>
> I'm one of the main authors of BMP 2 (still being worked on), and along the
> way of reworking our library, i came across the idea of encoding library
> queries as URIs, which may look like this:
>
> "query:///?artist=Air&album=Moon%20Safari"

(Is that at all a valid URI? I'm not sure.)

I think it is valid yes.

First of all, one can't simply invent ones own URI scheme, because it causes
trouble. Especially, for such a generic name as "query". This document
discusses this further:

http://developer.kde.org/policies/uri-guidelines.xhtml

How is interoperability for "query" ensured? Is it specified?

Not at all yet but  because of that i'm asking on those 2 lists here now (xdg
and gnome-multimedia), and furthermore i made some interoperability
proposals, just 2 totally off my head but not totally out of place either.
 

> BMP 2 has a plugin archicture which is a small VFS on it's own, and we
> treat certain things as "containers" (i.e. they "contain" URIs, like PLS
> playlists, XSPF, M3U, etc).
> Now i thought it might be not a bad idea to create a playlist format with
> these query URLs, and i've called it "MLQ" for media library query. In
> theory, it's not even
> application specific. The keys (identifiers), like artist, album, etc, are
> all based on GStreamer tag identifiers. (They could be maybe adapted to
> http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but
> it seems insufficient and doesn't specify certain items, like musicbrainz
> metadata, which GST does).
>
> So i've called this file format "MLQ", with the extension .mlq, created a
> mime package file for it:

I think this highlights possible trouble. Anyone else who decides to
invent "query" will get detected as "Media Library Query List". All that's
needed to fix this is to use URIs properly.

Yeah well that is problematic for them haha :P
 
However, I wouldn't invent a new URI scheme for this, it's too context
dependent. Music players & hardware(ipods, music players, music sharing
sites, and so on) is quite popular in western societies right now, but next
year it's something different. Technologies, such as a URI scheme, shouldn't
be hard coded on a specific use, it should be generic.

Re-use existing technologies. There's plenty of work and research on meta data
and querying data. Here's my suggestions:

Express the format in XML. This has nothing to do with XML files("text"),
unless one wants to. It means the format is conceptually, on an "abstract"
level, described in XML which in turn opens up the door for all methods XML
has.

For example, one could use an XPointer fragment with an XPath scheme:

file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album
= 'Safari'))

If "music collections" cannot be located as files, invent a scheme which can
identify them on this "abstract level."


That is actually a very good idea (to use an XPath), but then again i would be abusing
the file:/// scheme. What should it point to? Even if it would point to the physical location
of the database file, in my specific case this would be ~/.local/share/bmpx/library.mlib,
so file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz
and @album='Safari')), then i would be basically still "making something up", as you cannot
pass THIS uri to, say, a filemanager, and it would recognize it and do the correct thing.

Now of course it won't recognize query:/// either, but i made 2 proposals which would spec
query:/// in this way system wide.

What i'm up to is that while your proposal with file seems
more sane (and XPath/XPointer is certainly better than using a GET string, i might really
consider changing the query:/// URI to use that), it actually is no different. Those kinds of
file:/// URIs would need special treatment as well, and in fact, would cause even more headache
possibly, as file:/// _IS_ already a known scheme which is already specced etc, etd.
 

However, I would first assess RDF as suggested in this thread, since it is
designed exactly for things like this.

Well RDF possibly, but i think i will never in  my life use SPARQL. I took a look at it
and i want these things if not neccessarily, then at least possibly, human editable,
buit SPARQL is just way beyond the comprehension of taking a quick glance at the
file and making some corrections.
 

Cheers,

                Frans


-- Milosz

------=_Part_7734_19670285.1150992821952-- From frans.englich@telia.com Thu Jun 22 10:05:56 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 164263B085B for ; Thu, 22 Jun 2006 10:05:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00797-01 for ; Thu, 22 Jun 2006 10:05:48 -0400 (EDT) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by menubar.gnome.org (Postfix) with ESMTP id 4FFD63B081B for ; Thu, 22 Jun 2006 10:05:38 -0400 (EDT) X-T2-Posting-ID: 2yF4ydxc0UI9xI7FHZPfog== X-Cloudmark-Score: 0.000000 [] Received: from 83.72.134.122.ip.tele2adsl.dk ([83.72.134.122] verified) by mailfe08.swip.net (CommuniGate Pro SMTP 5.0.8) with ESMTP id 217821068; Thu, 22 Jun 2006 16:05:36 +0200 From: Frans Englich To: xdg@lists.freedesktop.org Subject: Re: MLQ (Media Library Query) file format and mime type proposal Date: Thu, 22 Jun 2006 14:18:59 +0000 User-Agent: KMail/1.8.50 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606221419.00204.frans.englich@telia.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.051 tagged_above=-999 required=2 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_NUMERIC_HELO=1.5] X-Spam-Score: -1.051 X-Spam-Level: X-Mailman-Approved-At: Thu, 22 Jun 2006 12:45:56 -0400 Cc: gnome-multimedia@gnome.org, Milosz Derezynski X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 14:05:56 -0000 On Thursday 22 June 2006 09:25, Milosz Derezynski wrote: > Hi, > > I'm one of the main authors of BMP 2 (still being worked on), and along the > way of reworking our library, i came across the idea of encoding library > queries as URIs, which may look like this: > > "query:///?artist=Air&album=Moon%20Safari" (Is that at all a valid URI? I'm not sure.) First of all, one can't simply invent ones own URI scheme, because it causes trouble. Especially, for such a generic name as "query". This document discusses this further: http://developer.kde.org/policies/uri-guidelines.xhtml How is interoperability for "query" ensured? Is it specified? > BMP 2 has a plugin archicture which is a small VFS on it's own, and we > treat certain things as "containers" (i.e. they "contain" URIs, like PLS > playlists, XSPF, M3U, etc). > Now i thought it might be not a bad idea to create a playlist format with > these query URLs, and i've called it "MLQ" for media library query. In > theory, it's not even > application specific. The keys (identifiers), like artist, album, etc, are > all based on GStreamer tag identifiers. (They could be maybe adapted to > http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but > it seems insufficient and doesn't specify certain items, like musicbrainz > metadata, which GST does). > > So i've called this file format "MLQ", with the extension .mlq, created a > mime package file for it: I think this highlights possible trouble. Anyone else who decides to invent "query" will get detected as "Media Library Query List". All that's needed to fix this is to use URIs properly. However, I wouldn't invent a new URI scheme for this, it's too context dependent. Music players & hardware(ipods, music players, music sharing sites, and so on) is quite popular in western societies right now, but next year it's something different. Technologies, such as a URI scheme, shouldn't be hard coded on a specific use, it should be generic. Re-use existing technologies. There's plenty of work and research on meta data and querying data. Here's my suggestions: Express the format in XML. This has nothing to do with XML files("text"), unless one wants to. It means the format is conceptually, on an "abstract" level, described in XML which in turn opens up the door for all methods XML has. For example, one could use an XPointer fragment with an XPath scheme: file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album = 'Safari')) If "music collections" cannot be located as files, invent a scheme which can identify them on this "abstract level." However, I would first assess RDF as suggested in this thread, since it is designed exactly for things like this. In this way one doesn't have to invent a whole query language for music files. That's like inventing C++ for writing games, C++ for fixing bugs in word processors, C++ for writing editors, and so on. Cheers, Frans From internalerror@gmail.com Thu Jun 22 13:17:35 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 614C33B0693 for ; Thu, 22 Jun 2006 13:17:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12677-02 for ; Thu, 22 Jun 2006 13:17:34 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.201]) by menubar.gnome.org (Postfix) with ESMTP id 0CBD83B06C8 for ; Thu, 22 Jun 2006 13:17:33 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so385228wxc for ; Thu, 22 Jun 2006 10:17:33 -0700 (PDT) Received: by 10.70.110.18 with SMTP id i18mr3484207wxc; Thu, 22 Jun 2006 10:17:33 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 10:17:33 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 19:17:33 +0200 From: "Milosz Derezynski" To: "Frans Englich" Subject: Re: MLQ (Media Library Query) file format and mime type proposal In-Reply-To: <200606221419.00204.frans.englich@telia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8538_10618378.1150996653355" References: <200606221419.00204.frans.englich@telia.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.272 tagged_above=-999 required=2 tests=[AWL=0.327, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.272 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 17:17:35 -0000 ------=_Part_8538_10618378.1150996653355 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/22/06, Frans Englich wrote: > > On Thursday 22 June 2006 09:25, Milosz Derezynski wrote: > > I think this highlights possible trouble. Anyone else who decides to > invent "query" will get detected as "Media Library Query List". All that's > needed to fix this is to use URIs properly. > I've changed the file magic so that the first line has to be "#MLQ", and our MLQ exporter writes them like that and recognizes them only like that, and i've updated the mime XML spec to recognize them this way. This is no better or worse than "#EXTM3U" for .m3u playlists, so i don't think there is any problem here now. As for the URIs themselves, i wasn't yet speaking of "open" use of them (outside of .mlq files), but only within them, so this change of the file magic should prevent problems with anything else that might use a query:/// URI in their file formats. -- Milosz ------=_Part_8538_10618378.1150996653355 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 6/22/06, Frans Englich <frans.englich@telia.com> wrote:
On Thursday 22 June 2006 09:25, Milosz Derezynski wrote:

I think this highlights possible trouble. Anyone else who decides to
invent "query" will get detected as "Media Library Query List". All that's
needed to fix this is to use URIs properly.

I've changed the file magic so that the first line has to be "#MLQ", and our
MLQ exporter writes them like that and recognizes them only like that, and i've
updated the mime XML spec to recognize them this way.  This is no better or worse than
"#EXTM3U" for .m3u playlists, so i don't think there is any problem here now.
As for the URIs themselves, i wasn't yet speaking of "open" use of them (outside of .mlq files),
but only within them, so this change of the file magic should prevent problems with
anything else that might use a query:/// URI in their file formats.

-- Milosz
------=_Part_8538_10618378.1150996653355-- From doclivingston@gmail.com Wed Jun 7 10:49:16 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 6DFBE3B0CC1 for ; Wed, 7 Jun 2006 10:49:16 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21939-01 for ; Wed, 7 Jun 2006 10:49:15 -0400 (EDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.229]) by menubar.gnome.org (Postfix) with ESMTP id D14723B03C1 for ; Wed, 7 Jun 2006 10:49:14 -0400 (EDT) Received: by wr-out-0506.google.com with SMTP id 50so195010wri for ; Wed, 07 Jun 2006 07:49:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:reply-to:to:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=D3/oYUbzoxrxaC8A9PmKhslTLvhndfLfj1yY1UbjWdxPLOVTGGtYcu0ciGotAkdC9rpqkdcPnVZMxJ6dpbOroKn3+pabYkPihqGfxJAljTjii14F9PbbIilMLHmiNyw9SX693UyHiryeZOKfQoct7i10NaO3a8zimwOM5qcjmis= Received: by 10.65.232.13 with SMTP id j13mr502626qbr; Wed, 07 Jun 2006 07:49:14 -0700 (PDT) Received: from alyrion.local ( [144.139.19.99]) by mx.gmail.com with ESMTP id e14sm242982qba.2006.06.07.07.49.12; Wed, 07 Jun 2006 07:49:14 -0700 (PDT) From: "James \"Doc\" Livingston" To: gnome-multimedia@gnome.org Content-Type: text/plain Date: Thu, 08 Jun 2006 00:49:05 +1000 Message-Id: <1149691745.5417.19.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.309 tagged_above=-999 required=2 tests=[AWL=0.291, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.309 X-Spam-Level: Subject: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: doclivingston@gmail.com List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 14:49:16 -0000 G'day everyone, Currently various multi-media application behave differently when the "scrolling" (up/down arrow, page up/down mouse wheel) actions are performed on their seek slider. There have been bugs (at least 164351 and 330570) filed against several applications asking that they behave like others, and it would be good to have consistent behaviour. Essentially the questions is what should happen when the user performs these actions? Should the "up" actions seek forward in time, seek back in time, or do nothing? Currently Totem and Gnome Sound Recorder map "up" to seek forwards in time, Sound-Juicer and Rhythmbox map "up" to seek back in time, and Banshee and Muine don't seek when the user does this. Which is correct is a matter of debate, and when I started a discussion about this on #gnome-hackers (which obviously isn't filled with "average users") a while back, people seemed to be split roughly equally between the options. Some of the point for up=forwards are: * people associate up with increasing the time from the start Some of the point for up=backwards are: * people associate up with increasing the time remaining (only applicable if it's shown to the user) * people associate up with "going towards the start", like for documents/web pages Some of the point for taking no action: * these are "vertical" scroll events and the slider is horizontal, so should do nothing Regardless of which is generally considered "best", I think having it consistent between application is important. Cheers, James "Doc" Livingston -- [Request for the names of the kings who became Nazgul] Dashur, Daensir, Prantsur, Vicksinn, Comuet, Cupuid, Dondor, Blitsun, and Rodulf, Witch-King of Angmar. -- Joseph Michael Bay From hadess@hadess.net Wed Jun 7 10:58:17 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 067753B0272 for ; Wed, 7 Jun 2006 10:58:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22613-04 for ; Wed, 7 Jun 2006 10:58:16 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id EA5A23B03C4 for ; Wed, 7 Jun 2006 10:58:15 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57EwBfm003839; Wed, 7 Jun 2006 10:58:11 -0400 Received: from pobox.surrey.redhat.com (pobox.surrey.redhat.com [172.16.10.17]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57EwASg001552; Wed, 7 Jun 2006 10:58:10 -0400 Received: from bnocera.surrey.redhat.com (bnocera.surrey.redhat.com [172.16.10.53]) by pobox.surrey.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57Ew9om000601; Wed, 7 Jun 2006 15:58:09 +0100 From: Bastien Nocera To: doclivingston@gmail.com In-Reply-To: <1149691745.5417.19.camel@localhost.localdomain> References: <1149691745.5417.19.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8 Date: Wed, 07 Jun 2006 15:58:09 +0100 Message-Id: <1149692289.14668.24.camel@bnocera.surrey.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-27) Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.954 tagged_above=-999 required=2 tests=[AWL=-0.496, BAYES_00=-2.599, SPF_FAIL=1.142, SPF_HELO_PASS=-0.001] X-Spam-Score: -1.954 X-Spam-Level: Cc: gnome-multimedia@gnome.org Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 14:58:17 -0000 On Thu, 2006-06-08 at 00:49 +1000, James "Doc" Livingston wrote: > G'day everyone, > Essentially the questions is what should happen when the user performs > these actions? Should the "up" actions seek forward in time, seek back > in time, or do nothing? Same problem for the volume sliders by default. Obviously, I think that apps should seek forward in time with up, and backwards with down. And I also think that when scrolling down, the step should be shorter than when moving forward (because it makes it easier to find precise points in the timeline). Maybe we need to move things like the volume widget, and some "seek sliders" to a library like gnome-media? -- Bastien Nocera If I'm not challenged, I can do nothing. Maybe my next film will be in Japanese. -- Alejandro González Iñárittu From abockover@novell.com Wed Jun 7 11:08:04 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C6EB33B022D for ; Wed, 7 Jun 2006 11:08:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23164-09 for ; Wed, 7 Jun 2006 11:08:04 -0400 (EDT) Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.25.9.101]) by menubar.gnome.org (Postfix) with ESMTP id B3F5E3B0127 for ; Wed, 7 Jun 2006 11:08:03 -0400 (EDT) Received: from [192.168.0.101] (cpe-024-162-230-116.nc.res.rr.com [24.162.230.116]) by ms-smtp-02.southeast.rr.com (8.13.6/8.13.6) with ESMTP id k57F7xLC012187; Wed, 7 Jun 2006 11:07:59 -0400 (EDT) From: Aaron Bockover To: doclivingston@gmail.com In-Reply-To: <1149691745.5417.19.camel@localhost.localdomain> References: <1149691745.5417.19.camel@localhost.localdomain> Content-Type: text/plain Date: Wed, 07 Jun 2006 11:04:47 -0400 Message-Id: <1149692687.14205.10.camel@sledipus.rex> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.472 tagged_above=-999 required=2 tests=[AWL=-0.073, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2] X-Spam-Score: -2.472 X-Spam-Level: Cc: gnome-multimedia@gnome.org Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 15:08:05 -0000 On Thu, 2006-06-08 at 00:49 +1000, James "Doc" Livingston wrote: > Currently various multi-media application behave differently when the > "scrolling" (up/down arrow, page up/down mouse wheel) actions are > performed on their seek slider. There have been bugs (at least 164351 > and 330570) filed against several applications asking that they behave > like others, and it would be good to have consistent behaviour. Agreed. > Currently Totem and Gnome Sound Recorder map "up" to seek forwards in > time, Sound-Juicer and Rhythmbox map "up" to seek back in time, and > Banshee and Muine don't seek when the user does this. Banshee (and Muine?) seeks on CTRL+Left/Right. > Some of the point for up=forwards are: > * people associate up with increasing the time from the start > Time is usually displayed on the X axis... sliders for seeking are usually horizontal... so Up/Down keys for this mess with my mind > Some of the point for up=backwards are: > * people associate up with increasing the time remaining (only > applicable if it's shown to the user) > * people associate up with "going towards the start", like for > documents/web pages Again, for me it's more literal connection with visual objects... if I press the right arrow, I am scrolling my time graph "into the future." Volume is my Y axis. > Some of the point for taking no action: > * these are "vertical" scroll events and the slider is horizontal, so > should do nothing I don't think this is should be a no-action case. I think representations just should be "on-axis" (of course feelings are going to differ, this are just how I interpret position) >From a more technical (and possibly usability) standpoint, my objection to up/down is that it's used by and is more important to other widgets (our track views in Banshee/RB), meaning the slider needs focus for the keys to actually seek. In Banshee you can press CTRL+Left/Right anywhere and it seeks. Cheers, Aaron From rbultje@ronald.bitfreak.net Wed Jun 7 11:46:19 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3D92F3B04A2 for ; Wed, 7 Jun 2006 11:46:19 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26037-06 for ; Wed, 7 Jun 2006 11:46:15 -0400 (EDT) Received: from ms-smtp-01.rdc-nyc.rr.com (ms-smtp-01.rdc-nyc.rr.com [24.29.109.5]) by menubar.gnome.org (Postfix) with ESMTP id 8B1693B022D for ; Wed, 7 Jun 2006 11:46:15 -0400 (EDT) Received: from [192.168.0.103] (cpe-66-65-0-167.nyc.res.rr.com [66.65.0.167]) by ms-smtp-01.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id k57Fk2jY021579; Wed, 7 Jun 2006 11:46:13 -0400 (EDT) From: "Ronald S. Bultje" To: Bastien Nocera In-Reply-To: <1149692289.14668.24.camel@bnocera.surrey.redhat.com> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> Content-Type: text/plain Date: Wed, 07 Jun 2006 11:44:22 -0400 Message-Id: <1149695062.2855.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.561 tagged_above=-999 required=2 tests=[AWL=0.038, BAYES_00=-2.599] X-Spam-Score: -2.561 X-Spam-Level: Cc: gnome-multimedia@gnome.org Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 15:46:19 -0000 On Wed, 2006-06-07 at 15:58 +0100, Bastien Nocera wrote: > Maybe we need to move things like the volume widget, and some "seek > sliders" to a library like gnome-media? I would personally prefer libegg (or bacon, where the volume widget resides). I've never really seen gnome-media as a widget-library, but more like a bunch of applications and utilities. I totally don't mind each app making their own copy if such widgets, as long as they update their copy reasonably often. Cheers, Ronald From abockover@novell.com Wed Jun 7 11:58:56 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id D43973B0411 for ; Wed, 7 Jun 2006 11:58:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26954-08 for ; Wed, 7 Jun 2006 11:58:56 -0400 (EDT) Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.25.9.101]) by menubar.gnome.org (Postfix) with ESMTP id 120B23B0D4B for ; Wed, 7 Jun 2006 11:58:56 -0400 (EDT) Received: from [192.168.0.101] (cpe-024-162-230-116.nc.res.rr.com [24.162.230.116]) by ms-smtp-02.southeast.rr.com (8.13.6/8.13.6) with ESMTP id k57FwrFL000910; Wed, 7 Jun 2006 11:58:54 -0400 (EDT) From: Aaron Bockover To: "Ronald S. Bultje" In-Reply-To: <1149695062.2855.2.camel@localhost.localdomain> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> <1149695062.2855.2.camel@localhost.localdomain> Content-Type: text/plain Date: Wed, 07 Jun 2006 11:55:41 -0400 Message-Id: <1149695742.15592.1.camel@sledipus.rex> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.473 tagged_above=-999 required=2 tests=[AWL=-0.074, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2] X-Spam-Score: -2.473 X-Spam-Level: Cc: gnome-multimedia@gnome.org, Bastien Nocera Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 15:58:57 -0000 On Wed, 2006-06-07 at 11:44 -0400, Ronald S. Bultje wrote: > On Wed, 2006-06-07 at 15:58 +0100, Bastien Nocera wrote: > > Maybe we need to move things like the volume widget, and some "seek > > sliders" to a library like gnome-media? > > I would personally prefer libegg (or bacon, where the volume widget > resides). I've never really seen gnome-media as a widget-library, but > more like a bunch of applications and utilities. > > I totally don't mind each app making their own copy if such widgets, as > long as they update their copy reasonably often. I agree here; bacon would probably be best if it were to be in a library, but I think applications providing copies is fine too. I wouldn't want to depend on bacon (or gnome-media) for a widget. --Aaron From hadess@hadess.net Wed Jun 7 12:02:02 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 001A03B0DF9 for ; Wed, 7 Jun 2006 12:02:02 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27399-05 for ; Wed, 7 Jun 2006 12:01:59 -0400 (EDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id 9822B3B0E10 for ; Wed, 7 Jun 2006 12:00:49 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57G0nE9001971; Wed, 7 Jun 2006 12:00:49 -0400 Received: from pobox.surrey.redhat.com (pobox.surrey.redhat.com [172.16.10.17]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57G0mZE021228; Wed, 7 Jun 2006 12:00:48 -0400 Received: from bnocera.surrey.redhat.com (bnocera.surrey.redhat.com [172.16.10.53]) by pobox.surrey.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k57G0lTo006172; Wed, 7 Jun 2006 17:00:47 +0100 From: Bastien Nocera To: Aaron Bockover In-Reply-To: <1149695742.15592.1.camel@sledipus.rex> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> <1149695062.2855.2.camel@localhost.localdomain> <1149695742.15592.1.camel@sledipus.rex> Content-Type: text/plain Date: Wed, 07 Jun 2006 17:00:47 +0100 Message-Id: <1149696047.14668.35.camel@bnocera.surrey.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-27) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.953 tagged_above=-999 required=2 tests=[AWL=-0.495, BAYES_00=-2.599, SPF_FAIL=1.142, SPF_HELO_PASS=-0.001] X-Spam-Score: -1.953 X-Spam-Level: Cc: "Ronald S. Bultje" , gnome-multimedia@gnome.org Subject: Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 16:02:02 -0000 On Wed, 2006-06-07 at 11:55 -0400, Aaron Bockover wrote: > On Wed, 2006-06-07 at 11:44 -0400, Ronald S. Bultje wrote: > > On Wed, 2006-06-07 at 15:58 +0100, Bastien Nocera wrote: > > > Maybe we need to move things like the volume widget, and some "seek > > > sliders" to a library like gnome-media? > > > > I would personally prefer libegg (or bacon, where the volume widget > > resides). I've never really seen gnome-media as a widget-library, but > > more like a bunch of applications and utilities. > > > > I totally don't mind each app making their own copy if such widgets, as > > long as they update their copy reasonably often. > > I agree here; bacon would probably be best if it were to be in a > library, but I think applications providing copies is fine too. I > wouldn't want to depend on bacon (or gnome-media) for a widget. libbacon is a cut'n'paste library like libegg, so not a problem. -- Bastien Nocera Lucas has made a vacuous, boring, pretentious, retroactively destructive sequel. He has lost the plot. The man is a fool. -- Simon Pegg (on the Phantom Menace) From uraeus@linuxrising.org Fri Jun 9 10:13:15 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 91BCF3B01D8 for ; Fri, 9 Jun 2006 10:13:15 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29942-03 for ; Fri, 9 Jun 2006 10:13:14 -0400 (EDT) Received: from mx1.es6.egwn.net (server02.es6.egwn.net [195.10.6.12]) by menubar.gnome.org (Postfix) with ESMTP id E0C263B01BE for ; Fri, 9 Jun 2006 10:13:13 -0400 (EDT) Received: from [192.168.1.235] (core.fluendo.com [195.10.6.237]) by mx1.es6.egwn.net (Postfix) with ESMTP id 9E4AC4F81BC; Fri, 9 Jun 2006 16:13:11 +0200 (CEST) From: Christian Fredrik Kalager Schaller To: Bastien Nocera In-Reply-To: <1149696047.14668.35.camel@bnocera.surrey.redhat.com> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> <1149695062.2855.2.camel@localhost.localdomain> <1149695742.15592.1.camel@sledipus.rex> <1149696047.14668.35.camel@bnocera.surrey.redhat.com> Content-Type: text/plain Date: Fri, 09 Jun 2006 16:11:58 +0200 Message-Id: <1149862318.2356.36.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.397 tagged_above=-999 required=2 tests=[AWL=1.202, BAYES_00=-2.599] X-Spam-Score: -1.397 X-Spam-Level: Cc: "Ronald S. Bultje" , gnome-multimedia@gnome.org Subject: a general multimedia library - Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 14:13:15 -0000 Well the topic of having a multimedia widget library has been discussed multiple times and maybe now is the time to move on it? Currently there are multiple things I see that would be natural to put into such a library: a) the gconf schemas in gnome-media b) the playlist parser library in totem c) the seek sliders widgets mentioned here d) a simple to use GStreamer GTK+ video widget e) others things? Basically this library would/could contain things which are higher level our not directly in the scope of GStreamer. Or which is very GTK+/GNOME related. Christian On Wed, 2006-06-07 at 17:00 +0100, Bastien Nocera wrote: > On Wed, 2006-06-07 at 11:55 -0400, Aaron Bockover wrote: > > On Wed, 2006-06-07 at 11:44 -0400, Ronald S. Bultje wrote: > > > On Wed, 2006-06-07 at 15:58 +0100, Bastien Nocera wrote: > > > > Maybe we need to move things like the volume widget, and some "seek > > > > sliders" to a library like gnome-media? > > > > > > I would personally prefer libegg (or bacon, where the volume widget > > > resides). I've never really seen gnome-media as a widget-library, but > > > more like a bunch of applications and utilities. > > > > > > I totally don't mind each app making their own copy if such widgets, as > > > long as they update their copy reasonably often. > > > > I agree here; bacon would probably be best if it were to be in a > > library, but I think applications providing copies is fine too. I > > wouldn't want to depend on bacon (or gnome-media) for a widget. > > libbacon is a cut'n'paste library like libegg, so not a problem. > From rbultje@ronald.bitfreak.net Fri Jun 9 10:47:45 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id B71663B0413 for ; Fri, 9 Jun 2006 10:47:45 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32342-10 for ; Fri, 9 Jun 2006 10:47:42 -0400 (EDT) Received: from ms-smtp-03.rdc-nyc.rr.com (ms-smtp-03.rdc-nyc.rr.com [24.29.109.7]) by menubar.gnome.org (Postfix) with ESMTP id 215673B0FF1 for ; Fri, 9 Jun 2006 10:47:42 -0400 (EDT) Received: from [192.168.0.103] (cpe-66-65-0-167.nyc.res.rr.com [66.65.0.167]) by ms-smtp-03.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id k59Eld9O019647; Fri, 9 Jun 2006 10:47:40 -0400 (EDT) From: "Ronald S. Bultje" To: Christian Fredrik Kalager Schaller In-Reply-To: <1149862318.2356.36.camel@localhost.localdomain> References: <1149691745.5417.19.camel@localhost.localdomain> <1149692289.14668.24.camel@bnocera.surrey.redhat.com> <1149695062.2855.2.camel@localhost.localdomain> <1149695742.15592.1.camel@sledipus.rex> <1149696047.14668.35.camel@bnocera.surrey.redhat.com> <1149862318.2356.36.camel@localhost.localdomain> Content-Type: text/plain Date: Fri, 09 Jun 2006 10:46:01 -0400 Message-Id: <1149864361.2869.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.563 tagged_above=-999 required=2 tests=[AWL=0.036, BAYES_00=-2.599] X-Spam-Score: -2.563 X-Spam-Level: Cc: gnome-multimedia@gnome.org, Bastien Nocera Subject: Re: a general multimedia library - Re: Scrolling "seek" sliders X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 14:47:45 -0000 Hi, On Fri, 2006-06-09 at 16:11 +0200, Christian Fredrik Kalager Schaller wrote: > Well the topic of having a multimedia widget library has been discussed > multiple times and maybe now is the time to move on it? If someone believes that this would be useful and should be done, then that person should go ahead and do it. Ronald From thomas@apestaart.org Fri Jun 9 15:11:02 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 78FFA3B00E9 for ; Fri, 9 Jun 2006 15:11:02 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15077-08 for ; Fri, 9 Jun 2006 15:11:01 -0400 (EDT) Received: from mx1.es6.egwn.net (server02.es6.egwn.net [195.10.6.12]) by menubar.gnome.org (Postfix) with ESMTP id E94F03B0149 for ; Fri, 9 Jun 2006 15:11:00 -0400 (EDT) Received: from mx1.fr4.egwn.net (server07.fr4.egwn.net [62.39.85.77]) by mx1.es6.egwn.net (Postfix) with ESMTP id 0FC914F822C; Fri, 9 Jun 2006 21:10:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mx1.fr4.egwn.net (spiffy mail daemon) with ESMTP id CB4CC83BFD; Fri, 9 Jun 2006 21:10:47 +0200 (CEST) Received: from mx1.fr4.egwn.net ([127.0.0.1]) by localhost (server07.fr4.egwn.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22095-43; Fri, 9 Jun 2006 21:10:47 +0200 (CEST) Received: from thread.fluendo.lan (core.fluendo.com [195.10.6.237]) by mx1.fr4.egwn.net (spiffy mail daemon) with ESMTP id D8A3283BF8; Fri, 9 Jun 2006 21:10:46 +0200 (CEST) Received: from otto.amantes (thomas.fluendo.lan [192.168.1.10]) by thread.fluendo.lan (Postfix) with ESMTP id 8DDD1FE93; Fri, 9 Jun 2006 21:10:57 +0200 (CEST) Received: from otto.amantes (otto.amantes [127.0.0.1]) by otto.amantes (Postfix) with ESMTP id 9B95DEFC0D; Fri, 9 Jun 2006 21:11:00 +0200 (CEST) Content-Type: multipart/mixed; boundary="127.0.0.1.500.4863.1149880260.533.2" MIME-Version: 1.0 To: gstreamer-devel@lists.sourceforge.net, gstreamer-announce@lists.sourceforge.net, kde-multimedia@kde.org, gnome-multimedia@gnome.org Message-Id: <20060609191100.9B95DEFC0D@otto.amantes> Date: Fri, 9 Jun 2006 21:11:00 +0200 (CEST) From: thomas@apestaart.org X-Scanned: By amavis at egwn.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: Yes, score=2.06 tagged_above=-999 required=2 tests=[AWL=-1.482, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, MIME_BASE64_TEXT=1.885, NO_REAL_NAME=0.961, RCVD_IN_SBL=3.16] X-Spam-Score: 2.06 X-Spam-Level: ** X-Spam-Flag: YES Cc: Subject: RELEASE: GStreamer 0.10.7 'Soepeke, ik zie ou' X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 19:11:02 -0000 --127.0.0.1.500.4863.1149880260.533.2 Content-Type: text/plain This mail announces the release of GStreamer 0.10.7 'Soepeke, ik zie ou'. GStreamer is a streaming media framework that allows the construction of graphs of elements which operate on media data. Applications using this library can do anything from real-time sound processing over playing video to capturing audio, video, and even other types of media data. Its architecture allows for adding new data types or processing capabilities simply by installing new plug-ins. GStreamer is the core module, containing libraries, headers, the basic object hierarchy, and a set of media-agnostic core elements. For more information, see [http://gstreamer.freedesktop.org/modules/gstreamer.html] To file bugs, go to [http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer&component=gstreamer+%28core%29] --127.0.0.1.500.4863.1149880260.533.2 Content-Type: text/plain; name=RELEASE Content-Transfer-Encoding: base64 ClJlbGVhc2Ugbm90ZXMgZm9yIEdTdHJlYW1lcsKgMC4xMC43ICJTb2VwZWtlLCBpayB6aWUgb3Ui CiAgICAgICAgCgoKVGhlIEdTdHJlYW1lciB0ZWFtIGlzIHByb3VkIHRvIGFubm91bmNlIGEgbmV3 IHJlbGVhc2UKaW4gdGhlIDAuMTAueCBzdGFibGUgc2VyaWVzIG9mIHRoZQpjb3JlIG9mIHRoZSBH U3RyZWFtZXIgc3RyZWFtaW5nIG1lZGlhIGZyYW1ld29yay4KCgpUaGUgMC4xMC54IHNlcmllcyBp cyBhIHN0YWJsZSBzZXJpZXMgdGFyZ2V0ZWQgYXQgZW5kIHVzZXJzLgpJdCBpcyBub3QgQVBJIG9y IEFCSSBjb21wYXRpYmxlIHdpdGggdGhlIHN0YWJsZSAwLjgueCBzZXJpZXMuCkl0IGlzLCBob3dl dmVyLCBwYXJhbGxlbCBpbnN0YWxsYWJsZSB3aXRoIHRoZSAwLjgueCBzZXJpZXMuCgoKVGhlIDAu MTAueCBzZXJpZXMgaGFzIGJlZW4gcmV3b3JrZWQgZm9yIHRocmVhZHNhZmV0eS4gIEl0IGFsc28g ZmVhdHVyZXMKdmFyaW91cyBmZWF0dXJlIGFkZGl0aW9ucyBhbmQgZW5jaGFuY2VtZW50cy4KCgpU aGlzIG1vZHVsZSwgZ3N0cmVhbWVyLCBvbmx5IGNvbnRhaW5zIGNvcmUgZnVuY3Rpb25hbGl0eS4K Rm9yIGFjdHVhbCBtZWRpYSBwbGF5YmFjaywgeW91IHdpbGwgbmVlZCBvdGhlciBtb2R1bGVzLgoK Z3N0LXBsdWdpbnMtYmFzZQpjb250YWlucyBhIGJhc2ljIHNldCBvZiB3ZWxsLXN1cHBvcnRlZCBw bHVnLWlucwpnc3QtcGx1Z2lucy1nb29kCmNvbnRhaW5zIGEgc2V0IG9mIHdlbGwtc3VwcG9ydGVk IHBsdWctaW5zIHVuZGVyIG91ciBwcmVmZXJyZWQgbGljZW5zZQpnc3QtcGx1Z2lucy11Z2x5CmNv bnRhaW5zIGEgc2V0IG9mIHdlbGwtc3VwcG9ydGVkIHBsdWctaW5zLCBidXQgbWlnaHQgcG9zZSBw cm9ibGVtcyBmb3IKICAgIGRpc3RyaWJ1dG9ycwpnc3QtcGx1Z2lucy1iYWQKY29udGFpbnMgYSBz ZXQgb2YgbGVzcyBzdXBwb3J0ZWQgcGx1Zy1pbnMgdGhhdCBoYXZlbid0IHBhc3NlZCB0aGUKICAg IHJpZ29yb3VzIHF1YWxpdHkgdGVzdGluZyB3ZSBleHBlY3QKCgoKICAKRmVhdHVyZXMgb2YgdGhp cyByZWxlYXNlCiAgICAKICAgICAgKiBQYXJhbGxlbCBpbnN0YWxsYWJpbGl0eSB3aXRoIDAuOC54 IHNlcmllcwogICAgICAqIFRocmVhZHNhZmUgZGVzaWduIGFuZCBBUEkKICAgICAgKiBSZWdpc3Ry eSBjYWNoZSB1cGRhdGluZyBpcyBub3cgZG9uZSBpbiBhIGZvcmssIHNvIG5vIHBsdWdpbnMgYXJl IGxlZnQgb3BlbmVkCiAgICAgICogTmV3IHZlcnNpb24gb2YgZGF0YSBwcm90b2NvbCBub3cgc2Vy aWFsaXplcyBldmVudHMKICAgICAgKiBxdWV1ZSBmaXhlcwogICAgICAqIHdpbjMyIGZpeGVzCgpC dWdzIGZpeGVkIGluIHRoaXMgcmVsZWFzZQogICAgCiAgICAgICogMzM4MzM1IDogW3BhdGNoXSBt ZW1sZWFrIGluIGdzdC11dGlscy5jIChsZWFrIHBhZHMgZnJvbSBpdGVyYXRvcikKICAgICAgKiAz NDM1OTggOiB1bmRlZmluZWQgc3ltYm9sIGluIGNvcmVpbmRleGVycyB3aGVuIHVzaW5nIC0tZGlz YWJsZS1sb2EuLi4KICAgICAgKiAzMzY5MjkgOiBHc3RDb2xsZWN0UGFkcyBkb2VzIG5vdCBjbGVh ci9yZXNldCBzZWdtZW50IGluZm8gYWZ0ZXIgZmwuLi4KICAgICAgKiAzMzcxMDAgOiBbZmFrZXNp bmtdIGFkZCAiIHByZXJvbGwtaGFuZG9mZiAiIHNpZ25hbAogICAgICAqIDMzOTkxOCA6IEdzdFRh Z1NldHRlciBtZXJnZS1tb2RlIGRlc2NyaXB0aW9uIHVuY2xlYXIsIGFuZCBpbXBsZW1lbi4uLgog ICAgICAqIDM0MDUwMSA6IFtmaWxlc3JjXSBnaXZlIHByaW1hcnkgcmFuawogICAgICAqIDM0MTY2 MiA6IGdzdC1sYXVuY2ggcHJpbnRfdGFncygpIGZpeAogICAgICAqIDM0MjIzOCA6IEFQSTogZ3N0 X2VsZW1lbnRfc2Vla19zaW1wbGUKICAgICAgKiAzNDIzMjEgOiBHU1RfUVVFUllfUE9TSVRJT04g ZmFpbHMgaWYgR3N0QmFzZVNyYyBpbiBnZXRfcmFuZ2UgbW9kZQogICAgICAqIDM0Mjc3NyA6IHJl YnVpbGRpbmcgdGhlIHJlZ2lzdHJ5IGxlYXZlcyBhbGwgcGx1Z2lucyBpbiBtZW1vcnkKICAgICAg KiAzNDI4MjAgOiBnc3RuZXRjbGllbnRjbG9jay5jKDQ1Myk6IHNlcnZhZGRyIHVzZWQgYmVmb3Jl IHNldAogICAgICAqIDM0MzA1NyA6IGdzdC1sYXVuY2gtMC4xMCBzZWdmYXVsdHMgd2hlbiBwYXNz ZWQgZ3N0LXBsdWdpbi1wYXRoIGFuZC4uLgogICAgICAqIDM0MzM0MSA6IFtBUEldIGFkZCBHU1Rf VEFHX1BSRVZJRVdfSU1BR0UKICAgICAgKiAzNDM4MjcgOiBsZWFrIGluIGdzdF9pbmRleF9ndHlw ZV9yZXNvbHZlcgogICAgICAqIDM0MzkyOSA6IFVzZSBvZiAvLyBpbiBwdWJsaWMgaGVhZGVyCiAg ICAgICogMzQzOTg4IDogZGF0YSBwcm90b2NvbCBuZWVkcyBleHRlbmRpbmcgdG8gaGFuZGxlIGV2 ZW50cyBiZXR0ZXIKICAgICAgKiAzNDE0NzkgOiBUb28gbWFueSBwbHVnaW5zIGxvYWRlZCBldmVu IGZvciB1cC10by1kYXRlIHJlZ2lzdHJ5CiAgICAgICogMzQzMzM0IDogR3N0Q29sbGVjdFBhZHMg dGVzdHN1aXRlIGFuZCBmaXhlcwogICAgICAqIDM0MzUzOCA6IEdzdENvbGxlY3RQYWRzIGRvZXNu J3QgcmVzZXQgRU9TIGZpZWxkcyB3aGVuIHN0b3BwZWQKCkFQSSBjaGFuZ2VkIGluIHRoaXMgcmVs ZWFzZQogICAgIAoKLSBBUEkgYWRkaXRpb25zOgogICAgCiogZ3N0X2VsZW1lbnRfc2Vla19zaW1w bGUoKQoqIEdTVF9GTE9XX0NVU1RPTV9TVUNDRVNTCiogR1NUX0ZMT1dfQ1VTVE9NX0VSUk9SCiog R1NUX0ZMT1dfSVNfU1VDQ0VTUwoqIGdzdF9jb2xsZWN0X3BhZHNfc2V0X2ZsdXNoaW5nKCkKKiBH U1RfVEFHX1BSRVZJRVdfSU1BR0UKKiBnc3RfZHBfY3JjKCkKKiBHc3REUFBhY2tldGl6ZXIKKiBH c3REUFZlcnNpb24KKiBHc3RGYWtlU2luazo6cHJlcm9sbC1oYW5kb2ZmCiogR3N0RmFrZVNpbms6 OnVzZS1tbWFwCgpEb3dubG9hZAoKWW91IGNhbiBmaW5kIHNvdXJjZSByZWxlYXNlcyBvZiBnc3Ry ZWFtZXIgaW4gdGhlIGRvd25sb2FkIGRpcmVjdG9yeToKaHR0cDovL2dzdHJlYW1lci5mcmVlZGVz a3RvcC5vcmcvc3JjL2dzdHJlYW1lci8KCkdTdHJlYW1lciBIb21lcGFnZQoKTW9yZSBkZXRhaWxz IGNhbiBiZSBmb3VuZCBvbiB0aGUgcHJvamVjdCdzIHdlYnNpdGU6Cmh0dHA6Ly9nc3RyZWFtZXIu ZnJlZWRlc2t0b3Aub3JnLwoKU3VwcG9ydCBhbmQgQnVncwoKV2UgdXNlIEdOT01FJ3MgYnVnemls bGEgZm9yIGJ1ZyByZXBvcnRzIGFuZCBmZWF0dXJlIHJlcXVlc3RzOgpodHRwOi8vYnVnemlsbGEu Z25vbWUub3JnL2VudGVyX2J1Zy5jZ2k/cHJvZHVjdD1HU3RyZWFtZXIKCkRldmVsb3BlcnMKCkNW UyBpcyBob3N0ZWQgb24gY3ZzLmZyZWVkZXNrdG9wLm9yZy4KQWxsIGNvZGUgaXMgaW4gQ1ZTIGFu ZCBjYW4gYmUgY2hlY2tlZCBvdXQgZnJvbSB0aGVyZS4KSW50ZXJlc3RlZCBkZXZlbG9wZXJzIG9m IHRoZSBjb3JlIGxpYnJhcnksIHBsdWctaW5zLCBhbmQgYXBwbGljYXRpb25zIHNob3VsZApzdWJz Y3JpYmUgdG8gdGhlIGdzdHJlYW1lci1kZXZlbCBsaXN0LiBJZiB0aGVyZSBpcyBzdWZmaWNpZW50 IGludGVyZXN0IHdlCndpbGwgY3JlYXRlIG1vcmUgbGlzdHMgYXMgbmVjZXNzYXJ5LgoKICAgICAg ICAKQXBwbGljYXRpb25zCgpBcHBsaWNhdGlvbnMgcG9ydGVkIHRvIEdTdHJlYW1lciAwLjEwIGlu Y2x1ZGUgVG90ZW0sIFJoeXRobUJveCwgU291bmQtSnVpY2VyLApHbm9tZSBNZWRpYSwgRmx1bW90 aW9uLCBBbWFyb2ssIEphbWJvcmVlLCBQaXRpdmksIElzdGFuYnVsLCBBbm5vQW1wLCBFbGlzYSwg YW5kIG90aGVycy4KTGV0IHVzIGtub3cgaWYgeW91IHdhbnQgdG8gYmUgYWRkZWQgdG8gdGhpcyBs aXN0LgoKICAKQ29udHJpYnV0b3JzIHRvIHRoaXMgcmVsZWFzZQogICAgCiAgICAgICogQWxlc3Nh bmRybyBEZWNpbmEKICAgICAgKiBFZHdhcmQgSGVydmV5CiAgICAgICogSmFuIFNjaG1pZHQKICAg ICAgKiBKdWxpZW4gTW91dHRlCiAgICAgICogTHV0eiBNdWVsbGVyCiAgICAgICogTWFyayBOYXV3 ZWxhZXJ0cwogICAgICAqIE1pY2hhZWwgU21pdGgKICAgICAgKiBTZWJhc3RpZW4gTW91dHRlCiAg ICAgICogU3RlZmFuIEtvc3QKICAgICAgKiBUaG9tYXMgVmFuZGVyIFN0aWNoZWxlCiAgICAgICog VGltLVBoaWxpcHAgTcO8bGxlcgogICAgICAqIFdpbSBUYXltYW5zCiAgICAgICogWmFoZWVyIEFi YmFzIE1lcmFsaQrCoA== --127.0.0.1.500.4863.1149880260.533.2-- From thomas@apestaart.org Fri Jun 9 15:11:49 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5C75C3B00E9 for ; Fri, 9 Jun 2006 15:11:49 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15136-05 for ; Fri, 9 Jun 2006 15:11:48 -0400 (EDT) Received: from mx1.es6.egwn.net (server02.es6.egwn.net [195.10.6.12]) by menubar.gnome.org (Postfix) with ESMTP id 0A9E03B0149 for ; Fri, 9 Jun 2006 15:11:47 -0400 (EDT) Received: from mx1.fr4.egwn.net (server07.fr4.egwn.net [62.39.85.77]) by mx1.es6.egwn.net (Postfix) with ESMTP id 5C5134F822C; Fri, 9 Jun 2006 21:11:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mx1.fr4.egwn.net (spiffy mail daemon) with ESMTP id 20D9883BFD; Fri, 9 Jun 2006 21:11:35 +0200 (CEST) Received: from mx1.fr4.egwn.net ([127.0.0.1]) by localhost (server07.fr4.egwn.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23574-43; Fri, 9 Jun 2006 21:11:34 +0200 (CEST) Received: from thread.fluendo.lan (core.fluendo.com [195.10.6.237]) by mx1.fr4.egwn.net (spiffy mail daemon) with ESMTP id 33DE383BF8; Fri, 9 Jun 2006 21:11:34 +0200 (CEST) Received: from otto.amantes (thomas.fluendo.lan [192.168.1.10]) by thread.fluendo.lan (Postfix) with ESMTP id 071AFFE93; Fri, 9 Jun 2006 21:11:45 +0200 (CEST) Received: from otto.amantes (otto.amantes [127.0.0.1]) by otto.amantes (Postfix) with ESMTP id 35F55EFC0D; Fri, 9 Jun 2006 21:11:48 +0200 (CEST) Content-Type: multipart/mixed; boundary="127.0.0.1.500.5548.1149880308.216.2" MIME-Version: 1.0 To: gstreamer-devel@lists.sourceforge.net, gstreamer-announce@lists.sourceforge.net, kde-multimedia@kde.org, gnome-multimedia@gnome.org Message-Id: <20060609191148.35F55EFC0D@otto.amantes> Date: Fri, 9 Jun 2006 21:11:48 +0200 (CEST) From: thomas@apestaart.org X-Scanned: By amavis at egwn.net X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: Yes, score=2.198 tagged_above=-999 required=2 tests=[AWL=-1.575, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, MIME_BASE64_TEXT=1.885, NO_REAL_NAME=0.961, RCVD_IN_SBL=3.16, TW_EG=0.077, TW_EV=0.077, TW_FD=0.077] X-Spam-Score: 2.198 X-Spam-Level: ** X-Spam-Flag: YES Cc: Subject: RELEASE: GStreamer Base Plug-ins 0.10.8 'Moar gij zie mij nie' X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 19:11:49 -0000 --127.0.0.1.500.5548.1149880308.216.2 Content-Type: text/plain This mail announces the release of GStreamer Base Plug-ins 0.10.8 'Moar gij zie mij nie'. GStreamer Base Plug-ins is a well-groomed and well-maintained collection of GStreamer plug-ins and elements, spanning the range of possible types of elements one would want to write for GStreamer. It also contains helper libraries and base classes useful for writing elements. A wide range of video and audio decoders, encoders, and filters are included. For more information, see [http://gstreamer.freedesktop.org/modules/gst-plugins-base.html] To file bugs, go to [http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer&component=gst-plugins-base] --127.0.0.1.500.5548.1149880308.216.2 Content-Type: text/plain; name=RELEASE Content-Transfer-Encoding: base64 ClJlbGVhc2Ugbm90ZXMgZm9yIEdTdHJlYW1lciBCYXNlIFBsdWctaW5zwqAwLjEwLjggIk1vYXIg Z2lqIHppZXQgbWlqIG5pZSIKICAgICAgICAKCgpUaGUgR1N0cmVhbWVyIHRlYW0gaXMgcHJvdWQg dG8gYW5ub3VuY2UgYSBuZXcgcmVsZWFzZQppbiB0aGUgMC4xMC54IHN0YWJsZSBzZXJpZXMgb2Yg dGhlCkdTdHJlYW1lciBCYXNlIFBsdWctaW5zLgoKClRoZSAwLjEwLnggc2VyaWVzIGlzIGEgc3Rh YmxlIHNlcmllcyB0YXJnZXRlZCBhdCBlbmQgdXNlcnMuCkl0IGlzIG5vdCBBUEkgb3IgQUJJIGNv bXBhdGlibGUgd2l0aCB0aGUgc3RhYmxlIDAuOC54IHNlcmllcy4KSXQgaXMsIGhvd2V2ZXIsIHBh cmFsbGVsIGluc3RhbGxhYmxlIHdpdGggdGhlIDAuOC54IHNlcmllcy4KCgoKVGhpcyBtb2R1bGUg Y29udGFpbnMgYSBzZXQgb2YgcmVmZXJlbmNlIHBsdWdpbnMsIGJhc2UgY2xhc3NlcyBmb3Igb3Ro ZXIKcGx1Z2lucywgYW5kIGhlbHBlciBsaWJyYXJpZXMuCgpUaGlzIG1vZHVsZSBpcyBrZXB0IHVw LXRvLWRhdGUgdG9nZXRoZXIgd2l0aCB0aGUgY29yZSBkZXZlbG9wbWVudHMuICBFbGVtZW50Cndy aXRlcnMgc2hvdWxkIGxvb2sgYXQgdGhlIGVsZW1lbnRzIGluIHRoaXMgbW9kdWxlIGFzIGEgcmVm ZXJlbmNlIGZvcgp0aGVpciBkZXZlbG9wbWVudC4KClRoaXMgbW9kdWxlIGNvbnRhaW5zIGVsZW1l bnRzIGZvciwgYW1vbmcgb3RoZXJzOgoKICBkZXZpY2UgcGx1Z2luczogeCh2KWltYWdlc2luaywg YWxzYSwgdjRsc3JjLCBjZHBhcmFub2lhCiAgY29udGFpbmVyczogb2dnCiAgY29kZWNzOiB2b3Ji aXMsIHRoZW9yYQogIHRleHQ6IHRleHRvdmVybGF5LCBzdWJwYXJzZQogIHNvdXJjZXM6IGF1ZGlv dGVzdHNyYywgdmlkZW90ZXN0c3JjLCBnbm9tZXZmc3NyYwogIG5ldHdvcms6IHRjcAogIHR5cGVm aW5kCiAgYXVkaW8gcHJvY2Vzc2luZzogYXVkaW9jb252ZXJ0LCBhZGRlciwgYXVkaW9yYXRlLCBh dWRpb3NjYWxlLCB2b2x1bWUKICB2aXN1YWxpc2F0aW9uOiBsaWJ2aXN1YWwKICB2aWRlbyBwcm9j ZXNzaW5nOiBmZm1wZWdjb2xvcnNwYWNlCiAgYWdncmVnYXRlIGVsZW1lbnRzOiBkZWNvZGViaW4s IHBsYXliaW4KCgpPdGhlciBtb2R1bGVzIGNvbnRhaW5pbmcgcGx1Zy1pbnMgYXJlOgoKCmdzdC1w bHVnaW5zLWdvb2QKY29udGFpbnMgYSBzZXQgb2Ygd2VsbC1zdXBwb3J0ZWQgcGx1Zy1pbnMgdW5k ZXIgb3VyIHByZWZlcnJlZCBsaWNlbnNlCmdzdC1wbHVnaW5zLXVnbHkKY29udGFpbnMgYSBzZXQg b2Ygd2VsbC1zdXBwb3J0ZWQgcGx1Zy1pbnMsIGJ1dCBtaWdodCBwb3NlIHByb2JsZW1zIGZvcgog ICAgZGlzdHJpYnV0b3JzCmdzdC1wbHVnaW5zLWJhZApjb250YWlucyBhIHNldCBvZiBsZXNzIHN1 cHBvcnRlZCBwbHVnLWlucyB0aGF0IGhhdmVuJ3QgcGFzc2VkIHRoZQogICAgcmlnb3JvdXMgcXVh bGl0eSB0ZXN0aW5nIHdlIGV4cGVjdAoKCgogIApGZWF0dXJlcyBvZiB0aGlzIHJlbGVhc2UKICAg IAogICAgICAqIFBhcmFsbGVsIGluc3RhbGxhYmlsaXR5IHdpdGggMC44Lnggc2VyaWVzCiAgICAg ICogVGhyZWFkc2FmZSBkZXNpZ24gYW5kIEFQSQogICAgICAqIGFsc2FzaW5rIHByb2JpbmcgZml4 ZXMKICAgICAgKiB4dmltYWdlc2luayBlcnJvciByZXBvcnRpbmcgZml4ZXMKICAgICAgKiBzdWJ0 aXRsZSBmaXhlcwogICAgICAqIGFkZGVyIGZpeGVzCiAgICAgICogdm9yYmlzIG11bHRpY2hhbm5l bCBmaXhlcwogICAgICAqIG11bHRpZmRzaW5rIHN0cmVhbWhlYWRlciBmaXhlcwoKQnVncyBmaXhl ZCBpbiB0aGlzIHJlbGVhc2UKICAgIAogICAgICAqIDE2OTkzNiA6IFtzdWJwYXJzZV0gc3VwcG9y dCBmb3IgU0FNSSBzdWJ0aXRsZXMKICAgICAgKiAzMTUzMTIgOiBHc3RyZWFtZXIgWHYgdXNlcyBS R0IgaW5zdGVhZCBvZiBZVVYuCiAgICAgICogMzM0MDAyIDogdmlkZW80bGludXggc2hvdWxkbid0 IGRlcGVuZCBvbiBYIGluIGNvbmZpZ3VyZSBzY3JpcHQKICAgICAgKiAzMzY4ODEgOiBbbGlidmlz dWFsXSBhZGRpdGlvbmFsIHN1cHBvcnQgZm9yIGxpYnZpc3VhbC0wLjQKICAgICAgKiAzMzc1NDQg OiBbeHZpbWFnZXNpbmtdIEludGVybmFsIEVycm9yIHdoZW4gaW1hZ2UgaXMgdG9vIGxhcmdlCiAg ICAgICogMzM5NTIwIDogW3N1YnBhcnNlXSBhZGQgIiBlbmNvZGluZyAiIHByb3BlcnR5CiAgICAg ICogMzQwOTA5IDogW2Fsc2FzaW5rXSBjYW4ndCBlbmFibGUgc3BkaWYgb3V0cHV0CiAgICAgICog MzQxNTQyIDogc29tZSB1c2VycyBoYXZlIGFuIGFzc2VydGlvbiBmYWlsZWQ6IChHU1RfVklERU9f U0lOS19XSURULi4uCiAgICAgICogMzQxNTYyIDogYXVkaW9jb252ZXJ0IGRvZXNuJ3QgbGlzdCBm b3JtYXRzIGluIG9yZGVyIG9mIHByZWZlcmVuY2UKICAgICAgKiAzNDE2OTYgOiBhdWRpb2NvbnZl cnQgY3Jhc2hlcyBpZiBjb252ZXJ0aW5nIGZyb20gYSBmb3JtYXQgd2l0aCBubyAuLi4KICAgICAg KiAzNDE3MTkgOiBiaXNlY3Rpb24gYWxnb3JpdGhtIGluIG9nZyBkb2Vzbid0IGJpc2VjdCBpbiBz b21lIGNhc2VzCiAgICAgICogMzQxNzMyIDogW2Fsc2FzaW5rXSBkb2Vzbid0IHF1ZXJ5IHN1cHBv cnRlZCBzYW1wbGUgcmF0ZXMKICAgICAgKiAzNDE4NzMgOiBbYWxzYXNpbmtdIG1pbm9yIG1lbW9y eSBsZWFrLCB1c2VzIHVucHJvdGVjdGVkIHN0YXRpYyB2YXIuLi4KICAgICAgKiAzNDIxNDMgOiBb c3VicGFyc2VdIHNhbWkgcGFyc2VyIG5lZWRzIHRvIGVzY2FwZSBjaGFyYWN0ZXJzCiAgICAgICog MzQyMTgxIDogW2Fsc2FdIGFkZCBwcm9wZXJ0eSBwcm9iZSBpbnRlcmZhY2UgdG8gYWxzYXNpbmsg YW5kIGFsc2FzcmMKICAgICAgKiAzNDIyNjggOiBbcGxheWJpbl0gYWRkICdzdWJ0aXRsZS1lbmNv ZGluZycgcHJvcGVydHkKICAgICAgKiAzNDIzNDUgOiBbcmlmZl0gRWxlcGhhbnQncyBEcmVhbSBB VkkgZG9lcyBub3QgcGxheSwgSlVOSyBjaHVuayBiZWYuLi4KICAgICAgKiAzNDI1NjYgOiBCdWls ZGluZyB3aXRob3V0IEdUSysgZmFpbHMKICAgICAgKiAzNDMzOTcgOiBILjI2NC9BQUMgbW92aWUg ZGVhZGxvY2tzIHdpdGggdG90ZW0gaW4gZ3N0cmVhbWVyIGNvZGUsIHAuLi4KICAgICAgKiAzMzk5 MzUgOiBbYWRkZXJdIGRlYWQtbG9ja3Mgd2hlbiBhZGRpbmcgc2luayBwYWRzIGluIFBBVVNFRCBz dGF0ZQoKRG93bmxvYWQKCllvdSBjYW4gZmluZCBzb3VyY2UgcmVsZWFzZXMgb2YgZ3N0LXBsdWdp bnMtYmFzZSBpbiB0aGUgZG93bmxvYWQgZGlyZWN0b3J5OgpodHRwOi8vZ3N0cmVhbWVyLmZyZWVk ZXNrdG9wLm9yZy9zcmMvZ3N0LXBsdWdpbnMtYmFzZS8KCkdTdHJlYW1lciBIb21lcGFnZQoKTW9y ZSBkZXRhaWxzIGNhbiBiZSBmb3VuZCBvbiB0aGUgcHJvamVjdCdzIHdlYnNpdGU6Cmh0dHA6Ly9n c3RyZWFtZXIuZnJlZWRlc2t0b3Aub3JnLwoKU3VwcG9ydCBhbmQgQnVncwoKV2UgdXNlIEdOT01F J3MgYnVnemlsbGEgZm9yIGJ1ZyByZXBvcnRzIGFuZCBmZWF0dXJlIHJlcXVlc3RzOgpodHRwOi8v YnVnemlsbGEuZ25vbWUub3JnL2VudGVyX2J1Zy5jZ2k/cHJvZHVjdD1HU3RyZWFtZXIKCkRldmVs b3BlcnMKCkNWUyBpcyBob3N0ZWQgb24gY3ZzLmZyZWVkZXNrdG9wLm9yZy4KQWxsIGNvZGUgaXMg aW4gQ1ZTIGFuZCBjYW4gYmUgY2hlY2tlZCBvdXQgZnJvbSB0aGVyZS4KSW50ZXJlc3RlZCBkZXZl bG9wZXJzIG9mIHRoZSBjb3JlIGxpYnJhcnksIHBsdWctaW5zLCBhbmQgYXBwbGljYXRpb25zIHNo b3VsZApzdWJzY3JpYmUgdG8gdGhlIGdzdHJlYW1lci1kZXZlbCBsaXN0LiBJZiB0aGVyZSBpcyBz dWZmaWNpZW50IGludGVyZXN0IHdlCndpbGwgY3JlYXRlIG1vcmUgbGlzdHMgYXMgbmVjZXNzYXJ5 LgoKICAgICAgICAKQXBwbGljYXRpb25zCiAgCkNvbnRyaWJ1dG9ycyB0byB0aGlzIHJlbGVhc2UK ICAgIAogICAgICAqIEVkd2FyZCBIZXJ2ZXkKICAgICAgKiBKYW4gU2NobWlkdAogICAgICAqIEp1 bGllbiBNb3V0dGUKICAgICAgKiBNYXJ0aW4gU3p1bGVja2kKICAgICAgKiBNaWNoYWVsIFNtaXRo CiAgICAgICogUGV0ZXIgS2plbGxlcnN0ZWR0CiAgICAgICogU2ViYXN0aWVuIE1vdXR0ZQogICAg ICAqIFN0ZWZhbiBLb3N0CiAgICAgICogVGhvbWFzIFZhbmRlciBTdGljaGVsZQogICAgICAqIFRp bS1QaGlsaXBwIE3DvGxsZXIKICAgICAgKiBXaW0gVGF5bWFucwogICAgICAqIFlvdW5nLUhvIENo YQogICAgICAqIFphaGVlciBBYmJhcyBNZXJhbGkKwqA= --127.0.0.1.500.5548.1149880308.216.2-- From thomas@apestaart.org Sat Jun 10 13:20:04 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 77ABD3B0280 for ; Sat, 10 Jun 2006 13:20:04 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16793-02 for ; Sat, 10 Jun 2006 13:20:03 -0400 (EDT) Received: from core.fluendo.com (core.fluendo.com [195.10.6.237]) by menubar.gnome.org (Postfix) with ESMTP id E5DCC3B01B8 for ; Sat, 10 Jun 2006 13:20:02 -0400 (EDT) Received: from onzenbak.amantes (70.Red-81-38-184.dynamicIP.rima-tde.net [81.38.184.70]) by core.fluendo.com (Postfix) with ESMTP id 205F71DC; Sat, 10 Jun 2006 19:20:01 +0200 (CEST) Received: from otto.amantes (otto.amantes [192.168.1.10]) by onzenbak.amantes (Postfix) with ESMTP id 4680720476; Sat, 10 Jun 2006 19:19:58 +0200 (CEST) Received: from otto.amantes (otto.amantes [127.0.0.1]) by otto.amantes (Postfix) with ESMTP id 3B641EFC0D; Sat, 10 Jun 2006 19:20:01 +0200 (CEST) Content-Type: multipart/mixed; boundary="127.0.0.1.500.6078.1149960001.170.2" MIME-Version: 1.0 To: gstreamer-devel@lists.sourceforge.net, gstreamer-announce@lists.sourceforge.net, kde-multimedia@kde.org, gnome-multimedia@gnome.org Message-Id: <20060610172001.3B641EFC0D@otto.amantes> Date: Sat, 10 Jun 2006 19:20:01 +0200 (CEST) From: thomas@apestaart.org X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-0.991 tagged_above=-999 required=2 tests=[AWL=-1.373, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, MIME_BASE64_TEXT=1.885, NO_REAL_NAME=0.961] X-Spam-Score: -0.991 X-Spam-Level: Cc: Subject: RELEASE: GStreamer 0.10.8 'Soepeke, ik zie ou nog altijd nie' X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 17:20:04 -0000 --127.0.0.1.500.6078.1149960001.170.2 Content-Type: text/plain This mail announces the release of GStreamer 0.10.8 'Soepeke, ik zie ou nog altijd nie'. GStreamer is a streaming media framework that allows the construction of graphs of elements which operate on media data. Applications using this library can do anything from real-time sound processing over playing video to capturing audio, video, and even other types of media data. Its architecture allows for adding new data types or processing capabilities simply by installing new plug-ins. GStreamer is the core module, containing libraries, headers, the basic object hierarchy, and a set of media-agnostic core elements. For more information, see [http://gstreamer.freedesktop.org/modules/gstreamer.html] To file bugs, go to [http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer&component=gstreamer+%28core%29] --127.0.0.1.500.6078.1149960001.170.2 Content-Type: text/plain; name=RELEASE Content-Transfer-Encoding: base64 ClJlbGVhc2Ugbm90ZXMgZm9yIEdTdHJlYW1lcsKgMC4xMC44ICJTb2VwZWtlLCBpayB6aWUgb3Ug bm9nIGFsdGlqZCBuaWUiCiAgICAgICAgCgoKVGhlIEdTdHJlYW1lciB0ZWFtIGlzIHByb3VkIHRv IGFubm91bmNlIGEgbmV3IHJlbGVhc2UKaW4gdGhlIDAuMTAueCBzdGFibGUgc2VyaWVzIG9mIHRo ZQpjb3JlIG9mIHRoZSBHU3RyZWFtZXIgc3RyZWFtaW5nIG1lZGlhIGZyYW1ld29yay4KCgpUaGUg MC4xMC54IHNlcmllcyBpcyBhIHN0YWJsZSBzZXJpZXMgdGFyZ2V0ZWQgYXQgZW5kIHVzZXJzLgpJ dCBpcyBub3QgQVBJIG9yIEFCSSBjb21wYXRpYmxlIHdpdGggdGhlIHN0YWJsZSAwLjgueCBzZXJp ZXMuCkl0IGlzLCBob3dldmVyLCBwYXJhbGxlbCBpbnN0YWxsYWJsZSB3aXRoIHRoZSAwLjgueCBz ZXJpZXMuCgoKVGhlIDAuMTAueCBzZXJpZXMgaGFzIGJlZW4gcmV3b3JrZWQgZm9yIHRocmVhZHNh ZmV0eS4gIEl0IGFsc28gZmVhdHVyZXMKdmFyaW91cyBmZWF0dXJlIGFkZGl0aW9ucyBhbmQgZW5j aGFuY2VtZW50cy4KCgpUaGlzIG1vZHVsZSwgZ3N0cmVhbWVyLCBvbmx5IGNvbnRhaW5zIGNvcmUg ZnVuY3Rpb25hbGl0eS4KRm9yIGFjdHVhbCBtZWRpYSBwbGF5YmFjaywgeW91IHdpbGwgbmVlZCBv dGhlciBtb2R1bGVzLgoKZ3N0LXBsdWdpbnMtYmFzZQpjb250YWlucyBhIGJhc2ljIHNldCBvZiB3 ZWxsLXN1cHBvcnRlZCBwbHVnLWlucwpnc3QtcGx1Z2lucy1nb29kCmNvbnRhaW5zIGEgc2V0IG9m IHdlbGwtc3VwcG9ydGVkIHBsdWctaW5zIHVuZGVyIG91ciBwcmVmZXJyZWQgbGljZW5zZQpnc3Qt cGx1Z2lucy11Z2x5CmNvbnRhaW5zIGEgc2V0IG9mIHdlbGwtc3VwcG9ydGVkIHBsdWctaW5zLCBi dXQgbWlnaHQgcG9zZSBwcm9ibGVtcyBmb3IKICAgIGRpc3RyaWJ1dG9ycwpnc3QtcGx1Z2lucy1i YWQKY29udGFpbnMgYSBzZXQgb2YgbGVzcyBzdXBwb3J0ZWQgcGx1Zy1pbnMgdGhhdCBoYXZlbid0 IHBhc3NlZCB0aGUKICAgIHJpZ29yb3VzIHF1YWxpdHkgdGVzdGluZyB3ZSBleHBlY3QKCgoKICAK RmVhdHVyZXMgb2YgdGhpcyByZWxlYXNlCiAgICAKICAgICAgKiBQYXJhbGxlbCBpbnN0YWxsYWJp bGl0eSB3aXRoIDAuOC54IHNlcmllcwogICAgICAqIFRocmVhZHNhZmUgZGVzaWduIGFuZCBBUEkK ICAgICAgKiBJbXBvcnRhbnQgZml4IGZvciByZWdpc3RyeSB1cGRhdGUgY2F1c2luZyBhcHBsZXRz IG5vdCB0byBsb2FkCgpCdWdzIGZpeGVkIGluIHRoaXMgcmVsZWFzZQogICAgCiAgICAgICogMzQ0 NDc0IDogR25vbWUgTWl4ZXIgQXBwbGV0IGRvZXNuJ3Qgd2FudCB0byBsb2FkCgpEb3dubG9hZAoK WW91IGNhbiBmaW5kIHNvdXJjZSByZWxlYXNlcyBvZiBnc3RyZWFtZXIgaW4gdGhlIGRvd25sb2Fk IGRpcmVjdG9yeToKaHR0cDovL2dzdHJlYW1lci5mcmVlZGVza3RvcC5vcmcvc3JjL2dzdHJlYW1l ci8KCkdTdHJlYW1lciBIb21lcGFnZQoKTW9yZSBkZXRhaWxzIGNhbiBiZSBmb3VuZCBvbiB0aGUg cHJvamVjdCdzIHdlYnNpdGU6Cmh0dHA6Ly9nc3RyZWFtZXIuZnJlZWRlc2t0b3Aub3JnLwoKU3Vw cG9ydCBhbmQgQnVncwoKV2UgdXNlIEdOT01FJ3MgYnVnemlsbGEgZm9yIGJ1ZyByZXBvcnRzIGFu ZCBmZWF0dXJlIHJlcXVlc3RzOgpodHRwOi8vYnVnemlsbGEuZ25vbWUub3JnL2VudGVyX2J1Zy5j Z2k/cHJvZHVjdD1HU3RyZWFtZXIKCkRldmVsb3BlcnMKCkNWUyBpcyBob3N0ZWQgb24gY3ZzLmZy ZWVkZXNrdG9wLm9yZy4KQWxsIGNvZGUgaXMgaW4gQ1ZTIGFuZCBjYW4gYmUgY2hlY2tlZCBvdXQg ZnJvbSB0aGVyZS4KSW50ZXJlc3RlZCBkZXZlbG9wZXJzIG9mIHRoZSBjb3JlIGxpYnJhcnksIHBs dWctaW5zLCBhbmQgYXBwbGljYXRpb25zIHNob3VsZApzdWJzY3JpYmUgdG8gdGhlIGdzdHJlYW1l ci1kZXZlbCBsaXN0LiBJZiB0aGVyZSBpcyBzdWZmaWNpZW50IGludGVyZXN0IHdlCndpbGwgY3Jl YXRlIG1vcmUgbGlzdHMgYXMgbmVjZXNzYXJ5LgoKICAgICAgICAKQXBwbGljYXRpb25zCgpBcHBs aWNhdGlvbnMgcG9ydGVkIHRvIEdTdHJlYW1lciAwLjEwIGluY2x1ZGUgVG90ZW0sIFJoeXRobUJv eCwgU291bmQtSnVpY2VyLApHbm9tZSBNZWRpYSwgRmx1bW90aW9uLCBBbWFyb2ssIEphbWJvcmVl LCBQaXRpdmksIElzdGFuYnVsLCBBbm5vQW1wLCBFbGlzYSwgYW5kIG90aGVycy4KTGV0IHVzIGtu b3cgaWYgeW91IHdhbnQgdG8gYmUgYWRkZWQgdG8gdGhpcyBsaXN0LgoKICAKQ29udHJpYnV0b3Jz IHRvIHRoaXMgcmVsZWFzZQogICAgCiAgICAgICogRWR3YXJkIEhlcnZleQogICAgICAqIFRob21h cyBWYW5kZXIgU3RpY2hlbGUKICAgICAgKiBUaW0tUGhpbGlwcCBNw7xsbGVyCsKg --127.0.0.1.500.6078.1149960001.170.2-- From sjoeboo@sjoeboo.com Wed Jun 14 10:50:35 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CE3003B037F; Wed, 14 Jun 2006 10:50:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08478-04; Wed, 14 Jun 2006 10:50:34 -0400 (EDT) Received: from server.sjoeboo.com (unknown [64.79.192.114]) by menubar.gnome.org (Postfix) with ESMTP id D38F13B02C8; Wed, 14 Jun 2006 10:50:33 -0400 (EDT) Received: by server.sjoeboo.com (Postfix, from userid 33) id 6D37418C4F7F; Wed, 14 Jun 2006 07:50:15 -0700 (PDT) To: gnome-multimedia@gnome.org, rhythmbox-devel@gnome.org Subject: totem and goom information... MIME-Version: 1.0 Date: Wed, 14 Jun 2006 7:50:15 -0700 From: sjoeboo Organization: sjoeboo.com Message-ID: <5135b2d86e5568cedc7e8138809a3b9f@localhost> X-Sender: sjoeboo@sjoeboo.com User-Agent: RoundCube Webmail/0.1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.599 tagged_above=-999 required=2 tests=[AWL=0.000, BAYES_00=-2.599] X-Spam-Score: -2.599 X-Spam-Level: X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: sjoeboo@sjoeboo.com List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 14:50:36 -0000 Good "morning" everyone, So, my (and what should be everyones) favorite music player for gnome, rhythmbox, has been on a steady march of advancement for the past few months, with a whole slew of new features comming about. One thing I though of recently is visualizations, and how ncie it would be to have at least one, possibly as a plugin. I know totem uses GOOM to do this, and was wondering what I might have to do in terms of gstreamer etc to have rhythmbox use it as well. I was looking around on the Totem site for a mailing list etc, but couldn't find anything. Does anyone know where I might find more info for something like this? Thanks, and keep up the great work. -- Matthew Nicholson sjoeboo@sjoeboo.com sjoeboo.com From internalerror@gmail.com Thu Jun 22 05:25:58 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id E43203B02D2 for ; Thu, 22 Jun 2006 05:25:57 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12537-03 for ; Thu, 22 Jun 2006 05:25:56 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.201]) by menubar.gnome.org (Postfix) with ESMTP id D48DD3B0179 for ; Thu, 22 Jun 2006 05:25:55 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so314263wxc for ; Thu, 22 Jun 2006 02:25:55 -0700 (PDT) Received: by 10.70.91.12 with SMTP id o12mr2775555wxb; Thu, 22 Jun 2006 02:25:55 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 02:25:55 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 11:25:55 +0200 From: "Milosz Derezynski" To: xdg@lists.freedesktop.org Subject: MLQ (Media Library Query) file format and mime type proposal MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3009_31371308.1150968355005" X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.255 tagged_above=-999 required=2 tests=[AWL=0.344, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.255 X-Spam-Level: Cc: gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 09:25:58 -0000 ------=_Part_3009_31371308.1150968355005 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I'm one of the main authors of BMP 2 (still being worked on), and along the way of reworking our library, i came across the idea of encoding library queries as URIs, which may look like this: "query:///?artist=Air&album=Moon%20Safari" BMP 2 has a plugin archicture which is a small VFS on it's own, and we treat certain things as "containers" (i.e. they "contain" URIs, like PLS playlists, XSPF, M3U, etc). Now i thought it might be not a bad idea to create a playlist format with these query URLs, and i've called it "MLQ" for media library query. In theory, it's not even application specific. The keys (identifiers), like artist, album, etc, are all based on GStreamer tag identifiers. (They could be maybe adapted to http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but it seems insufficient and doesn't specify certain items, like musicbrainz metadata, which GST does). So i've called this file format "MLQ", with the extension .mlq, created a mime package file for it: Media Library Query List Adding a file of this type to BMPx, or just a plain query:/// URI itself causes a library query and appending of the relevant items to the tracklist (BMP is currently mostly based on the concept of a mutable playlist to which items can be added from various sources, unlike e.g. RB which has mostly immutable "Playlists", but allows for custom queues). Another example is: query:///?artist=Air&album=Moon%20Safari&title=La%20Femme%20d'Argent query:///?artist=Air&album=Moon%20Safari&title=Sexy%20Boy query:///?artist=Air&album=Moon%20Safari&title=All%20I%20Need query:///?artist=Air&album=Moon%20Safari&title=Kelly,%20Watch%20The%20Stars! query:///?artist=Air&album=Moon%20Safari&title=Talisman query:///?artist=Air&album=Moon%20Safari&title=Remember query:///?artist=Air&album=Moon%20Safari&title=You%20Make%20It%20Easy query:///?artist=Air&album=Moon%20Safari&title=Ce%20Matin%20La query:///?artist=Air&album=Moon%20Safari&title=New%20Star%20In%20The%20Sky query:///?artist=Air&album=Moon%20Safari&title=Le%20Voyage%20De%20Penelope Or it might just be: query:///?genre=Jazz Since this is very common, and having the discussions about a common music database in mind, this seems like a useful proposal, since it is not player specific. This ships currently with BMP 2/BMPx SVN, and while i will ship this with the 0.20 release (end-July) anyway, what does everyone think of this in a broader context (common music database, etc)? -- Milosz ------=_Part_3009_31371308.1150968355005 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

I'm one of the main authors of BMP 2 (still being worked on), and along the way of reworking our library, i came across the idea of encoding library queries as URIs, which may look like this:

"query:///?artist=Air&album=Moon%20Safari"

BMP 2 has a plugin archicture which is a small VFS on it's own, and we treat certain things as "containers" (i.e. they "contain" URIs, like PLS playlists, XSPF, M3U, etc).
Now i thought it might be not a bad idea to create a playlist format with these query URLs, and i've called it "MLQ" for media library query. In theory, it's not even
application specific. The keys (identifiers), like artist, album, etc, are all based on GStreamer tag identifiers. (They could be maybe adapted to http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but it seems insufficient and doesn't specify certain items, like musicbrainz metadata, which GST does).

So i've called this file format "MLQ", with the extension .mlq, created a mime package file for it:

<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info ">
  <mime-type type="application/x-media-library-query">
         <comment xml:lang="en">Media Library Query List</comment>
         <magic priority="50">
            <match value="query:///" type="string" offset="0"/>
         </magic>
         <glob pattern="*.mlq"/>
  </mime-type>
</mime-info>

Adding a file of this type to BMPx, or just a plain query:/// URI itself causes a library query and appending of the relevant items to the tracklist (BMP is currently mostly based on the concept of a mutable playlist to which items can be added from various sources, unlike e.g. RB which has mostly immutable "Playlists", but allows for custom queues).

Another example is:

query:///?artist=Air&album=Moon%20Safari&title=La%20Femme%20d'Argent
query:///?artist=Air&album=Moon%20Safari&title=Sexy%20Boy
query:///?artist=Air&album=Moon%20Safari&title=All%20I%20Need
query:///?artist=Air&album=Moon%20Safari&title=Kelly,%20Watch%20The%20Stars!
query:///?artist=Air&album=Moon%20Safari&title=Talisman
query:///?artist=Air&album=Moon%20Safari&title=Remember
query:///?artist=Air&album=Moon%20Safari&title=You%20Make%20It%20Easy
query:///?artist=Air&album=Moon%20Safari&title=Ce%20Matin%20La
query:///?artist=Air&album=Moon%20Safari&title=New%20Star%20In%20The%20Sky
query:///?artist=Air&album=Moon%20Safari&title=Le%20Voyage%20De%20Penelope

Or it might just be:

query:///?genre=Jazz

Since this is very common, and having the discussions about a common music database in mind, this seems like a useful proposal, since it is not player specific.
This ships currently with BMP 2/BMPx SVN, and while i will ship this with the 0.20 release (end-July) anyway, what does everyone think of this in a broader context (common music database, etc)?

-- Milosz
------=_Part_3009_31371308.1150968355005-- From internalerror@gmail.com Thu Jun 22 05:32:59 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 7208D3B00DE for ; Thu, 22 Jun 2006 05:32:59 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12916-03 for ; Thu, 22 Jun 2006 05:32:58 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.207]) by menubar.gnome.org (Postfix) with ESMTP id 6F0643B0373 for ; Thu, 22 Jun 2006 05:32:58 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so314918wxc for ; Thu, 22 Jun 2006 02:32:57 -0700 (PDT) Received: by 10.70.103.9 with SMTP id a9mr2787413wxc; Thu, 22 Jun 2006 02:32:57 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 02:32:57 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 11:32:57 +0200 From: "Milosz Derezynski" To: xdg@lists.freedesktop.org Subject: MLQ: Followup MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3081_18949182.1150968777845" X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.875 tagged_above=-999 required=2 tests=[AWL=-0.071, BAYES_00=-2.599, HTML_00_10=0.795, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -1.875 X-Spam-Level: Cc: gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 09:32:59 -0000 ------=_Part_3081_18949182.1150968777845 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline What i forgot to mention: One benefit of MLQs over 'regular' playlists at least with BMP 2 is that i've introduced a concept of keeping track of tracks across mount point changes which basically works like this: BMP stores for each file the HAL volume and device UDI, and the VRP (Volume Relative Path), that is, the path stripped off the mount point root. Whenever it seems that a file is missing, it checks whether the volume UDI of this file is still present on the system, and if so, gathers the new mount point, and adjusts the URI of this file in the library (this obiviously only works with tracks from the library only anyway since only there we can reliably store the HAL volume/device UDI and the VRP). This means practically: - Mount your music to /music - Start BMP - Add music from /music to the library - Quit BMP - Remount /music to e.g. /old_music - Start BMP - Use the library as before. Whenever BMP finds a file is missing, it will correct the URI on-the-fly as long as the volume is mounted at all on the system (and has an UDI to begin with; problem cases here are network volumes, NFS and SMBFS) So the benefit of an MLQ is that unlike a static playlist, you can be rather sure that no matter where you really move the music, BMP will always be able to find it. Downsides/doesn't-works: - There is no volume UDI available - You make a regular 'move' (mv), and not just a remount In the context of having a common music database, or something like Tracker, this seems very useful (Jamie: Hence my urge to add HAL volume/device UDI per file to the metadata). -- Milosz ------=_Part_3081_18949182.1150968777845 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline What i forgot to mention:

One benefit of MLQs over 'regular' playlists at least with BMP 2 is that i've introduced a concept of keeping track of tracks across mount point changes which basically works like this:

BMP stores for each file the HAL volume and device UDI, and the VRP (Volume Relative Path), that is, the path stripped off the mount point root.
Whenever it seems that a file is missing, it checks whether the volume UDI of this file is still present on the system, and if so, gathers the new mount point, and adjusts the URI of this
file in the library (this obiviously only works with tracks from the library only anyway since only there we can reliably store the HAL volume/device UDI and the VRP).

This means practically:

- Mount your music to /music
- Start BMP
- Add music from /music to the library
- Quit BMP
- Remount /music to e.g. /old_music
- Start BMP
- Use the library as before. Whenever BMP finds a file is missing, it will correct the URI on-the-fly as long as the volume is mounted at all on the system (and has an UDI to begin with; problem cases here are network volumes, NFS and SMBFS)

So the benefit of an MLQ is that unlike a static playlist, you can be rather sure that no matter where you really move the music, BMP will always be able to find it.

Downsides/doesn't-works:

- There is no volume UDI available
- You make a regular 'move' (mv), and not just a remount

In the context of having a common music database, or something like Tracker, this seems very useful (Jamie: Hence my urge to add HAL volume/device UDI per file to the metadata).

-- Milosz
------=_Part_3081_18949182.1150968777845-- From internalerror@gmail.com Thu Jun 22 06:23:10 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 61AE53B0403 for ; Thu, 22 Jun 2006 06:23:10 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15637-08 for ; Thu, 22 Jun 2006 06:23:09 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.195]) by menubar.gnome.org (Postfix) with ESMTP id 7534E3B045B for ; Thu, 22 Jun 2006 06:23:08 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so321629wxc for ; Thu, 22 Jun 2006 03:23:07 -0700 (PDT) Received: by 10.70.14.14 with SMTP id 14mr2842980wxn; Thu, 22 Jun 2006 03:23:07 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 03:23:07 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 12:23:07 +0200 From: "Milosz Derezynski" To: "Josef Spillner" Subject: Re: MLQ (Media Library Query) file format and mime type proposal In-Reply-To: <200606221139.41836.spillner@kde.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3405_33193106.1150971787566" References: <200606221139.41836.spillner@kde.org> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.443 tagged_above=-999 required=2 tests=[AWL=-0.496, BAYES_00=-2.599, HTML_10_20=1.351, HTML_MESSAGE=0.001, MIME_BASE64_NO_NAME=0.224, SPF_PASS=-0.001, TW_XD=0.077] X-Spam-Score: -1.443 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 10:23:10 -0000 ------=_Part_3405_33193106.1150971787566 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline WWVhaCB3ZWxsIGp1c3QgdG8gc3RheSB3aXRoaW4gdGhlIGZvY3VzIG9mIGEgbXVzaWMgbGlicmFy eSwgdGhlcmUgaGFzIHRvIGJlCnNvbWV0aGluZwp0aGF0IGRvZXMgdGhlIHJlc29sdXRpb24uCgpP TkUgcG9zc2libGUgb3B0aW9uIHdvdWxkIGJlIHRvIHNwZWNpZnkgYSBELUJVUyBpbnRlcmZhY2Ug bmFtZSwgYW5kIGEgaGF2ZQpzaW1wbGUgbGF1bmNoZXIuCgpBbGwgYXBwcyBzdXBwb3J0aW5nIE1M UXMgd291bGQgaGF2ZSB0byBoYXZlIGEgbWluaW1hbCBjb21tb24gc3Vic2V0Cm9mIEQtQlVTIGlu dGVyZmFjZXJ5IHRvIGFsbG93IHRoaXMga2luZCBvZiBxdWVyeSB0byBiZSBzZW50IHRvIHRoZW0g aW4gc29tZQp3YXkKKHNvbWV0aGluZyBsaWtlIGFuIEFkZFVyaSBjYWxsIG1pZ2h0IGp1c3Qgc3Vm ZmljZSksIHRoZW4gdGhlIGxhdW5jaGVyIHdvdWxkCmJhc2ljYWxseQpjb25zaXN0IG9mIHN0YXJ0 aW5nIHRoZSByZWxldmFudCBhcGxsaWNhdGlvbiB0cm91Z2ggRC1CVVMgYWN0aXZhdGlvbiwgYW5k CnRoZW4gcGFzcyBvbgp0aGUgYWN0dWFsIHF1ZXJ5IHRvIGl0LgoKKFdlIGhhdmUgYSBkdW1teSBt ZXRob2QgIlN0YXJ0dXAiIG9uIG91ciBELUJVUyBpZmFjZSB3aGljaApkb2VzIG5vdGhpbmcsIGJ1 dCBjYXVzZXMgRC1CVVMgdG8gc3RhcnQgdXAgQk1QLiBUaGUgcmVhc29uaW5nIGlzIHRoYXQgd2UK aGF2ZSBvbmUgbWFpbgpiaW5hcnkgYW5kIG9uZSAicmVtb3RlIiBiaW5hcnksIHdoaWNoIGlzIHRo b3VnaCBzZXQgc28gdGhhdCBpdCBpcyBwZXJjZWl2ZWQKYXMgYmVpbmcgdGhlIG1haW4KYmluYXJ5 LCBhcyBpbiBpdCdzIGluIC91c3IvYmluLCB3aGVyZWFzIHRoZSAtYmluIChtYWluKSBiaW5hcnkg aXMgaW4KL3Vzci9saWJleGVjLiBUaGUgcmVhc29uCmlzIHNvIHRoYXQgd2UgaGF2ZSBhIGxpZ2h0 d2VpZ2h0IHJlbW90ZSBhcHAgdGhhdCBjYW4gcGVyZm9ybSBhY3Rpb25zIG9uIHRoZQptYWluIGJp bmFyeQphbmQgZG9uJ3QgaGF2ZSB0byBoYXZlIHRoZSBtYWluIGFwcCBiZSBjYXBhYmxlIG9mIGJl aW5nIGEgY2xpZW50IHRvIGl0J3Mgb3duCnNlcnZlcgphbmQgaGF2ZSBhbGwgdGhlIHN0YXJ0dXAg c2hpenpsZSBnb2luZyBqdXN0IHRvIHBlcmZvcm0gYSBjZXJ0YWluIHJlbW90ZQpvcGVyYXRpb24p LgoKRm9yIGV4YW1wbGUgeW91J2QgaGF2ZToKcXVlcnk6Ly9vcmcuYmVlcG1lZGlhcGxheWVyLmJt cC8/YXJ0aXN0PUFpciZBbGJ1bT1Nb29uJTIwU2FmYXJpCgpUaGUgc2NyaXB0LCBvciBiZSBpdCBh IGJpbmFyeSwgbGV0J3MgY2FsbCBpdCAicGxheS1tbHEiLCB3b3VsZCBsYXVuY2ggdGhlCnBsYXll ciB3aXRoIHRoZSBzcGVjaWZpZWQgaW50ZXJmYWNlIGFuZCBwYXNzIGl0IHRoZSBhY3R1YWwgcXVl cnkuCgpfQW5vdGhlcl8gcG9zc2liaWxpdHksIGFsdGhvdWdoIHRoaXMgd291bGQgcmVxdWlyZSBw bGF5ZXJzIHRoYXQgY2FuIHdvcmsKd2l0aAptdXRhYmxlIHBsYXlsaXN0cyBsaWtlIEJNUCwgaXMg dGhhdCBpdCB3b3VsZCBwYXNzIHRoZSBxdWVyeSBvbiB0byBlLmcuCnNvbWV0aGluZwpsaWtlIFRy YWNrZXIgb3Igc29tZSBvdGhlciBpbmRleGVyLCB3aGljaCB3b3VsZCB0aGVuIGV4ZWN1dGUgdGhl IHF1ZXJ5IGFuZApfSVRfIHdvdWxkIHRoZW4gc3RhcnQgdGhlIHBsYXllciBzcGVjaWZpZWQgYnkg dGhlIGludGVyZmFjZSBhbmQgcGFzcyBpdAphbG9uZyB0aGUKcmVzdWx0aW5nIFVSSXMuCgotLSBN aWxvc3oKCk9uIDYvMjIvMDYsIEpvc2VmIFNwaWxsbmVyIDxzcGlsbG5lckBrZGUub3JnPiB3cm90 ZToKPgo+IEFsbGUgMTE6MjUsIGdpb3ZlZMOsLCAyMi4gZ2l1Z25vIDIwMDYsIE1pbG9zeiBEZXJl enluc2tpIGhhIHNjcml0dG86Cj4gPiBTaW5jZSB0aGlzIGlzIHZlcnkgY29tbW9uLCBhbmQgaGF2 aW5nIHRoZSBkaXNjdXNzaW9ucyBhYm91dCBhIGNvbW1vbgo+IG11c2ljCj4gPiBkYXRhYmFzZSBp biBtaW5kLCB0aGlzIHNlZW1zIGxpa2UgYSB1c2VmdWwgcHJvcG9zYWwsIHNpbmNlIGl0IGlzIG5v dAo+IHBsYXllcgo+ID4gc3BlY2lmaWMuCj4KPiBJdCBpcyBub3QgZXZlbiBtdXNpYyBzcGVjaWZp Yy4gSSd2ZSB1c2VkIHF1ZXJ5Oi8vIFVSSXMgZm9yIGEgbG9uZyB0aW1lCj4gd2l0aAo+IG1ldGFz ZXJ2ZXJzLCBhbHRob3VnaCBvbmx5IGluIGEgcmVhZC1vbmx5IGNvbnRleHQsIHdoZXJlYXMgZm9y IHdyaXRlCj4gYWNjZXNzCj4gdGhlIChhbHRlcm5hdGl2ZSkgZnVsbC1ibG93biBYTUwgaW50ZXJm YWNlIGlzIHVzZWQuCj4KPiBUaGUgd2F5IGl0IGlzIHVzZWQgZm9yIHRoZSBtZXRhc2VydmVyIGlz IGxpa2UgcXVlcnk6Ly90eXBlL2NhdGVnb3J5LCB3aGVyZQo+IGUuZy4gdHlwZSB3b3VsZCBiZSB0 aGUgZ2VuZXJpYyBuYW1lIGZvciBhIHNlcnZlciAoc2F5LCAnZnJlZWNpdicgb3IKPiAnY3Vwc2Qn KQo+IGFuZCBjYXRlZ29yeSB3b3VsZCBiZSAnY29ubmVjdGlvbicgKHRvIGdldCBiYWNrIGEgY29u bmVjdGlvbiBVUkkpIG9yCj4gJ21ldGEnCj4gKHRvIGdldCBiYWNrIG90aGVyIG1ldGFzZXJ2ZXIg VVJJcyBmb3IgdGhlIHNhbWUgdHlwZSkuCj4gVXNpbmcgc3VjaCBhIHNjaGVtZSBtYWtlcyBhbiBh cHBsaWNhdGlvbiByZXNpc3RhbnQgYWdhaW5zdCBob3N0IG5hbWUKPiBjaGFuZ2VzCj4gaW4gdGhl IGxvbmcgcnVuLCBpLmUuIGl0IHdpbGwgcGljayB1cCBtb3Zpbmcgc2VydmVycyBhdXRvbWF0aWNh bGx5Lgo+Cj4gVGhpcyBpcyBwcm9iYWJseSBub3QgdGhlIHNhbWUgdGhpbmcgYXMgeW91ciBxdWVy eSwgYnV0IG9idmlvdXNseSBpdCdzIGFsc28KPiB1c2VkIHRvIHF1ZXJ5IGEgZGF0YWJhc2UgYmVo aW5kIGl0ICh3aGljaCBpcyBhIFhNTCBkYXRhYmFzZSBpbiBteSBjYXNlLAo+IGJ1dAo+IGNvdWxk IGJlIFNRTCBvciBhbnl0aGluZyBlbHNlIGZvciB0aGF0IG1hdHRlcikuIFNvIG1heWJlIGl0IG1h a2VzIHNlbnNlIHRvCj4gc3RhbmRhcmRpc2UgdGhpcyBpbiBhIGJyb2FkZXIgY29udGV4dC4KPgo+ IEtERSBSYWRpbyBTdGF0aW9uIGlzIG9uZSBleGFtcGxlIHdoZXJlIHRoaXMgaXMgdXNlZCAoaGEg LSBmb3VuZCBhIHJlbGF0aW9uCj4gdG8KPiBtdXNpYyEpLCBhbmQgdGhlIEdHWiBHYW1pbmcgWm9u ZSBwcm9qZWN0IGlzIGFub3RoZXIgb25lICh3aGVyZSBpdAo+IG9yaWdpbmF0ZWQKPiBzaW5jZSBt ZXRhc2VydmVycyBhcmUgY29tbW9ucGxhY2Ugd2l0aCBnYW1lIHNlcnZlcnMpLgo+Cj4gSm9zZWYK PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IHhkZyBt YWlsaW5nIGxpc3QKPiB4ZGdAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCj4gaHR0cDovL2xpc3RzLmZy ZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hkZwo+Cg== ------=_Part_3405_33193106.1150971787566 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline WWVhaCB3ZWxsIGp1c3QgdG8gc3RheSB3aXRoaW4gdGhlIGZvY3VzIG9mIGEgbXVzaWMgbGlicmFy eSwgdGhlcmUgaGFzIHRvIGJlIHNvbWV0aGluZzxicj50aGF0IGRvZXMgdGhlIHJlc29sdXRpb24u PGJyPjxicj5PTkUgcG9zc2libGUgb3B0aW9uIHdvdWxkIGJlIHRvIHNwZWNpZnkgYSBELUJVUyBp bnRlcmZhY2UgbmFtZSwgYW5kIGEgaGF2ZSBzaW1wbGUgbGF1bmNoZXIuPGJyPjxicj5BbGwgYXBw cyBzdXBwb3J0aW5nIE1MUXMgd291bGQgaGF2ZSB0byBoYXZlIGEgbWluaW1hbCBjb21tb24gc3Vi c2V0Cjxicj5vZiBELUJVUyBpbnRlcmZhY2VyeSB0byBhbGxvdyB0aGlzIGtpbmQgb2YgcXVlcnkg dG8gYmUgc2VudCB0byB0aGVtIGluIHNvbWUgd2F5PGJyPihzb21ldGhpbmcgbGlrZSBhbiBBZGRV cmkgY2FsbCBtaWdodCBqdXN0IHN1ZmZpY2UpLCB0aGVuIHRoZSBsYXVuY2hlciB3b3VsZCBiYXNp Y2FsbHk8YnI+Y29uc2lzdCBvZiBzdGFydGluZyB0aGUgcmVsZXZhbnQgYXBsbGljYXRpb24gdHJv dWdoIEQtQlVTIGFjdGl2YXRpb24sIGFuZCB0aGVuIHBhc3Mgb24KPGJyPnRoZSBhY3R1YWwgcXVl cnkgdG8gaXQuIDxicj48YnI+KFdlIGhhdmUgYSBkdW1teSBtZXRob2QgJnF1b3Q7U3RhcnR1cCZx dW90OyBvbiBvdXIgRC1CVVMgaWZhY2Ugd2hpY2g8YnI+ZG9lcyBub3RoaW5nLCBidXQgY2F1c2Vz IEQtQlVTIHRvIHN0YXJ0IHVwIEJNUC4gVGhlIHJlYXNvbmluZyBpcyB0aGF0IHdlIGhhdmUgb25l IG1haW48YnI+YmluYXJ5IGFuZCBvbmUgJnF1b3Q7cmVtb3RlJnF1b3Q7IGJpbmFyeSwgd2hpY2gg aXMgdGhvdWdoIHNldCBzbyB0aGF0IGl0IGlzIHBlcmNlaXZlZCBhcyBiZWluZyB0aGUgbWFpbgo8 YnI+YmluYXJ5LCBhcyBpbiBpdCdzIGluIC91c3IvYmluLCB3aGVyZWFzIHRoZSAtYmluIChtYWlu KSBiaW5hcnkgaXMgaW4gL3Vzci9saWJleGVjLiBUaGUgcmVhc29uPGJyPmlzIHNvIHRoYXQgd2Ug aGF2ZSBhIGxpZ2h0d2VpZ2h0IHJlbW90ZSBhcHAgdGhhdCBjYW4gcGVyZm9ybSBhY3Rpb25zIG9u IHRoZSBtYWluIGJpbmFyeTxicj5hbmQgZG9uJ3QgaGF2ZSB0byBoYXZlIHRoZSBtYWluIGFwcCBi ZSBjYXBhYmxlIG9mIGJlaW5nIGEgY2xpZW50IHRvIGl0J3Mgb3duIHNlcnZlcgo8YnI+YW5kIGhh dmUgYWxsIHRoZSBzdGFydHVwIHNoaXp6bGUgZ29pbmcganVzdCB0byBwZXJmb3JtIGEgY2VydGFp biByZW1vdGUgb3BlcmF0aW9uKS48YnI+PGJyPkZvciBleGFtcGxlIHlvdSdkIGhhdmU6PGJyPnF1 ZXJ5Oi8vb3JnLmJlZXBtZWRpYXBsYXllci5ibXAvP2FydGlzdD1BaXImYW1wO0FsYnVtPU1vb24l MjBTYWZhcmk8YnI+PGJyPlRoZSBzY3JpcHQsIG9yIGJlIGl0IGEgYmluYXJ5LCBsZXQncyBjYWxs IGl0ICZxdW90O3BsYXktbWxxJnF1b3Q7LCB3b3VsZCBsYXVuY2ggdGhlCjxicj5wbGF5ZXIgd2l0 aCB0aGUgc3BlY2lmaWVkIGludGVyZmFjZSBhbmQgcGFzcyBpdCB0aGUgYWN0dWFsIHF1ZXJ5Ljxi cj48YnI+X0Fub3RoZXJfIHBvc3NpYmlsaXR5LCBhbHRob3VnaCB0aGlzIHdvdWxkIHJlcXVpcmUg cGxheWVycyB0aGF0IGNhbiB3b3JrIHdpdGg8YnI+bXV0YWJsZSBwbGF5bGlzdHMgbGlrZSBCTVAs IGlzIHRoYXQgaXQgd291bGQgcGFzcyB0aGUgcXVlcnkgb24gdG8gCmUuZy4gc29tZXRoaW5nPGJy Pmxpa2UgVHJhY2tlciBvciBzb21lIG90aGVyIGluZGV4ZXIsIHdoaWNoIHdvdWxkIHRoZW4gZXhl Y3V0ZSB0aGUgcXVlcnkgYW5kPGJyPl9JVF8gd291bGQgdGhlbiBzdGFydCB0aGUgcGxheWVyIHNw ZWNpZmllZCBieSB0aGUgaW50ZXJmYWNlIGFuZCBwYXNzIGl0IGFsb25nIHRoZTxicj5yZXN1bHRp bmcgVVJJcy48YnI+PGJyPi0tIE1pbG9zejxicj48YnI+CjxkaXY+PHNwYW4gY2xhc3M9ImdtYWls X3F1b3RlIj5PbiA2LzIyLzA2LCA8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+Sm9zZWYgU3Bp bGxuZXI8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86c3BpbGxuZXJAa2RlLm9yZyI+c3BpbGxuZXJA a2RlLm9yZzwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv dGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFy Z2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4KQWxsZSAxMToyNSwg Z2lvdmVkw6wsIDIyLiBnaXVnbm8gMjAwNiwgTWlsb3N6IERlcmV6eW5za2kgaGEgc2NyaXR0bzo8 YnI+Jmd0OyBTaW5jZSB0aGlzIGlzIHZlcnkgY29tbW9uLCBhbmQgaGF2aW5nIHRoZSBkaXNjdXNz aW9ucyBhYm91dCBhIGNvbW1vbiBtdXNpYzxicj4mZ3Q7IGRhdGFiYXNlIGluIG1pbmQsIHRoaXMg c2VlbXMgbGlrZSBhIHVzZWZ1bCBwcm9wb3NhbCwgc2luY2UgaXQgaXMgbm90IHBsYXllcgo8YnI+ Jmd0OyBzcGVjaWZpYy48YnI+PGJyPkl0IGlzIG5vdCBldmVuIG11c2ljIHNwZWNpZmljLiBJJ3Zl IHVzZWQgcXVlcnk6Ly8gVVJJcyBmb3IgYSBsb25nIHRpbWUgd2l0aDxicj5tZXRhc2VydmVycywg YWx0aG91Z2ggb25seSBpbiBhIHJlYWQtb25seSBjb250ZXh0LCB3aGVyZWFzIGZvciB3cml0ZSBh Y2Nlc3M8YnI+dGhlIChhbHRlcm5hdGl2ZSkgZnVsbC1ibG93biBYTUwgaW50ZXJmYWNlIGlzIHVz ZWQuCjxicj48YnI+VGhlIHdheSBpdCBpcyB1c2VkIGZvciB0aGUgbWV0YXNlcnZlciBpcyBsaWtl IHF1ZXJ5Oi8vdHlwZS9jYXRlZ29yeSwgd2hlcmU8YnI+ZS5nLiB0eXBlIHdvdWxkIGJlIHRoZSBn ZW5lcmljIG5hbWUgZm9yIGEgc2VydmVyIChzYXksICdmcmVlY2l2JyBvciAnY3Vwc2QnKTxicj5h bmQgY2F0ZWdvcnkgd291bGQgYmUgJ2Nvbm5lY3Rpb24nICh0byBnZXQgYmFjayBhIGNvbm5lY3Rp b24gVVJJKSBvciAnbWV0YScKPGJyPih0byBnZXQgYmFjayBvdGhlciBtZXRhc2VydmVyIFVSSXMg Zm9yIHRoZSBzYW1lIHR5cGUpLjxicj5Vc2luZyBzdWNoIGEgc2NoZW1lIG1ha2VzIGFuIGFwcGxp Y2F0aW9uIHJlc2lzdGFudCBhZ2FpbnN0IGhvc3QgbmFtZSBjaGFuZ2VzPGJyPmluIHRoZSBsb25n IHJ1biwgaS5lLiBpdCB3aWxsIHBpY2sgdXAgbW92aW5nIHNlcnZlcnMgYXV0b21hdGljYWxseS48 YnI+PGJyPlRoaXMgaXMgcHJvYmFibHkgbm90IHRoZSBzYW1lIHRoaW5nIGFzIHlvdXIgcXVlcnks IGJ1dCBvYnZpb3VzbHkgaXQncyBhbHNvCjxicj51c2VkIHRvIHF1ZXJ5IGEgZGF0YWJhc2UgYmVo aW5kIGl0ICh3aGljaCBpcyBhIFhNTCBkYXRhYmFzZSBpbiBteSBjYXNlLCBidXQ8YnI+Y291bGQg YmUgU1FMIG9yIGFueXRoaW5nIGVsc2UgZm9yIHRoYXQgbWF0dGVyKS4gU28gbWF5YmUgaXQgbWFr ZXMgc2Vuc2UgdG88YnI+c3RhbmRhcmRpc2UgdGhpcyBpbiBhIGJyb2FkZXIgY29udGV4dC48YnI+ PGJyPktERSBSYWRpbyBTdGF0aW9uIGlzIG9uZSBleGFtcGxlIHdoZXJlIHRoaXMgaXMgdXNlZCAo aGEgLSBmb3VuZCBhIHJlbGF0aW9uIHRvCjxicj5tdXNpYyEpLCBhbmQgdGhlIEdHWiBHYW1pbmcg Wm9uZSBwcm9qZWN0IGlzIGFub3RoZXIgb25lICh3aGVyZSBpdCBvcmlnaW5hdGVkPGJyPnNpbmNl IG1ldGFzZXJ2ZXJzIGFyZSBjb21tb25wbGFjZSB3aXRoIGdhbWUgc2VydmVycykuPGJyPjxicj5K b3NlZjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj54ZGcgbWFpbGluZyBsaXN0Cjxicj48YSBocmVmPSJtYWlsdG86eGRnQGxpc3RzLmZyZWVkZXNr dG9wLm9yZyI+eGRnQGxpc3RzLmZyZWVkZXNrdG9wLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cDov L2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hkZyI+aHR0cDovL2xpc3Rz LmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hkZzwvYT48YnI+PC9ibG9ja3F1b3Rl PjwvZGl2Pjxicj4K ------=_Part_3405_33193106.1150971787566-- From jamiemcc@blueyonder.co.uk Thu Jun 22 06:41:17 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 687D03B0251 for ; Thu, 22 Jun 2006 06:41:17 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17075-06 for ; Thu, 22 Jun 2006 06:41:15 -0400 (EDT) Received: from smtp-out5.blueyonder.co.uk (smtp-out5.blueyonder.co.uk [195.188.213.8]) by menubar.gnome.org (Postfix) with ESMTP id 74F7B3B021B for ; Thu, 22 Jun 2006 06:41:15 -0400 (EDT) Received: from [172.23.170.145] (helo=anti-virus03-08) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1FtMca-0004xo-T2; Thu, 22 Jun 2006 11:41:12 +0100 Received: from [62.30.198.187] (helo=[62.30.198.187]) by asmtp-out2.blueyonder.co.uk with esmtpa (Exim 4.52) id 1FtMcZ-0001pP-Rp; Thu, 22 Jun 2006 11:41:11 +0100 Message-ID: <449A73D1.6030401@blueyonder.co.uk> Date: Thu, 22 Jun 2006 11:41:21 +0100 From: Jamie McCracken User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Milosz Derezynski Subject: Re: MLQ: Followup References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.459 tagged_above=-999 required=2 tests=[AWL=0.141, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.459 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 10:41:17 -0000 Milosz Derezynski wrote: > What i forgot to mention: > > One benefit of MLQs over 'regular' playlists at least with BMP 2 is that > i've introduced a concept of keeping track of tracks across mount point > changes which basically works like this: > > BMP stores for each file the HAL volume and device UDI, and the VRP > (Volume Relative Path), that is, the path stripped off the mount point root. > Whenever it seems that a file is missing, it checks whether the volume > UDI of this file is still present on the system, and if so, gathers the > new mount point, and adjusts the URI of this > file in the library (this obiviously only works with tracks from the > library only anyway since only there we can reliably store the HAL > volume/device UDI and the VRP). > > This means practically: > > - Mount your music to /music > - Start BMP > - Add music from /music to the library > - Quit BMP > - Remount /music to e.g. /old_music > - Start BMP > - Use the library as before. Whenever BMP finds a file is missing, it > will correct the URI on-the-fly as long as the volume is mounted at all > on the system (and has an UDI to begin with; problem cases here are > network volumes, NFS and SMBFS) > > So the benefit of an MLQ is that unlike a static playlist, you can be > rather sure that no matter where you really move the music, BMP will > always be able to find it. > > Downsides/doesn't-works: > > - There is no volume UDI available > - You make a regular 'move' (mv), and not just a remount > > In the context of having a common music database, or something like > Tracker, this seems very useful (Jamie: Hence my urge to add HAL > volume/device UDI per file to the metadata). Im quite happy to add this as metadata to tracker and even get tracker to hide stuff based on it (using hal) but it still needs to be part of the uri for a music file (otherwise we wont be able to uniquely identify the files) -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ From jamiemcc@blueyonder.co.uk Thu Jun 22 06:52:34 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 93DEE3B031A for ; Thu, 22 Jun 2006 06:52:34 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17877-10 for ; Thu, 22 Jun 2006 06:52:32 -0400 (EDT) Received: from smtp-out5.blueyonder.co.uk (smtp-out5.blueyonder.co.uk [195.188.213.8]) by menubar.gnome.org (Postfix) with ESMTP id 66C8B3B0262 for ; Thu, 22 Jun 2006 06:52:32 -0400 (EDT) Received: from [172.23.170.140] (helo=anti-virus02-07) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1FtMnX-0007Tp-4T; Thu, 22 Jun 2006 11:52:31 +0100 Received: from [62.30.198.187] (helo=[62.30.198.187]) by asmtp-out1.blueyonder.co.uk with esmtpa (Exim 4.52) id 1FtMnU-0001TX-7r; Thu, 22 Jun 2006 11:52:28 +0100 Message-ID: <449A7676.6060309@blueyonder.co.uk> Date: Thu, 22 Jun 2006 11:52:38 +0100 From: Jamie McCracken User-Agent: Thunderbird 1.5.0.2 (X11/20060522) MIME-Version: 1.0 To: Milosz Derezynski Subject: Re: MLQ (Media Library Query) file format and mime type proposal References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.422 tagged_above=-999 required=2 tests=[AWL=0.101, BAYES_00=-2.599, SPF_PASS=-0.001, TW_RQ=0.077] X-Spam-Score: -2.422 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 10:52:34 -0000 Milosz Derezynski wrote: > Hi, > > I'm one of the main authors of BMP 2 (still being worked on), and along > the way of reworking our library, i came across the idea of encoding > library queries as URIs, which may look like this: > > "query:///?artist=Air&album=Moon%20Safari" > > BMP 2 has a plugin archicture which is a small VFS on it's own, and we > treat certain things as "containers" (i.e. they "contain" URIs, like PLS > playlists, XSPF, M3U, etc). > Now i thought it might be not a bad idea to create a playlist format > with these query URLs, and i've called it "MLQ" for media library query. > In theory, it's not even > application specific. The keys (identifiers), like artist, album, etc, > are all based on GStreamer tag identifiers. (They could be maybe adapted > to http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , > but it seems insufficient and doesn't specify certain items, like > musicbrainz metadata, which GST does). Tracker's metadata spec does (http://freedesktop.org/wiki/Standards/shared-filemetadata-spec) > > So i've called this file format "MLQ", with the extension .mlq, created > a mime package file for it: > > > > > Media Library Query List > > > > > > > > Adding a file of this type to BMPx, or just a plain query:/// URI itself > causes a library query and appending of the relevant items to the > tracklist (BMP is currently mostly based on the concept of a mutable > playlist to which items can be added from various sources, unlike e.g. > RB which has mostly immutable "Playlists", but allows for custom queues). > > Another example is: > > query:///?artist=Air&album=Moon%20Safari&title=La%20Femme%20d'Argent > query:///?artist=Air&album=Moon%20Safari&title=Sexy%20Boy > query:///?artist=Air&album=Moon%20Safari&title=All%20I%20Need > query:///?artist=Air&album=Moon%20Safari&title=Kelly,%20Watch%20The%20Stars! > query:///?artist=Air&album=Moon%20Safari&title=Talisman > query:///?artist=Air&album=Moon%20Safari&title=Remember > query:///?artist=Air&album=Moon%20Safari&title=You%20Make%20It%20Easy > query:///?artist=Air&album=Moon%20Safari&title=Ce%20Matin%20La > query:///?artist=Air&album=Moon%20Safari&title=New%20Star%20In%20The%20Sky > query:///?artist=Air&album=Moon%20Safari&title=Le%20Voyage%20De%20Penelope > > Or it might just be: > > query:///?genre=Jazz > > Since this is very common, and having the discussions about a common > music database in mind, this seems like a useful proposal, since it is > not player specific. > This ships currently with BMP 2/BMPx SVN, and while i will ship this > with the 0.20 release (end-July) anyway, what does everyone think of > this in a broader context (common music database, etc)? Could be interesting as an alternative to rdf query that tracker uses but rdf query is a *standard* and is the WC3's recommended means of querying metadata. A more compact version of the xml based rdf query language is sparql (http://www.w3.org/TR/rdf-sparql-query/) and is also a candidate for standardisation. I guess its going to be fun deciding which to use (I will go with the flow) -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ From doclivingston@gmail.com Thu Jun 22 07:00:08 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 966243B038B for ; Thu, 22 Jun 2006 07:00:08 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18372-10 for ; Thu, 22 Jun 2006 07:00:05 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by menubar.gnome.org (Postfix) with ESMTP id 2DC8B3B00ED for ; Thu, 22 Jun 2006 07:00:05 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id f25so276546pyf for ; Thu, 22 Jun 2006 04:00:04 -0700 (PDT) Received: by 10.35.91.15 with SMTP id t15mr948347pyl; Thu, 22 Jun 2006 04:00:04 -0700 (PDT) Received: from alyrion.local ( [144.139.19.209]) by mx.gmail.com with ESMTP id w28sm110735pyc.2006.06.22.04.00.02; Thu, 22 Jun 2006 04:00:04 -0700 (PDT) Subject: Re: MLQ: Followup From: "James \"Doc\" Livingston" To: gnome-multimedia@gnome.org In-Reply-To: References: Content-Type: text/plain Date: Thu, 22 Jun 2006 20:59:59 +1000 Message-Id: <1150973999.5186.17.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.317 tagged_above=-999 required=2 tests=[AWL=0.283, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.317 X-Spam-Level: X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: doclivingston@gmail.com List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 11:00:08 -0000 On Thu, 2006-06-22 at 11:32 +0200, Milosz Derezynski wrote: > One benefit of MLQs over 'regular' playlists at least with BMP 2 is > that i've introduced a concept of keeping track of tracks across mount > point changes which basically works like this: > So the benefit of an MLQ is that unlike a static playlist, you can be > rather sure that no matter where you really move the music, BMP will > always be able to find it. I'm a bit confused about how "HAL UDI + partial path" is related to the MLQ idea. To me they seem fairly orthogonal. However using HAL UDIs is a good idea. Most apps currently use the URI as it's unique identifier and the method of finding the actual file, we could decide that the common db would use a as the unique id/location method. > Downsides/doesn't-works: > - There is no volume UDI available If this is a permanent thing, e.g. a non-HAL system or a http:// resource, then we could say that a null UDI and the full uri would be used instead. If it's temporary, e.g. HAL isn't running, or isn't detecting the device properly, then it's probably more complicated. Dealing with the fact that the users music is stored as and we don't know the URI would be funky. Perhaps we could say all db entries have the field, and a "last known"/non-HAL location field. > - You make a regular 'move' (mv), and not just a remount That is different again, and is probably best solved with audio fingerprinting, and/or embedding unique metadata in the file. Cheers. James "Doc" Livingston -- If USENET is anarchy, IRC is a paranoid schizophrenic after 6 days on speed. -- Chris "Saundo" Saunderson in asr. From doclivingston@gmail.com Thu Jun 22 07:04:28 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id CFF783B0254 for ; Thu, 22 Jun 2006 07:04:28 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18854-05 for ; Thu, 22 Jun 2006 07:04:27 -0400 (EDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.181]) by menubar.gnome.org (Postfix) with ESMTP id 0309C3B05B2 for ; Thu, 22 Jun 2006 07:04:26 -0400 (EDT) Received: by py-out-1112.google.com with SMTP id f28so267516pyf for ; Thu, 22 Jun 2006 04:04:26 -0700 (PDT) Received: by 10.35.82.15 with SMTP id j15mr949278pyl; Thu, 22 Jun 2006 04:04:26 -0700 (PDT) Received: from alyrion.local ( [144.139.19.209]) by mx.gmail.com with ESMTP id w66sm860753pyw.2006.06.22.04.04.24; Thu, 22 Jun 2006 04:04:26 -0700 (PDT) Subject: Re: MLQ (Media Library Query) file format and mime type proposal From: "James \"Doc\" Livingston" To: gnome-multimedia@gnome.org In-Reply-To: References: Content-Type: text/plain Date: Thu, 22 Jun 2006 21:04:21 +1000 Message-Id: <1150974261.5186.22.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.319 tagged_above=-999 required=2 tests=[AWL=0.281, BAYES_00=-2.599, SPF_PASS=-0.001] X-Spam-Score: -2.319 X-Spam-Level: X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list Reply-To: doclivingston@gmail.com List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 11:04:29 -0000 On Thu, 2006-06-22 at 11:25 +0200, Milosz Derezynski wrote: > I'm one of the main authors of BMP 2 (still being worked on), and > along the way of reworking our library, i came across the idea of > encoding library queries as URIs, which may look like this: > > "query:///?artist=Air&album=Moon%20Safari" > Adding a file of this type to BMPx, or just a plain query:/// URI > itself causes a library query and appending of the relevant items to > the tracklist (BMP is currently mostly based on the concept of a > mutable playlist to which items can be added from various sources, > unlike e.g. RB which has mostly immutable "Playlists", but allows for > custom queues). I'm a bit confused as to what this is actually for. Is it meant for saving "smart playlist"-type (or other db queries) things to disk? If so, it's probably better to use one of the existing query formats. If we want to use XML, then RDF (which is what Tracker uses for all it's queries) is probably as good as anything. James "Doc" Livingston -- "The Web brings people together because no matter what kind of a twisted sexual mutant you happen to be, you've got millions of pals out there. Type in 'Find people that have sex with goats that are on fire' and the computer will ask, 'Specify type of goat.'" -- Rich Jeni From internalerror@gmail.com Thu Jun 22 07:35:27 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id BBE833B064F for ; Thu, 22 Jun 2006 07:35:27 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20711-02 for ; Thu, 22 Jun 2006 07:35:26 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.197]) by menubar.gnome.org (Postfix) with ESMTP id 1F4E83B0528 for ; Thu, 22 Jun 2006 07:35:26 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so334141wxc for ; Thu, 22 Jun 2006 04:35:26 -0700 (PDT) Received: by 10.70.65.10 with SMTP id n10mr2935604wxa; Thu, 22 Jun 2006 04:35:25 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 04:35:25 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 13:35:25 +0200 From: "Milosz Derezynski" To: doclivingston@gmail.com Subject: Re: MLQ: Followup In-Reply-To: <1150973999.5186.17.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3961_29338319.1150976125920" References: <1150973999.5186.17.camel@localhost.localdomain> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.246 tagged_above=-999 required=2 tests=[AWL=0.353, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.246 X-Spam-Level: Cc: gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 11:35:27 -0000 ------=_Part_3961_29338319.1150976125920 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/22/06, James Doc Livingston wrote: If it's temporary, e.g. HAL isn't running, or isn't detecting the device > properly, then it's probably more complicated. Dealing with the fact > that the users music is stored as and we don't know the URI > would be funky. Perhaps we could say all db entries have the > field, and a "last known"/non-HAL location field. > That's what i'm currently doing, i store the full URI, but also the UDI and the partial path, and in case HAL is not avaiable there is still the full URI present as a current resort. The ideal situation would be that HAL would be always available, would have UDIs for all volumes, and would run on all systems we need to run this to (Including let's say Solaris, etc), in which case it would be exactly what you said, one would need to only store the volume UDI and the partial path. Well anyway, repeating myself, just wanted to add that we also already store the full URI as a backup. ------=_Part_3961_29338319.1150976125920 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 6/22/06, James Doc Livingston <doclivingston@gmail.com> wrote:

If it's temporary, e.g. HAL isn't running, or isn't detecting the device
properly, then it's probably more complicated. Dealing with the fact
that the users music is stored as <UDI, path> and we don't know the URI
would be funky. Perhaps we could say all db entries have the <UDI, path>
field, and a "last known"/non-HAL location field.


That's what i'm currently doing, i store the full URI, but also the UDI and the partial path,
and in case HAL is not avaiable there is still the full URI present as a current resort.

The ideal situation would be that HAL would be always available, would have UDIs for all
volumes, and would run on all systems we need to run this to (Including let's say Solaris,
etc), in which case it would be exactly what you said, one would need to only store the volume
UDI and the partial path. Well anyway, repeating myself, just wanted to add that we also
already store the full URI as a backup.
------=_Part_3961_29338319.1150976125920-- From internalerror@gmail.com Thu Jun 22 12:04:05 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 802573B0830 for ; Thu, 22 Jun 2006 12:04:05 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07916-06 for ; Thu, 22 Jun 2006 12:04:01 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.201]) by menubar.gnome.org (Postfix) with ESMTP id 35C833B083F for ; Thu, 22 Jun 2006 12:01:33 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so373874wxc for ; Thu, 22 Jun 2006 09:01:32 -0700 (PDT) Received: by 10.70.83.20 with SMTP id g20mr3337015wxb; Thu, 22 Jun 2006 09:01:32 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 09:01:32 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 18:01:32 +0200 From: "Milosz Derezynski" To: "Frans Englich" Subject: Re: MLQ (Media Library Query) file format and mime type proposal In-Reply-To: <200606221419.00204.frans.englich@telia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7583_10781705.1150992092417" References: <200606221419.00204.frans.englich@telia.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.073 tagged_above=-999 required=2 tests=[AWL=0.152, BAYES_00=-2.599, HTML_30_40=0.374, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.073 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 16:04:05 -0000 ------=_Part_7583_10781705.1150992092417 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/22/06, Frans Englich wrote: > > On Thursday 22 June 2006 09:25, Milosz Derezynski wrote: > > Hi, > > > > I'm one of the main authors of BMP 2 (still being worked on), and along > the > > way of reworking our library, i came across the idea of encoding library > > queries as URIs, which may look like this: > > > > "query:///?artist=Air&album=Moon%20Safari" > > (Is that at all a valid URI? I'm not sure.) I think it is valid yes. First of all, one can't simply invent ones own URI scheme, because it causes > trouble. Especially, for such a generic name as "query". This document > discusses this further: > > http://developer.kde.org/policies/uri-guidelines.xhtml > > How is interoperability for "query" ensured? Is it specified? Not at all yet but because of that i'm asking on those 2 lists here now (xdg and gnome-multimedia), and furthermore i made some interoperability proposals, just 2 totally off my head but not totally out of place either. > BMP 2 has a plugin archicture which is a small VFS on it's own, and we > > treat certain things as "containers" (i.e. they "contain" URIs, like PLS > > playlists, XSPF, M3U, etc). > > Now i thought it might be not a bad idea to create a playlist format > with > > these query URLs, and i've called it "MLQ" for media library query. In > > theory, it's not even > > application specific. The keys (identifiers), like artist, album, etc, > are > > all based on GStreamer tag identifiers. (They could be maybe adapted to > > http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , > but > > it seems insufficient and doesn't specify certain items, like > musicbrainz > > metadata, which GST does). > > > > So i've called this file format "MLQ", with the extension .mlq, created > a > > mime package file for it: > > I think this highlights possible trouble. Anyone else who decides to > invent "query" will get detected as "Media Library Query List". All that's > needed to fix this is to use URIs properly. Yeah well that is problematic for them haha :P > However, I wouldn't invent a new URI scheme for this, it's too context > dependent. Music players & hardware(ipods, music players, music sharing > sites, and so on) is quite popular in western societies right now, but > next > year it's something different. Technologies, such as a URI scheme, > shouldn't > be hard coded on a specific use, it should be generic. > > Re-use existing technologies. There's plenty of work and research on meta > data > and querying data. Here's my suggestions: > > Express the format in XML. This has nothing to do with XML files("text"), > unless one wants to. It means the format is conceptually, on an "abstract" > level, described in XML which in turn opens up the door for all methods > XML > has. > > For example, one could use an XPointer fragment with an XPath scheme: > > file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album > = 'Safari')) > > If "music collections" cannot be located as files, invent a scheme which > can > identify them on this "abstract level." That is actually a very good idea (to use an XPath), but then again i would be abusing the file:/// scheme. What should it point to? Even if it would point to the physical location of the database file, in my specific case this would be ~/.local/share/bmpx/library.mlib, so file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz and @album='Safari')), then i would be basically still "making something up", as you cannot pass THIS uri to, say, a filemanager, and it would recognize it and do the correct thing. Now of course it won't recognize query:/// either, but i made 2 proposals which would spec query:/// in this way system wide. What i'm up to is that while your proposal with file seems more sane (and XPath/XPointer is certainly better than using a GET string, i might really consider changing the query:/// URI to use that), it actually is no different. Those kinds of file:/// URIs would need special treatment as well, and in fact, would cause even more headache possibly, as file:/// _IS_ already a known scheme which is already specced etc, etd. However, I would first assess RDF as suggested in this thread, since it is > designed exactly for things like this. Well RDF possibly, but i think i will never in my life use SPARQL. I took a look at it and i want these things if not neccessarily, then at least possibly, human editable, buit SPARQL is just way beyond the comprehension of taking a quick glance at the file and making some corrections. > > Cheers, > > Frans > -- Milosz ------=_Part_7583_10781705.1150992092417 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 6/22/06, Frans Englich <frans.englich@telia.com> wrote:
On Thursday 22 June 2006 09:25, Milosz Derezynski wrote:
> Hi,
>
> I'm one of the main authors of BMP 2 (still being worked on), and along the
> way of reworking our library, i came across the idea of encoding library
> queries as URIs, which may look like this:
>
> "query:///?artist=Air&album=Moon%20Safari"

(Is that at all a valid URI? I'm not sure.)

I think it is valid yes.

First of all, one can't simply invent ones own URI scheme, because it causes
trouble. Especially, for such a generic name as "query". This document
discusses this further:

http://developer.kde.org/policies/uri-guidelines.xhtml

How is interoperability for "query" ensured? Is it specified?

Not at all yet but  because of that i'm asking on those 2 lists here now (xdg
and gnome-multimedia), and furthermore i made some interoperability
proposals, just 2 totally off my head but not totally out of place either.
 

> BMP 2 has a plugin archicture which is a small VFS on it's own, and we
> treat certain things as "containers" (i.e. they "contain" URIs, like PLS
> playlists, XSPF, M3U, etc).
> Now i thought it might be not a bad idea to create a playlist format with
> these query URLs, and i've called it "MLQ" for media library query. In
> theory, it's not even
> application specific. The keys (identifiers), like artist, album, etc, are
> all based on GStreamer tag identifiers. (They could be maybe adapted to
> http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but
> it seems insufficient and doesn't specify certain items, like musicbrainz
> metadata, which GST does).
>
> So i've called this file format "MLQ", with the extension .mlq, created a
> mime package file for it:

I think this highlights possible trouble. Anyone else who decides to
invent "query" will get detected as "Media Library Query List". All that's
needed to fix this is to use URIs properly.

Yeah well that is problematic for them haha :P
 
However, I wouldn't invent a new URI scheme for this, it's too context
dependent. Music players & hardware(ipods, music players, music sharing
sites, and so on) is quite popular in western societies right now, but next
year it's something different. Technologies, such as a URI scheme, shouldn't
be hard coded on a specific use, it should be generic.

Re-use existing technologies. There's plenty of work and research on meta data
and querying data. Here's my suggestions:

Express the format in XML. This has nothing to do with XML files("text"),
unless one wants to. It means the format is conceptually, on an "abstract"
level, described in XML which in turn opens up the door for all methods XML
has.

For example, one could use an XPointer fragment with an XPath scheme:

file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album
= 'Safari'))

If "music collections" cannot be located as files, invent a scheme which can
identify them on this "abstract level."


That is actually a very good idea (to use an XPath), but then again i would be abusing
the file:/// scheme. What should it point to? Even if it would point to the physical location
of the database file, in my specific case this would be ~/.local/share/bmpx/library.mlib,
so file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz
and @album='Safari')), then i would be basically still "making something up", as you cannot
pass THIS uri to, say, a filemanager, and it would recognize it and do the correct thing.

Now of course it won't recognize query:/// either, but i made 2 proposals which would spec
query:/// in this way system wide.

What i'm up to is that while your proposal with file seems
more sane (and XPath/XPointer is certainly better than using a GET string, i might really
consider changing the query:/// URI to use that), it actually is no different. Those kinds of
file:/// URIs would need special treatment as well, and in fact, would cause even more headache
possibly, as file:/// _IS_ already a known scheme which is already specced etc, etd.
 

However, I would first assess RDF as suggested in this thread, since it is
designed exactly for things like this.

Well RDF possibly, but i think i will never in  my life use SPARQL. I took a look at it
and i want these things if not neccessarily, then at least possibly, human editable,
buit SPARQL is just way beyond the comprehension of taking a quick glance at the
file and making some corrections.
 

Cheers,

                Frans


-- Milosz
------=_Part_7583_10781705.1150992092417-- From internalerror@gmail.com Thu Jun 22 12:13:45 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 5FD223B0389 for ; Thu, 22 Jun 2006 12:13:45 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08581-05 for ; Thu, 22 Jun 2006 12:13:43 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.205]) by menubar.gnome.org (Postfix) with ESMTP id B81413B01D2 for ; Thu, 22 Jun 2006 12:13:42 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so375754wxc for ; Thu, 22 Jun 2006 09:13:42 -0700 (PDT) Received: by 10.70.18.10 with SMTP id 10mr3379733wxr; Thu, 22 Jun 2006 09:13:42 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 09:13:41 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 18:13:41 +0200 From: "Milosz Derezynski" To: "Frans Englich" Subject: Re: MLQ (Media Library Query) file format and mime type proposal In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7734_19670285.1150992821952" References: <200606221419.00204.frans.englich@telia.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.079 tagged_above=-999 required=2 tests=[AWL=0.146, BAYES_00=-2.599, HTML_30_40=0.374, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.079 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 16:13:45 -0000 ------=_Part_7734_19670285.1150992821952 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I didn't know about tag URIs though, i'm taking a look at it now, thanks. On 6/22/06, Milosz Derezynski wrote: > > > > On 6/22/06, Frans Englich wrote: > > > > On Thursday 22 June 2006 09:25, Milosz Derezynski wrote: > > > Hi, > > > > > > I'm one of the main authors of BMP 2 (still being worked on), and > > along the > > > way of reworking our library, i came across the idea of encoding > > library > > > queries as URIs, which may look like this: > > > > > > "query:///?artist=Air&album=Moon%20Safari" > > > > (Is that at all a valid URI? I'm not sure.) > > > I think it is valid yes. > > First of all, one can't simply invent ones own URI scheme, because it > > causes > > trouble. Especially, for such a generic name as "query". This document > > discusses this further: > > > > http://developer.kde.org/policies/uri-guidelines.xhtml > > > > How is interoperability for "query" ensured? Is it specified? > > > Not at all yet but because of that i'm asking on those 2 lists here now > (xdg > and gnome-multimedia), and furthermore i made some interoperability > proposals, just 2 totally off my head but not totally out of place either. > > > > BMP 2 has a plugin archicture which is a small VFS on it's own, and we > > > treat certain things as "containers" (i.e. they "contain" URIs, like > > PLS > > > playlists, XSPF, M3U, etc). > > > Now i thought it might be not a bad idea to create a playlist format > > with > > > these query URLs, and i've called it "MLQ" for media library query. In > > > theory, it's not even > > > application specific. The keys (identifiers), like artist, album, etc, > > are > > > all based on GStreamer tag identifiers. (They could be maybe adapted > > to > > > http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , > > but > > > it seems insufficient and doesn't specify certain items, like > > musicbrainz > > > metadata, which GST does). > > > > > > So i've called this file format "MLQ", with the extension .mlq, > > created a > > > mime package file for it: > > > > I think this highlights possible trouble. Anyone else who decides to > > invent "query" will get detected as "Media Library Query List". All > > that's > > needed to fix this is to use URIs properly. > > > Yeah well that is problematic for them haha :P > > > > However, I wouldn't invent a new URI scheme for this, it's too context > > dependent. Music players & hardware(ipods, music players, music sharing > > sites, and so on) is quite popular in western societies right now, but > > next > > year it's something different. Technologies, such as a URI scheme, > > shouldn't > > be hard coded on a specific use, it should be generic. > > > > Re-use existing technologies. There's plenty of work and research on > > meta data > > and querying data. Here's my suggestions: > > > > Express the format in XML. This has nothing to do with XML > > files("text"), > > unless one wants to. It means the format is conceptually, on an > > "abstract" > > level, described in XML which in turn opens up the door for all methods > > XML > > has. > > > > For example, one could use an XPointer fragment with an XPath scheme: > > > > file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album > > = 'Safari')) > > > > If "music collections" cannot be located as files, invent a scheme which > > can > > identify them on this "abstract level." > > > > That is actually a very good idea (to use an XPath), but then again i > would be abusing > the file:/// scheme. What should it point to? Even if it would point to > the physical location > of the database file, in my specific case this would be > ~/.local/share/bmpx/library.mlib, > so file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz > > and @album='Safari')), then i would be basically still "making something > up", as you cannot > pass THIS uri to, say, a filemanager, and it would recognize it and do the > correct thing. > > Now of course it won't recognize query:/// either, but i made 2 proposals > which would spec > query:/// in this way system wide. > > What i'm up to is that while your proposal with file seems > more sane (and XPath/XPointer is certainly better than using a GET string, > i might really > consider changing the query:/// URI to use that), it actually is no > different. Those kinds of > file:/// URIs would need special treatment as well, and in fact, would > cause even more headache > possibly, as file:/// _IS_ already a known scheme which is already specced > etc, etd. > > > However, I would first assess RDF as suggested in this thread, since it is > > designed exactly for things like this. > > > Well RDF possibly, but i think i will never in my life use SPARQL. I took > a look at it > and i want these things if not neccessarily, then at least possibly, human > editable, > buit SPARQL is just way beyond the comprehension of taking a quick glance > at the > file and making some corrections. > > > > > > Cheers, > > > > Frans > > > > > -- Milosz > ------=_Part_7734_19670285.1150992821952 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I didn't know about tag URIs though, i'm taking a look at it now, thanks.

On 6/22/06, Milosz Derezynski <internalerror@gmail.com > wrote:


On 6/22/06, Frans Englich <frans.englich@telia.com> wrote:
On Thursday 22 June 2006 09:25, Milosz Derezynski wrote:
> Hi,
>
> I'm one of the main authors of BMP 2 (still being worked on), and along the
> way of reworking our library, i came across the idea of encoding library
> queries as URIs, which may look like this:
>
> "query:///?artist=Air&album=Moon%20Safari"

(Is that at all a valid URI? I'm not sure.)

I think it is valid yes.

First of all, one can't simply invent ones own URI scheme, because it causes
trouble. Especially, for such a generic name as "query". This document
discusses this further:

http://developer.kde.org/policies/uri-guidelines.xhtml

How is interoperability for "query" ensured? Is it specified?

Not at all yet but  because of that i'm asking on those 2 lists here now (xdg
and gnome-multimedia), and furthermore i made some interoperability
proposals, just 2 totally off my head but not totally out of place either.
 

> BMP 2 has a plugin archicture which is a small VFS on it's own, and we
> treat certain things as "containers" (i.e. they "contain" URIs, like PLS
> playlists, XSPF, M3U, etc).
> Now i thought it might be not a bad idea to create a playlist format with
> these query URLs, and i've called it "MLQ" for media library query. In
> theory, it's not even
> application specific. The keys (identifiers), like artist, album, etc, are
> all based on GStreamer tag identifiers. (They could be maybe adapted to
> http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but
> it seems insufficient and doesn't specify certain items, like musicbrainz
> metadata, which GST does).
>
> So i've called this file format "MLQ", with the extension .mlq, created a
> mime package file for it:

I think this highlights possible trouble. Anyone else who decides to
invent "query" will get detected as "Media Library Query List". All that's
needed to fix this is to use URIs properly.

Yeah well that is problematic for them haha :P
 
However, I wouldn't invent a new URI scheme for this, it's too context
dependent. Music players & hardware(ipods, music players, music sharing
sites, and so on) is quite popular in western societies right now, but next
year it's something different. Technologies, such as a URI scheme, shouldn't
be hard coded on a specific use, it should be generic.

Re-use existing technologies. There's plenty of work and research on meta data
and querying data. Here's my suggestions:

Express the format in XML. This has nothing to do with XML files("text"),
unless one wants to. It means the format is conceptually, on an "abstract"
level, described in XML which in turn opens up the door for all methods XML
has.

For example, one could use an XPointer fragment with an XPath scheme:

file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album
= 'Safari'))

If "music collections" cannot be located as files, invent a scheme which can
identify them on this "abstract level."


That is actually a very good idea (to use an XPath), but then again i would be abusing
the file:/// scheme. What should it point to? Even if it would point to the physical location
of the database file, in my specific case this would be ~/.local/share/bmpx/library.mlib,
so file:///home/mderezynski/.local/share/bmpx/library.mlib#xpointer(xpath1(song[@artist='Milosz
and @album='Safari')), then i would be basically still "making something up", as you cannot
pass THIS uri to, say, a filemanager, and it would recognize it and do the correct thing.

Now of course it won't recognize query:/// either, but i made 2 proposals which would spec
query:/// in this way system wide.

What i'm up to is that while your proposal with file seems
more sane (and XPath/XPointer is certainly better than using a GET string, i might really
consider changing the query:/// URI to use that), it actually is no different. Those kinds of
file:/// URIs would need special treatment as well, and in fact, would cause even more headache
possibly, as file:/// _IS_ already a known scheme which is already specced etc, etd.
 

However, I would first assess RDF as suggested in this thread, since it is
designed exactly for things like this.

Well RDF possibly, but i think i will never in  my life use SPARQL. I took a look at it
and i want these things if not neccessarily, then at least possibly, human editable,
buit SPARQL is just way beyond the comprehension of taking a quick glance at the
file and making some corrections.
 

Cheers,

                Frans


-- Milosz

------=_Part_7734_19670285.1150992821952-- From frans.englich@telia.com Thu Jun 22 10:05:56 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 164263B085B for ; Thu, 22 Jun 2006 10:05:56 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00797-01 for ; Thu, 22 Jun 2006 10:05:48 -0400 (EDT) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by menubar.gnome.org (Postfix) with ESMTP id 4FFD63B081B for ; Thu, 22 Jun 2006 10:05:38 -0400 (EDT) X-T2-Posting-ID: 2yF4ydxc0UI9xI7FHZPfog== X-Cloudmark-Score: 0.000000 [] Received: from 83.72.134.122.ip.tele2adsl.dk ([83.72.134.122] verified) by mailfe08.swip.net (CommuniGate Pro SMTP 5.0.8) with ESMTP id 217821068; Thu, 22 Jun 2006 16:05:36 +0200 From: Frans Englich To: xdg@lists.freedesktop.org Subject: Re: MLQ (Media Library Query) file format and mime type proposal Date: Thu, 22 Jun 2006 14:18:59 +0000 User-Agent: KMail/1.8.50 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606221419.00204.frans.englich@telia.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-1.051 tagged_above=-999 required=2 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_NUMERIC_HELO=1.5] X-Spam-Score: -1.051 X-Spam-Level: X-Mailman-Approved-At: Thu, 22 Jun 2006 12:45:56 -0400 Cc: gnome-multimedia@gnome.org, Milosz Derezynski X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 14:05:56 -0000 On Thursday 22 June 2006 09:25, Milosz Derezynski wrote: > Hi, > > I'm one of the main authors of BMP 2 (still being worked on), and along the > way of reworking our library, i came across the idea of encoding library > queries as URIs, which may look like this: > > "query:///?artist=Air&album=Moon%20Safari" (Is that at all a valid URI? I'm not sure.) First of all, one can't simply invent ones own URI scheme, because it causes trouble. Especially, for such a generic name as "query". This document discusses this further: http://developer.kde.org/policies/uri-guidelines.xhtml How is interoperability for "query" ensured? Is it specified? > BMP 2 has a plugin archicture which is a small VFS on it's own, and we > treat certain things as "containers" (i.e. they "contain" URIs, like PLS > playlists, XSPF, M3U, etc). > Now i thought it might be not a bad idea to create a playlist format with > these query URLs, and i've called it "MLQ" for media library query. In > theory, it's not even > application specific. The keys (identifiers), like artist, album, etc, are > all based on GStreamer tag identifiers. (They could be maybe adapted to > http://www.freedesktop.org/wiki/Standards_2faudio_2dmetadata_2dspec , but > it seems insufficient and doesn't specify certain items, like musicbrainz > metadata, which GST does). > > So i've called this file format "MLQ", with the extension .mlq, created a > mime package file for it: I think this highlights possible trouble. Anyone else who decides to invent "query" will get detected as "Media Library Query List". All that's needed to fix this is to use URIs properly. However, I wouldn't invent a new URI scheme for this, it's too context dependent. Music players & hardware(ipods, music players, music sharing sites, and so on) is quite popular in western societies right now, but next year it's something different. Technologies, such as a URI scheme, shouldn't be hard coded on a specific use, it should be generic. Re-use existing technologies. There's plenty of work and research on meta data and querying data. Here's my suggestions: Express the format in XML. This has nothing to do with XML files("text"), unless one wants to. It means the format is conceptually, on an "abstract" level, described in XML which in turn opens up the door for all methods XML has. For example, one could use an XPointer fragment with an XPath scheme: file:///myMusicColltion#xpointer(xpath1(song[@artist='Milosz' and @album = 'Safari')) If "music collections" cannot be located as files, invent a scheme which can identify them on this "abstract level." However, I would first assess RDF as suggested in this thread, since it is designed exactly for things like this. In this way one doesn't have to invent a whole query language for music files. That's like inventing C++ for writing games, C++ for fixing bugs in word processors, C++ for writing editors, and so on. Cheers, Frans From internalerror@gmail.com Thu Jun 22 13:17:35 2006 Return-Path: X-Original-To: gnome-multimedia@gnome.org Delivered-To: gnome-multimedia@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 614C33B0693 for ; Thu, 22 Jun 2006 13:17:35 -0400 (EDT) Received: from menubar.gnome.org ([127.0.0.1]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12677-02 for ; Thu, 22 Jun 2006 13:17:34 -0400 (EDT) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.201]) by menubar.gnome.org (Postfix) with ESMTP id 0CBD83B06C8 for ; Thu, 22 Jun 2006 13:17:33 -0400 (EDT) Received: by wx-out-0102.google.com with SMTP id t5so385228wxc for ; Thu, 22 Jun 2006 10:17:33 -0700 (PDT) Received: by 10.70.110.18 with SMTP id i18mr3484207wxc; Thu, 22 Jun 2006 10:17:33 -0700 (PDT) Received: by 10.70.30.3 with HTTP; Thu, 22 Jun 2006 10:17:33 -0700 (PDT) Message-ID: Date: Thu, 22 Jun 2006 19:17:33 +0200 From: "Milosz Derezynski" To: "Frans Englich" Subject: Re: MLQ (Media Library Query) file format and mime type proposal In-Reply-To: <200606221419.00204.frans.englich@telia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8538_10618378.1150996653355" References: <200606221419.00204.frans.englich@telia.com> X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Status: No, score=-2.272 tagged_above=-999 required=2 tests=[AWL=0.327, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] X-Spam-Score: -2.272 X-Spam-Level: Cc: xdg@lists.freedesktop.org, gnome-multimedia@gnome.org X-BeenThere: gnome-multimedia@gnome.org X-Mailman-Version: 2.1.8 Precedence: list List-Id: GNOME Multimedia development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2006 17:17:35 -0000 ------=_Part_8538_10618378.1150996653355 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/22/06, Frans Englich wrote: > > On Thursday 22 June 2006 09:25, Milosz Derezynski wrote: > > I think this highlights possible trouble. Anyone else who decides to > invent "query" will get detected as "Media Library Query List". All that's > needed to fix this is to use URIs properly. > I've changed the file magic so that the first line has to be "#MLQ", and our MLQ exporter writes them like that and recognizes them only like that, and i've updated the mime XML spec to recognize them this way. This is no better or worse than "#EXTM3U" for .m3u playlists, so i don't think there is any problem here now. As for the URIs themselves, i wasn't yet speaking of "open" use of them (outside of .mlq files), but only within them, so this change of the file magic should prevent problems with anything else that might use a query:/// URI in their file formats. -- Milosz ------=_Part_8538_10618378.1150996653355 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 6/22/06, Frans Englich <frans.englich@telia.com> wrote:
On Thursday 22 June 2006 09:25, Milosz Derezynski wrote:

I think this highlights possible trouble. Anyone else who decides to
invent "query" will get detected as "Media Library Query List". All that's
needed to fix this is to use URIs properly.

I've changed the file magic so that the first line has to be "#MLQ", and our
MLQ exporter writes them like that and recognizes them only like that, and i've
updated the mime XML spec to recognize them this way.  This is no better or worse than
"#EXTM3U" for .m3u playlists, so i don't think there is any problem here now.
As for the URIs themselves, i wasn't yet speaking of "open" use of them (outside of .mlq files),
but only within them, so this change of the file magic should prevent problems with
anything else that might use a query:/// URI in their file formats.

-- Milosz
------=_Part_8538_10618378.1150996653355--