Re: [gfvs] cdda backend

[Alexander Larsson]

So, I thought some more about the content type guessing. The current
code allows you to read files from all sorts of backends, and enumerate
the various places you can read from (volume monitor), if you add to
this a content type and a way to get at the lowlevel identifiers for the
volumes (so that you can optionally map them to other libraries and get
more details) this is quite powerful for many apps.

However, I'm not sure its the right place the actual content type
guessing API. Lets take a step back and consider the whole desktop. Any
time you mount something you want to guess the content on that so that
you can spawn the default operation. Another user of the content type
would be the f-spot photo import dialog, which would default to only
show photo type devices and mounts. However, at this points its not
ideal to have to start sniffing all the mounts before bringing up the
dialog, as that is kinda slow.

So, it seems to me, that the ideal approach is to sniff content types
each time something is mounted, and to remember that for further
(cross-process) use. And a good place to put the sniffing would be where
the open default content action guessing happens. 

I'm not sure where/how to store this though, as its a per-session thing
really (some mounts are session local, and session settings might affect
the results), and hal is system wide.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [gfvs] cdda backend

[Alexander Larsson]

On Wed, 2007-12-19 at 16:43 -0500, David Zeuthen wrote:

   I'm thinking this can also be used for the favorite servers like we
   have today in gnome-vfs; e.g. we just implement a volume monitor that
   creates GVolume objects that matches a list in gconf. Then when the
   mount is actually created the volume monitor adopts the DaemonMount in
   it's adopt_orphan_mount() function.
 
 Btw, is this how we should implement it? Or did you have anything else
 in mind? I really miss my public_html @ p.fd.o link that comes up
 automatically - I use it a lot when doing screen shots to share. 
 
 I think if we do the feature this way (a gvfs module that links in
 gconf) it can be written in a day or less.

Well, Its certainly a good way to implement connect to server as it
existed before. However, the question is whether this is the best design
in the new gio world. In the pre-gio world there were no mounts for a
remote share like your example, so it didn't appear anywhere. Connect to
server was added to sort of make it into a mount. But in the new world
we actually have a mount object, so the need to make it look like there
is a mount is gone. 

However, as you say this is used for another thing, namely easy access
to the share. In the gio world this would mean having a GVolume for the
GMount so that it is easy to mount. At the very least this would involve
changing how connect to server is exposed in the UI and what it is
called. There is also how it relates to bookmarks, which is another
not-quite-the-same way to quickly get to places.

So, I guess the question is, in what way is it better to have
public_html @ p.fd.o be a volume than using a bookmark for this?

  So, can there never be a situation where the GMount gets created before
  the corresponding GVolume object is? And in that case, how does the
  GVolume locate the mount?
 
 That's a good question; it's not supported in the API yet because that
 situation can never happen for the use I wrote it for (cdda:// backend).
 
 How about a another vtable entry in the GVolumeMonitor
 
  gboolean (*request_adoption_of_orphan_mount) (GVolume *adopter,
GMount *orphan);
 
 that each implementation can implement? Alternatively we can put this
 method on the GMount interface but that seems wrong since it's only
 something volume monitors would ever want to do.

The volume monitor would recurse over all volumes and call this?

Isn't it better to have something like: 

 GMount * (*find_orphan_mount_for_adoption) (GVolumeMonitor *monitor,
 GVolume *adopter)
 

   Other thoughts / questions about the API
   
- Busy mounts. Right now the cdda:// backend refuses to unmount
  if there are open files on it. I think that's probably the right
  thing to do for any backend. 
 
 Btw, what are you thoughts about this? I feel strongly this is the right
 thing to do .. otherwise you can lose data.
 
 I'd even go as far and say that the GVfsBackend base class should
 automatically return G_IO_ERROR_BUSY on unmount() when there are pending
 jobs. At least that would be the default unmount() operation unless you
 override it.

Sure, thats probably a good thing.

- Further, if a mount can't be unmounted because it's busy (and
  we can't avoid that since we support mounts backed by kernel
  drivers), we probably want something like lsof(8) that Nautilus
  and other stuff can use to put up a dialog showing what apps
  is blocking the unmount. How about a list_open_files() method
  on GMount() that returns an array of
   - process id (is that portable? maybe need an abstraction)
   - icon
   - name
   - etc.
  Would need backend support for this too.
  
  Now we're getting into really lowlevel bizarro things. I don't think we
  should really expose this in a generic API. Can't this just be reported
  in the error message for the G_IO_ERROR_BUSY error when unmounting.
  
  I.E. the error dialog would say Cannot unmount, because firefox (pid
  35) is keeping files open on the volume, or Cannot unmount, because 13
  applications are keeping open files on the volume.. Maybe in the last
  case we should at least give the name (and pid?) of one application so
  that you can make progress on unmount by killing that.
 
 Right, I definitely think we want the dialog to look something like this
 
  +---+
  | Cannot unmount public_html @ p.fd.o, the following  |
  | applications are still using it   |
  |   |
  | [icon] GEdit - Secret Stuff.txt[kill] |
  | [icon] GEdit - My Diary.txt[kill] |
  | [icon] Tomboy  [kill] |
  | [icon] /bin/cat[kill] |
  |   |
  | 

Re: [gfvs] cdda backend

[Alexander Larsson]

On Wed, 2007-12-19 at 16:43 -0500, David Zeuthen wrote:
 Hi again,
 
 Almost more questions than answers this time, sorry. Also no patch
 either since I wanted to hear your thoughts before doing the work.
  it's not supported in the API yet because that
 situation can never happen for the use I wrote it for (cdda:// backend).

I added the unmount flags to all unmount and eject calls and the remount
operation to GMount.

All users are fixed up, but nothing implements these yet.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [gfvs] cdda backend

[David Zeuthen]

On Thu, 2007-12-20 at 12:54 +0100, Alexander Larsson wrote:
 On Wed, 2007-12-19 at 16:43 -0500, David Zeuthen wrote:
  Hi again,
  
  Almost more questions than answers this time, sorry. Also no patch
  either since I wanted to hear your thoughts before doing the work.
   it's not supported in the API yet because that
  situation can never happen for the use I wrote it for (cdda:// backend).
 
 I added the unmount flags to all unmount and eject calls and the remount
 operation to GMount.
 
 All users are fixed up, but nothing implements these yet.

Great, thanks. I'll add this to the unix and hal backends.

Cheers,
David


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [gfvs] cdda backend

[David Zeuthen]

On Thu, 2007-12-20 at 11:57 +0100, Alexander Larsson wrote:
 So, I guess the question is, in what way is it better to have
 public_html @ p.fd.o be a volume than using a bookmark for this?

I suppose either works; it was just an idea. The main advantage is that
the icon for the volume wouldn't jump around (bookmarks IIRC are stored
below a separator line in the file chooser and sidebar) if you double
click it in the file chooser. I think bookmarks are more intended for
files or folders? I don't know.

   gboolean (*request_adoption_of_orphan_mount) (GVolume *adopter,
 GMount *orphan);
  
  that each implementation can implement? Alternatively we can put this
  method on the GMount interface but that seems wrong since it's only
  something volume monitors would ever want to do.
 
 The volume monitor would recurse over all volumes and call this?
 
 Isn't it better to have something like: 
 
  GMount * (*find_orphan_mount_for_adoption) (GVolumeMonitor *monitor,
  GVolume *adopter)

Actually with the proposal I had, the adoptor itself would iterate over
all mounts and use it's own criteria of how to pick an orphan - it's
probably in a better position to choose than the orphan's volume
monitor? I mean, suppose we did fav servers as a GVolume stemming from
a fav servers volume monitor; how would GDaemonVolumeMonitor know how
to pick adopter? 

(OTOH, the fav servers volume monitor backend would have no problem
picking the orphan; it would just compare the get_mount_root() from each
GMount on the system with whatever preferences it relies on)

stuff about busy unmount dialog

 I really think you are overreacting a bit on this. For regular unix
 mounts it is often the case that you get stuck with busy mounts, because
 applications with cwd inside the mount keep it open, or due to a dnotify
 watch. However, for gvfs mounts the only time something is busy is if
 there is actually an ongoing operation like a file copy, loading a file
 or something like that. This is far less likely to happen when you
 unmount a volume, and its far easier to be aware of this (for instance
 you'd have a copy file progress notification icon for the file copy, or
 just loading a file in gedit).

 Furthermore, since we can make sure we can succeed 100% with a forced
 unmount, having a blunt instrument like killing an application that is
 doing an operation on the volume seems like the wrong thing to do. I
 can't think of any reason you'd want to do this instead of forcefully
 unmounting and have the apps doing the operation get an i/o error.
 
 So, adding this chunk of lowlevel weird stuff (where you have to expose
 nonportable things like pids, etc) to the supported portable highlevel
 API for this very rare case that we can handle well with a force unmount
 anyway seems like a bad idea.
 
 Now, maybe you're thinking of using this for unmounting in the hal
 backend were we're talking about unmounting unix filesystems, which do
 not support a nice force unmount and are more likely to be busy. Yes,
 this is more of a problem, but do we really need to expose the
 implementation of lsof in the highlevel API. Isn't it better to just
 encapsulate the whole thing (dialog/widget + getting the data for it) in
 a single call.

Sure, we can do that as well (putting the calls to lsof(8) into the code
creating the dialog). It just seems like a waste to not abstract this
stuff out. There's GPid in glib already so am not sure why this isn't
portable (list_open_files() would be allowed to error out with
G_IO_ERROR_NOT_SUPPORTED of course).

Btw, I wouldn't be so sure about busy mounts; what if you keep you
media collection on a networked share? People are working on moving
people's documents and media off the client and on to hosted storage
services; it seems we'll be getting more of this. (And you can cwd into
~/.gvfs too but I agree that is not so common).

  stuff about volume monitoring

 If you want to extend this goal, you need to describe exactly what is
 the target of the new API. What should you be able to do with it, and
 what not. Then we can discuss how this is best achieved.

Sure, in addition from the gio volume monitoring just being a utility
library to be used by the file manager and file chooser, I'd like it to
be useful for other things.

First is auto mounters like e.g. gnome-volume-manager. This is necessary
because some file systems for devices like cameras and audio cd's are
not handled by hal (e.g. cdda:// and gphoto2://). So the auto mounter
needs to at least pay attention to the volume monitor to mount a gphoto2
camera and a cdda disc.

The other thing the auto mounter does is prompt the user for what
application to run when media with well-known content is inserted (cf.
this http://people.freedesktop.org/~david/g-v-m-prefs.png ). Hence you
need to have an idea of what could be on the media - similar to
the similar to 

Re: [gfvs] cdda backend

[Alexander Larsson]

On Thu, 2007-12-20 at 10:45 -0500, David Zeuthen wrote:
 On Thu, 2007-12-20 at 11:57 +0100, Alexander Larsson wrote:
  So, I guess the question is, in what way is it better to have
  public_html @ p.fd.o be a volume than using a bookmark for this?
 
 I suppose either works; it was just an idea. The main advantage is that
 the icon for the volume wouldn't jump around (bookmarks IIRC are stored
 below a separator line in the file chooser and sidebar) if you double
 click it in the file chooser. I think bookmarks are more intended for
 files or folders? I don't know.

Bookmarks are for folders (you get default bookmarks for things like the
photos folder, etc). 

I'm not saying I know what is best, just that its not obvious what the
best route is.

gboolean (*request_adoption_of_orphan_mount) (GVolume *adopter,
  GMount *orphan);
   
   that each implementation can implement? Alternatively we can put this
   method on the GMount interface but that seems wrong since it's only
   something volume monitors would ever want to do.
  
  The volume monitor would recurse over all volumes and call this?
  
  Isn't it better to have something like: 
  
   GMount * (*find_orphan_mount_for_adoption) (GVolumeMonitor *monitor,
   GVolume *adopter)
 
 Actually with the proposal I had, the adoptor itself would iterate over
 all mounts and use it's own criteria of how to pick an orphan - it's
 probably in a better position to choose than the orphan's volume
 monitor? I mean, suppose we did fav servers as a GVolume stemming from
 a fav servers volume monitor; how would GDaemonVolumeMonitor know how
 to pick adopter? 

Hmm, i guess. But how can the fav server volume monitor iterate over all
mounts? It doesn't see other volume monitors.

 Sure, we can do that as well (putting the calls to lsof(8) into the code
 creating the dialog). It just seems like a waste to not abstract this
 stuff out. There's GPid in glib already so am not sure why this isn't
 portable (list_open_files() would be allowed to error out with
 G_IO_ERROR_NOT_SUPPORTED of course).

Well, any time you expose an abstraction like this you limit both how
the backend can work, and what details you can show in the dialog. Plus
you add more stuff to the API that most people really don't need.

What would list_open_files() returns? A list of a new kind of GObject?

 Btw, I wouldn't be so sure about busy mounts; what if you keep you
 media collection on a networked share? People are working on moving
 people's documents and media off the client and on to hosted storage
 services; it seems we'll be getting more of this. (And you can cwd into
 ~/.gvfs too but I agree that is not so common).

You mean while the player plays a media file it would be busy. I guess
thats not to uncommon. pwds in ~/.gvfs don't keep the GVfs busy, as
~/.gvfs is just a single mount.

 The rationale for the patch is to
 
  - define what could be on the media means (x-content/*)
  - unify all sniffing code into a single place
- likely pluggable so 3rd party libs (like libipoddevice), that
  actually handle dealing with the device in question, can
  participate
  - involves name and icon selection too
  - encourage people to use (and write) gvfs backends instead of using
Linux/UNIX-only libraries in their apps thus rendering non-portable
 
 Because, right now, it's a mess and every app (including the auto
 mounter) does their own thing. The result, as you can see from the
 screenshots, is that things not only look different, the names are
 different too. (and ideally, there would be a stock select_media
 dialog where you pass one or more x-content/* identifiers.)

Sounds like a good reason.

 Of course, it's fine if this is not a goal for gio but then volume
 monitor API of gio isn't really useful outside the file manager and the
 file chooser and should perhaps be private API instead.

I just want to make sure we don't add something that apps can't use that
we have to support forever. We need to make sure all APIs are right,
sane and useful. I'm tired of maintaining big-bag-of-crap libraries...

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [gfvs] cdda backend

[David Zeuthen]

On Thu, 2007-12-20 at 17:10 +0100, Alexander Larsson wrote:
 Hmm, i guess. But how can the fav server volume monitor iterate over all
 mounts? It doesn't see other volume monitors.

It would use the union monitor through the standard volume monitor API?

 What would list_open_files() returns? A list of a new kind of GObject?

Yeah, I think.

  Because, right now, it's a mess and every app (including the auto
  mounter) does their own thing. The result, as you can see from the
  screenshots, is that things not only look different, the names are
  different too. (and ideally, there would be a stock select_media
  dialog where you pass one or more x-content/* identifiers.)
 
 Sounds like a good reason.

I'll try to iterate over the patch. Thanks for considering!

  Of course, it's fine if this is not a goal for gio but then volume
  monitor API of gio isn't really useful outside the file manager and the
  file chooser and should perhaps be private API instead.
 
 I just want to make sure we don't add something that apps can't use that
 we have to support forever. We need to make sure all APIs are right,
 sane and useful. I'm tired of maintaining big-bag-of-crap libraries...

Yeah. I'll try to be preemptive and raise the idea of x-content/* on the
xdg lists. That's one thing we want standardized...

 David


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [gfvs] cdda backend

[Alexander Larsson]

On Wed, 2007-12-19 at 00:58 -0500, David Zeuthen wrote:
 Hi,
 
 Here's a new set of patches
 
 http://people.freedesktop.org/~david/gio-4.patch
 http://people.freedesktop.org/~david/gvfs-4.patch
 http://people.freedesktop.org/~david/nautilus-4.patch
 
 There's a description in ChangeLog and comments below

I commited this with some small changes:
Renamed fuse_name to stable_name
Remove unused GVolumeMonitor *union_monitor added to GHalVolumeMonitor.

 OK, I've fixed this. Was simply a typo where the value was used instead
 of the key in g_hash_table_remove().

Sweet.

  I don't see an obvious easy solution. It requires some work. The ideal
  thing to match with is an GMountSpec (which is basically the set of
  key-value pairs that define a gvfs mount). For a GDaemonMount this is
  availible in the GMountInfo object.
  
  Thats a gvfs-specific object though, so we can't make that availible in
  the base GVolume apis. What if we add some new vtable calls in
  GVolumeMonitor like find_volume_for_new_mount() and
  find_mount_for_new_volume() which we have GUnionVolumeMonitor call on
  the installed backends when new, unowned volume/mounts are added.
 
 I think I've come up with a pretty nice solution; see the new function
 g_volume_monitor_adopt_orphan_volume() in the gio patch. 
 
 I'm thinking this can also be used for the favorite servers like we
 have today in gnome-vfs; e.g. we just implement a volume monitor that
 creates GVolume objects that matches a list in gconf. Then when the
 mount is actually created the volume monitor adopts the DaemonMount in
 it's adopt_orphan_mount() function.

So, can there never be a situation where the GMount gets created before
the corresponding GVolume object is? And in that case, how does the
GVolume locate the mount?

 Other thoughts / questions about the API
 
  - Busy mounts. Right now the cdda:// backend refuses to unmount
if there are open files on it. I think that's probably the right
thing to do for any backend. Probably means we need to add flags
to the unmount() calls; the flags used in Linux, e.g.
 - force unmount
 - lazy unmount
comes to mind.

While I can sort of see the usecases for these, aren't we sort of
overcomplicating the API here? Is this really required? When and how
would the user force unmount or lazy unmount something? (Or the reverse,
if there is a case for one of these when should we not do it.)

  - Further, if a mount can't be unmounted because it's busy (and
we can't avoid that since we support mounts backed by kernel
drivers), we probably want something like lsof(8) that Nautilus
and other stuff can use to put up a dialog showing what apps
is blocking the unmount. How about a list_open_files() method
on GMount() that returns an array of
 - process id (is that portable? maybe need an abstraction)
 - icon
 - name
 - etc.
Would need backend support for this too.

Now we're getting into really lowlevel bizarro things. I don't think we
should really expose this in a generic API. Can't this just be reported
in the error message for the G_IO_ERROR_BUSY error when unmounting.

I.E. the error dialog would say Cannot unmount, because firefox (pid
35) is keeping files open on the volume, or Cannot unmount, because 13
applications are keeping open files on the volume.. Maybe in the last
case we should at least give the name (and pid?) of one application so
that you can make progress on unmount by killing that.

  - Mount options. Do we need this? At least for std file systems
such as vfat and ntfs people still use it at least judging from
bug reports. There's actually (very horrible) UI in gnome-mount for
 this crap
 
  http://people.freedesktop.org/~david/gm-prop/gm-prop2.png
 
I don't know; maybe that's specific to each gvfs backend and the hal
volume monitor. Ideally I want to ditch gnome-mount and just make the
hal volume monitor call directly into HAL.

I do believe we want some form of mount options. For instance, a very
common request is to be able to specify the filename encoding of e.g. a
ftp share. 

However, I don't think the right place for this is as API arguments for
the mount call. Instead i think these are more like preferences for each
mount point, that we can store somewhere and that gvfs automatically
picks up each time you mount that particular share.

I haven't sat down and worked out all the details about this though.

  - g_file_read() and g_file_read_async() probably needs to take a
GFileReadFlags value. See my other mail about the cdda:// backend
in this thread.

pasted here:

  - have an operation on GInputFileStream to set/clear flags.
 
 Am unsure whether there should be a dedicated SKIP_SCRATCHED_AREA flag
 or whether it should overload a standard one. We should probably also
 default to !SKIP_SCRATCHED_AREA.
 
 Now, common sense dictates that it's probably not alright to add such
 public API to gio with the cdda:// backend 

Re: [gfvs] cdda backend

[David Zeuthen]

Hi again,

Almost more questions than answers this time, sorry. Also no patch
either since I wanted to hear your thoughts before doing the work.

On Wed, 2007-12-19 at 11:43 +0100, Alexander Larsson wrote:
 I commited this with some small changes:
 Renamed fuse_name to stable_name
 Remove unused GVolumeMonitor *union_monitor added to GHalVolumeMonitor.

Great, thanks!

  I'm thinking this can also be used for the favorite servers like we
  have today in gnome-vfs; e.g. we just implement a volume monitor that
  creates GVolume objects that matches a list in gconf. Then when the
  mount is actually created the volume monitor adopts the DaemonMount in
  it's adopt_orphan_mount() function.

Btw, is this how we should implement it? Or did you have anything else
in mind? I really miss my public_html @ p.fd.o link that comes up
automatically - I use it a lot when doing screen shots to share. 

I think if we do the feature this way (a gvfs module that links in
gconf) it can be written in a day or less.

 So, can there never be a situation where the GMount gets created before
 the corresponding GVolume object is? And in that case, how does the
 GVolume locate the mount?

That's a good question; it's not supported in the API yet because that
situation can never happen for the use I wrote it for (cdda:// backend).

How about a another vtable entry in the GVolumeMonitor

 gboolean (*request_adoption_of_orphan_mount) (GVolume *adopter,
   GMount *orphan);

that each implementation can implement? Alternatively we can put this
method on the GMount interface but that seems wrong since it's only
something volume monitors would ever want to do.

  Other thoughts / questions about the API
  
   - Busy mounts. Right now the cdda:// backend refuses to unmount
 if there are open files on it. I think that's probably the right
 thing to do for any backend. 

Btw, what are you thoughts about this? I feel strongly this is the right
thing to do .. otherwise you can lose data.

I'd even go as far and say that the GVfsBackend base class should
automatically return G_IO_ERROR_BUSY on unmount() when there are pending
jobs. At least that would be the default unmount() operation unless you
override it.

 Probably means we need to add flags
 to the unmount() calls; the flags used in Linux, e.g.
  - force unmount
  - lazy unmount
 comes to mind.
 
 While I can sort of see the usecases for these, aren't we sort of
 overcomplicating the API here? Is this really required? When and how
 would the user force unmount or lazy unmount something? (Or the reverse,
 if there is a case for one of these when should we not do it.)

   - Further, if a mount can't be unmounted because it's busy (and
 we can't avoid that since we support mounts backed by kernel
 drivers), we probably want something like lsof(8) that Nautilus
 and other stuff can use to put up a dialog showing what apps
 is blocking the unmount. How about a list_open_files() method
 on GMount() that returns an array of
  - process id (is that portable? maybe need an abstraction)
  - icon
  - name
  - etc.
 Would need backend support for this too.
 
 Now we're getting into really lowlevel bizarro things. I don't think we
 should really expose this in a generic API. Can't this just be reported
 in the error message for the G_IO_ERROR_BUSY error when unmounting.
 
 I.E. the error dialog would say Cannot unmount, because firefox (pid
 35) is keeping files open on the volume, or Cannot unmount, because 13
 applications are keeping open files on the volume.. Maybe in the last
 case we should at least give the name (and pid?) of one application so
 that you can make progress on unmount by killing that.

Right, I definitely think we want the dialog to look something like this

 +---+
 | Cannot unmount public_html @ p.fd.o, the following  |
 | applications are still using it   |
 |   |
 | [icon] GEdit - Secret Stuff.txt[kill] |
 | [icon] GEdit - My Diary.txt[kill] |
 | [icon] Tomboy  [kill] |
 | [icon] /bin/cat[kill] |
 |   |
 |  [Cancel] |
 +---+
 (dunno what icon / wording to use for [kill] though. Maybe
  there could also be a [switch to] button that dismisses
  the dialog (or not?) and takes you to the application)

Stuffing all these details into the GError doesn't seem at all
reasonable. So I think a simple g_mount_list_open_files() function is
what we need (need an async function too).

Anyway, In fact, I think we want such a dialog in the next gtk+
release: 

GtkWidget *gtk_io_unmount_busy_dialog_new 

Re: [gfvs] cdda backend

[David Zeuthen]

On Wed, 2007-12-19 at 16:43 -0500, David Zeuthen wrote:
 Another thought: we probably need a way to learn more about the GDrive,
 GVolume and GMount objects than just their names and icons. First, cf.
 the network applet use, we need to know if the mount is networked or not
 and if it is, what hostname is it using. Simple proposal

Attached are some unfinished patches that illustrate this idea; notes

 - flags are replaced by textual strings (notice the resemblance to mime
   types?)
 - content sniffing happens in a thread when done async
 - no actual sniffing is done; should be trivial to add though
 - needs work in the drive classification bits.

 - There's some other stuff I wanted to propose regardless of this
   - get_id() on GDrive,Volume,Mount: needed to pass these around
   - model,vendor on GDrive; some apps (notably the cd burner ones) will
 need this for user selection when having multiple drives

Anyway, with this patch it should be simple to abuse the .desktop file
format and add something x-content/video to e.g. Totem's and mplayer's
desktop files. Then we can easily add machinery to the Preferred
Applications capplet for choosing the default video player and we can
finally get rid of this ugly entry boxes

 http://people.freedesktop.org/~david/g-v-m-prefs.png

Ditto for the other x-content/* formats. This is a problem we haven't
been able to solve for three years...

If you like this idea, here are the next steps I'm going to do

 - Finish the patch
 - Propose x-content/* and x-drive/* types as a fd.o spec on xdg-list
 - Make the directory sniffing code plug-in based
   (I expect we want to update this code rather frequently, it's a
bit like shared-mime-info)

Anyway, the whole idea may be crack (I don't think so though), but you
can't accuse me of not thinking in a user document centric way with
this :-)

  David

Index: gunixmount.c
===
--- gunixmount.c	(revision 6163)
+++ gunixmount.c	(working copy)
@@ -178,6 +178,14 @@
 }
 
 static char *
+g_unix_mount_get_id (GMount *mount)
+{
+  GUnixMount *unix_mount = G_UNIX_MOUNT (mount);
+  
+  return g_strdup (unix_mount-mount_path);
+}
+
+static char *
 g_unix_mount_get_name (GMount *mount)
 {
   GUnixMount *unix_mount = G_UNIX_MOUNT (mount);
@@ -393,6 +401,7 @@
 {
   iface-get_root = g_unix_mount_get_root;
   iface-get_name = g_unix_mount_get_name;
+  iface-get_id = g_unix_mount_get_id;
   iface-get_icon = g_unix_mount_get_icon;
   iface-get_uuid = g_unix_mount_get_uuid;
   iface-get_drive = g_unix_mount_get_drive;
Index: gdrive.c
===
--- gdrive.c	(revision 6163)
+++ gdrive.c	(working copy)
@@ -146,13 +146,35 @@
 }
 
 /**
+ * g_drive_get_id:
+ * @drive: a #GDrive.
+ * 
+ * Get an opaque textual identifier that can be used to pass a
+ * reference to @drive between processes.
+ *
+ * Returns: a string containing @drive's id. The returned string
+ * should be freed when no longer needed.
+ **/
+char *
+g_drive_get_id (GDrive *drive)
+{
+  GDriveIface *iface;
+
+  g_return_val_if_fail (G_IS_DRIVE (drive), NULL);
+
+  iface = G_DRIVE_GET_IFACE (drive);
+
+  return (* iface-get_id) (drive);
+}
+
+/**
  * g_drive_get_name:
  * @drive: a #GDrive.
  * 
  * Gets the name of @drive.
  *
- * Returns: a string containing @drive's name. The returned 
- * string should be freed when no longer needed.
+ * Returns: a string containing @drive's name. The returned string
+ * should be freed when no longer needed.
  **/
 char *
 g_drive_get_name (GDrive *drive)
@@ -167,6 +189,50 @@
 }
 
 /**
+ * g_drive_get_vendor:
+ * @drive: a #GDrive.
+ * 
+ * Gets the vendor of @drive.
+ *
+ * Returns: a string containing @drive's vendor or %NULL if no such
+ * name could be found. The returned string should be freed when no
+ * longer needed.
+ **/
+char *
+g_drive_get_vendor (GDrive *drive)
+{
+  GDriveIface *iface;
+
+  g_return_val_if_fail (G_IS_DRIVE (drive), NULL);
+
+  iface = G_DRIVE_GET_IFACE (drive);
+
+  return (* iface-get_vendor) (drive);
+}
+
+/**
+ * g_drive_get_model:
+ * @drive: a #GDrive.
+ * 
+ * Gets the model of @drive.
+ *
+ * Returns: a string containing @drive's model or %NULL if no such
+ * name could be found. The returned string should be freed when no
+ * longer needed.
+ **/
+char *
+g_drive_get_model (GDrive *drive)
+{
+  GDriveIface *iface;
+
+  g_return_val_if_fail (G_IS_DRIVE (drive), NULL);
+
+  iface = G_DRIVE_GET_IFACE (drive);
+
+  return (* iface-get_model) (drive);
+}
+
+/**
  * g_drive_get_icon:
  * @drive: a #GDrive.
  * 
@@ -468,5 +534,65 @@
   return (* iface-poll_for_media_finish) (drive, result, error);
 }
 
+/**
+ * g_drive_get_classification:
+ * @drive: a #GDrive.
+ *
+ * A #GDrive is an abstraction of a storage device connected to the
+ * system. As many popular consumer electronic devices, such as
+ * phones, music and video players, GPS devices and so on appear to
+ * the operating 

Re: [gfvs] cdda backend

[Alexander Larsson]

On Sun, 2007-12-16 at 18:22 -0500, David Zeuthen wrote:

 So I wrote the attached cdda module because with gio/gvfs I think it
 actually makes sense have a cdda:// backend (also, and sorry for
 sounding like a cargo cult follower, to have feature parity with Mac OS
 X and Windows). And I also wanted to get a feel / help review the plugin
 API before we freeze. 

I'm not convinced this is what people want (over launching e.g.
sound-juicer or gnome-cd when clicking on the audio disc icon), but lets
add it, it doesn't hurt.

 First, a small feature list
 
  - Stateful mounts; yes, you actually mount the cdda gvfs filesystem
driver; there's one instance of gvfsd-cdda per mount. You also have
to mount the fs manually: gvfs-mount cdda://sr0

You don't actually have to make each cdda mount its own process. If you
want you can add a well-known dbus name to the cdda.mount.in file (which
is missing from your patch btw). gvfsd will hand off cdda mount
operations to that name if it exists, instead of spawning a new copy.

  - Works with multiple clients at the same time as well as when
a iso9660 filesystem is mounted by a kernel driver. There's seeking
and it's a bit slow (can be alleviated once we introduce readahead
in the GVfsBackend base class, yes?) but basically works very well

Readahead is mainly gonna speed up the case where an app does
read_source()
write_destination()
read_source()
write_destingation()
...

I.e. while it blocks writing what it just read we can automatically
schedule a read from the source so that the next read will finish
faster. Its not really related to seeks.

  1. The GVfs FUSE daemon never class close() on my fs backend when
 it's done reading.. this leads to leaks. Have you seen this?

The fuse daemon is mainly the work of hans petter. I haven't really
looked into it or tried it that much.

  2. I have to set GMountSpec in try_mount(); it's not enough just
 setting it in do_mount(). Bug?

Yes, that shouldn't happen. Can you try to look into this?

  3. Once mounted, there's no way for the backend to change it's display
 name. I think I understand why you did this; it's because of the
 FUSE daemon right? E.g. you want to ensure that there are no
 name collisions to make it easier to figure out what directories
 to return in ~/.gvfs ...
 
 Anyway, the reason we want this is that initially we probably want
 the display name Audio Disc and if we (much later) acquire meta
 data for the disc we want to change it to Tori Amos - Silent
 all these years or whatever the title is.
 
 (same applies for the icon (think cover art); I haven't tested if
  this doesn't work)

Hmmm. Tricky. Its kinda weird having the name of the actual mountpoint
change. Especially with it being the identifier for the mount in the
fuse case. I think the best solution is to have the volume be called
_(Audio Disc), but then set the display name of the root of the disk
to the actual disk title. Thats what will be displayed in many places
like the window title for the toplevel directory.

  4. There's very little in way of documentation so it was really
 confusing to start writing the backend. Once I got the hang of
 it, it was a smooth ride though.

Well, gvfs is still kinda raw and not at the same state of polish as
gio. On the other hand, its not all that complex once you get the hang
of it (except some internal details).

  5. There needs to be a way to associate a GDaemonMount to an existing
 GVolume object (stemming from the HAL volume monitor). This is
 not a problem inherent to the CDDA backend; it applies to any
 backend that provides a user space file system driver for a block
 device (e.g. NTFS, secure paranoid vfat etc.).
 
 The first problems are probably easily fixable; the last one is more
 problematic. Here's how I envision it will work
 
 User inserts audio disc into drive. The HAL volume monitor notices this
 and creates a GVolume object representing the unmounted audio disc. The
 mount() method on the HAL volume monitor for said GVolume will simply do
 the equivalent of
 
  $ gvfs-mount cdda://sr0

(This is just g_file_mount_enclosing_volume)

 since it knows there a cdda:// backend already. So when this happens the
 gvfs-cdda backend is started for sr0 and as a result a GDaemonMount is
 created in the process space of all gvfs clients using volume monitoring
 (via GDaemonVolumeMonitor). Now, I think all we need to do is
 
  o  Make the GHalVolume live object for sr0 note that the
 new GDaemonMount object was created and associate with it (e.g.
 take a weak ref and emit changed. Future calls into get_mount()
 for the GHalVolume will return that ref).
 
  o  Have a way for the gvfsd-cdda backend to tell that the created
 GDaemonMount objects representing it needs to make get_volume()
 on them return a reference to the GHalVolume object.
 
 This all sounds complicated but I'm not sure it 

Re: [gfvs] cdda backend

[Ross Burton]

On Sun, 2007-12-16 at 18:22 -0500, David Zeuthen wrote:
  - Puts RIFF tags in the .wav files containing metadata; though no
metadata framework is currently hooked up (I tried experimentally
hooking up s-j's libjuicer and it works very well; unfortunately
that library is pulling in gtk, gnome-vfs, gconf... Ross?)

A total rewrite of Sound Juicer is on my to do list, but as my current
laptop doesn't have a CD drive progress has been slow. ;)  One of the
goals has been to ensure that the low-level libraries don't require GTK+
at all.  That said, metadata is tricky.

- CD-Text.  I've yet to see a commercial CD with CD-Text support
- FreeDB: useless.  The commercial servers are good (cf iTunes), but
freedb is a waste of space.  [this is where I get flamed]
- Musicbrainz.  Yes, libmusicbrainz is dead.  However, long live
libmusicbrainz!  There is a new API to the musicbrainz server which
resulted in a far saner library and I have a prototype patch to hook it
into libjuicer.

I have a plan, it just needs doing.  Volunteers to help gut and
reconstruct Sound Juicer welcome. :)

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [gfvs] cdda backend

[Alexander Larsson]

On Mon, 2007-12-17 at 10:42 +, Bastien Nocera wrote:
   - file manager not a good UI for ripping songs; better to launch
 the cd player
 
 That's still current.

I think this is the main issue here. There are technical aspects, yes
(as noted in your mail), but those are all secondary. The primary
question is, what is a good way for a desktop to support playing and
ripping audio CDs such that its powerful and easy to use. I think
pretending they are wavs succeed in neither of these.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [gfvs] cdda backend

[David Zeuthen]

On Mon, 2007-12-17 at 10:42 +, Bastien Nocera wrote:
  It seems the main objections to that new cdda module for gnome-vfs were
  
   - would pull gstreamer into the client apps 
 
 Which client app would want to deal with audio CD data without pulling
 in some sort of multimedia framework?

The problem, AFAIK, was that *any* application linking in
libgnome-vfs.so would pull in gstreamer. I understood from Alex's second
reply that was the main problem.

   - file manager not a good UI for ripping songs; better to launch
 the cd player
 
 That's still current.

I'm not suggesting to change that.

  However, that ignores several fundamental problems
  
   - libcdio / libparanoia isn't the API application programmers
 should use (however, gio is)
 
 GStreamer is, to deal with sound data.

Sure, and I agree we should all be using GStreamer and all the apps we
all use should be using it. But a number apps still don't and there are
multiple competing frameworks etc. Then again, a lot of us (and our
technical users) run command line tools and it's just damn handy to have
the PCM data available in ~/.gvfs.

 How will you export the (very as-hoc) errors from the underlying
 libraries? 

We could return G_IO_ERROR_SCRATCHED and have the app do the moral
equivalent of an ioctl() on the GFile to set the retries. But I think
that's crazy and I'm not sure apps want to deal with error handling
_anyway_ so hiding it in the backend is fine (other fs drives don't do
this). 

I think instead the backend just skips over the scratched area and puts
up a libnotify notification (or other out-of-band signal) to notify the
user it's skipping over the scratched area (that's how DVD Player in Mac
OS X 10.5 does it)

 How do you export the MusicBrainz Disc ID, or FreeDB one?

As metadata in the WAV container (see the patch for details; search for
Jailhouse; it's fine, we can choose another container for the PCM data
if you want (AIFF?)

 I think that's a bad idea. And it eats the cdda:/ MRL space for
 GStreamer.

I'm not sure these namespaces are similar anyway.

  David


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [gfvs] cdda backend

[David Zeuthen]

On Mon, 2007-12-17 at 12:47 +0100, Alexander Larsson wrote:
 On Mon, 2007-12-17 at 10:42 +, Bastien Nocera wrote:
- file manager not a good UI for ripping songs; better to launch
  the cd player
  
  That's still current.
 
 I think this is the main issue here. There are technical aspects, yes
 (as noted in your mail), but those are all secondary. The primary
 question is, what is a good way for a desktop to support playing and
 ripping audio CDs such that its powerful and easy to use. I think
 pretending they are wavs succeed in neither of these.

I'm not suggesting to change what happens if you double click the Audio
CD icon on the desktop or in computer:///. But what should happen if
you select the Audio CD in the file chooser?

The main point of this backend is to unify the IO path for getting the
PCM data on the disc. Contrary to popular belief the data on audio discs
is actually PCM data and pretending it's not isn't really useful.

There's also the point that /dev/cdrom (or whatever) might not be
accessible to the user once (and if) packet writing starts becoming
mainstream. Then it's useful to just grant the gvfsd-cdda driver the
permission to access the device file.

 David


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [gfvs] cdda backend

[David Zeuthen]

On Mon, 2007-12-17 at 11:00 -0500, David Zeuthen wrote:
 On Mon, 2007-12-17 at 12:47 +0100, Alexander Larsson wrote:
  On Mon, 2007-12-17 at 10:42 +, Bastien Nocera wrote:
 - file manager not a good UI for ripping songs; better to launch
   the cd player
   
   That's still current.
  
  I think this is the main issue here. There are technical aspects, yes
  (as noted in your mail), but those are all secondary. The primary
  question is, what is a good way for a desktop to support playing and
  ripping audio CDs such that its powerful and easy to use. I think
  pretending they are wavs succeed in neither of these.
 
 I'm not suggesting to change what happens if you double click the Audio
 CD icon on the desktop or in computer:///. 

On a similar note; we should ensure that the desktop launces totem if
you click the icon representing the GMount for a disc that is a DVD
Movie. Similar for e.g. f-spot if the GMount represents a card with
photos (DCIM/) or a camera (gphoto2 backend). In the extreme at least.

(Personally, I'd prefer the file manager was launched for any of these
with a Blue bar in the top (like we have for trash:// and burn://)
telling me I should use these apps and providing a Launch button for
them)

I think my main point is that this discussion mixes GNOME Desktop user
experience and IO paths. I'm only proposing cdda:// for the IO path.
And, frankly, gio/gvfs is so cool that we want other desktops (with
different ideas of user experience) to use it too.

 David



___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [gfvs] cdda backend

[Bastien Nocera]

On Mon, 2007-12-17 at 10:56 -0500, David Zeuthen wrote:
 On Mon, 2007-12-17 at 10:42 +, Bastien Nocera wrote:
   It seems the main objections to that new cdda module for gnome-vfs were
   
- would pull gstreamer into the client apps 
  
  Which client app would want to deal with audio CD data without pulling
  in some sort of multimedia framework?
 
 The problem, AFAIK, was that *any* application linking in
 libgnome-vfs.so would pull in gstreamer. I understood from Alex's second
 reply that was the main problem.

That's rubbish. Either the build system was seriously broken, or I
didn't quite understand the concept of plugins...

snip
   However, that ignores several fundamental problems
   
- libcdio / libparanoia isn't the API application programmers
  should use (however, gio is)
  
  GStreamer is, to deal with sound data.
 
 Sure, and I agree we should all be using GStreamer and all the apps we
 all use should be using it. But a number apps still don't and there are
 multiple competing frameworks etc.

Then they're probably using another way of accessing the data, probably
through plugins for that particular framework, certainly not using gvfs.

  Then again, a lot of us (and our
 technical users) run command line tools and it's just damn handy to have
 the PCM data available in ~/.gvfs.

Most tools you'd want to use also take in stdin.

  How will you export the (very as-hoc) errors from the underlying
  libraries? 
 
 We could return G_IO_ERROR_SCRATCHED and have the app do the moral
 equivalent of an ioctl() on the GFile to set the retries. But I think
 that's crazy and I'm not sure apps want to deal with error handling
 _anyway_ so hiding it in the backend is fine (other fs drives don't do
 this). 
 
 I think instead the backend just skips over the scratched area and puts
 up a libnotify notification (or other out-of-band signal) to notify the
 user it's skipping over the scratched area (that's how DVD Player in Mac
 OS X 10.5 does it)

That's not a bad idea for playback, but certainly not of any use for
ripping.

  How do you export the MusicBrainz Disc ID, or FreeDB one?
 
 As metadata in the WAV container (see the patch for details; search for
 Jailhouse; it's fine, we can choose another container for the PCM data
 if you want (AIFF?)

How will you get the metadata? You'll need to use musicbrainz, or
similar, data which won't carry over to changes in applications.

  I think that's a bad idea. And it eats the cdda:/ MRL space for
  GStreamer.
 
 I'm not sure these namespaces are similar anyway.

We'll need to blacklist cdda:/ from the gvfs GStreamer plugin to get it
handled by the proper CDDA plugin from GStreamer, so they do overlap.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [gfvs] cdda backend

[David Zeuthen]

On Mon, 2007-12-17 at 16:13 +, Bastien Nocera wrote:
  Sure, and I agree we should all be using GStreamer and all the apps we
  all use should be using it. But a number apps still don't and there are
  multiple competing frameworks etc.
 
 Then they're probably using another way of accessing the data, probably
 through plugins for that particular framework, certainly not using gvfs.

No, of course not. But it's pretty useful to do things like [1]; ditto
for lame and other commandline tools. There's a lot of complaints from
users that the gnome-vfs mounts weren't accessible to plain old POSIX
apps.

  I think instead the backend just skips over the scratched area and puts
  up a libnotify notification (or other out-of-band signal) to notify the
  user it's skipping over the scratched area (that's how DVD Player in Mac
  OS X 10.5 does it)
 
 That's not a bad idea for playback, but certainly not of any use for
 ripping.

Maybe if you explain what you need it's easier to figure out. It's hard
guessing.

   How do you export the MusicBrainz Disc ID, or FreeDB one?
  
  As metadata in the WAV container (see the patch for details; search for
  Jailhouse; it's fine, we can choose another container for the PCM data
  if you want (AIFF?)
 
 How will you get the metadata? You'll need to use musicbrainz, or
 similar, 

Sure. The point here is that we'll have a desktop-wide mechanism for
obtaining this meta data so each and every app don't need to grow their
own how to get meta data preferences dialog.

 data which won't carry over to changes in applications.

What does this mean?

 We'll need to blacklist cdda:/ from the gvfs GStreamer plugin to get it
 handled by the proper CDDA plugin from GStreamer, so they do overlap.

Does GStreamer have the concept of a VFS already?

  David

[1] : $ python wavdumper.py ~/.gvfs/CD\ Audio\ on\ sr0/Track\ 2.wav 
File: /home/davidz/.gvfs/CD Audio on sr0/Track 2.wav (61083910 bytes)
Chunk at pos 20: id = fmt , length = 16 bytes
  Format Chunk
  Data format: Uncompressed PCM
  Channels: 2
  Sample rate: 44100 Hz
  Average bytes per sec: 176400
  Block align (bytes): 4
  Bits per sample: 16
Chunk at pos 44: id = LIST, length = 66 bytes
  List Chunk, id = INFO
  Chunk at pos 56: id = ISFT, length = 54 bytes
Software: gvfs-cdda using libcdio 0.78.2 i386-redhat-linux-gnu
Chunk at pos 118: id = data, length = 61083792 bytes
  61083792 bytes sample data
  15270948 samples
  346.280 seconds


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [gfvs] cdda backend

[Bastien Nocera]

On Mon, 2007-12-17 at 11:37 -0500, David Zeuthen wrote:
 On Mon, 2007-12-17 at 16:13 +, Bastien Nocera wrote:
   Sure, and I agree we should all be using GStreamer and all the apps we
   all use should be using it. But a number apps still don't and there are
   multiple competing frameworks etc.
  
  Then they're probably using another way of accessing the data, probably
  through plugins for that particular framework, certainly not using gvfs.
 
 No, of course not. But it's pretty useful to do things like [1]; ditto
 for lame and other commandline tools. There's a lot of complaints from
 users that the gnome-vfs mounts weren't accessible to plain old POSIX
 apps.
 
   I think instead the backend just skips over the scratched area and puts
   up a libnotify notification (or other out-of-band signal) to notify the
   user it's skipping over the scratched area (that's how DVD Player in Mac
   OS X 10.5 does it)
  
  That's not a bad idea for playback, but certainly not of any use for
  ripping.
 
 Maybe if you explain what you need it's easier to figure out. It's hard
 guessing.

In playback mode, you want to skip over broken bits. You'll get a little
garble in the output. In ripping mode, you want to try as hard as
possible.

It's not possible to make the distinction right now, using gvfs.

How do you export the MusicBrainz Disc ID, or FreeDB one?
   
   As metadata in the WAV container (see the patch for details; search for
   Jailhouse; it's fine, we can choose another container for the PCM data
   if you want (AIFF?)
  
  How will you get the metadata? You'll need to use musicbrainz, or
  similar, 
 
 Sure. The point here is that we'll have a desktop-wide mechanism for
 obtaining this meta data so each and every app don't need to grow their
 own how to get meta data preferences dialog.

As we discussed on IRC, it's a bad idea to do metadata fetching from the
module itself. It's not future-proof, it makes reading the CD do network
I/O, it causes problems in terms of architecture as to where to put
dialogue for manual problem resolution (2 different CDs with the same
ID).

Having a way to get/set the metadata in the module would make sense
though. It would allow:
- renaming the mount point to show a specific name[1]
- setting an icon for the audio CD (most likely the cover)
- metadata persistance done on the application side (insert CD when on
the network, launch app, take network down, remove CD, insert CD,
metadata is still there)

IIRC, MacOS X does this the same way (ie. it will just be called Audio
Disc before iTunes gets started up). The main difference would be that
I think their module can read from the iTunes database, so it would know
about the metadata the second time the CD is inserted, even if iTunes
isn't started.

  data which won't carry over to changes in applications.
 
 What does this mean?

- Get metadata in sound-juicer
- Modify it
- No changes in the listing

  We'll need to blacklist cdda:/ from the gvfs GStreamer plugin to get it
  handled by the proper CDDA plugin from GStreamer, so they do overlap.
 
 Does GStreamer have the concept of a VFS already?

It has a concept of schemes, which are handled by one or more plugins.
Eg. a file:/// URI could be handled by the filesrc or the gnomevfssrc
right now. It obviously doesn't do directory listings, or anything
complicated like that.

Also, once the first problem (ripping vs. playing) is sorted, we could
switch the cdparanoia plugin of GStreamer to using gvfs for playback
instead. Thing I didn't understand at first was that the cdda gvfs
module doesn't allow for the audio CD to be accessed if HAL doesn't tell
it it's an audio CD. So you can play mixed CDs without the backdraw of
stomping on burns. _That_ makes complete sense (and which wasn't clear
from your original mail, which is why we came to handbags ;)

Cheers

[1]: http://bugzilla.gnome.org/show_bug.cgi?id=316403

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [gfvs] cdda backend

[David Zeuthen]

Hi,

On Mon, 2007-12-17 at 10:16 +0100, Alexander Larsson wrote:
 I'm not convinced this is what people want (over launching e.g.
 sound-juicer or gnome-cd when clicking on the audio disc icon), 

Yeah, I wasn't really clear about that. 

The main points are

 a. to get the apps to use the same IO path (gio) instead of every one
of them using cdparanoia or similar crufty API's. 

 b. having a centralized IO path allows us to handle the case where an
app tries to access the drive directly when you're burning a disc;
the cdda:// backend will just flat out refuse to mount the
disc unless there is audio on it (and it knows, a'priori, via hal
if there is: e.g. no IO is needed to find out).

 c. a small (but vocal) minority of us likes to use the command line
and non-gnome POSIX apps so have the files available via ~/.gvfs
is nice

I'm pretty sure we're all in violent agreement about that looking at
cdda:// in the file manager is a terrible experience for casual users
(e.g. my mom). 

My proposal here is to use a Clue bar [1] to tell the user to use
sound-juicer or Rhythmbox or whatever the preferred app for CD audio is
(more on preferred apps in a future mail). Probably just bring the user
directly to the app if they double click the disc. 

So users ever only get to the file manager view if they select it in the
file chooser or the file browser sidebar. And even there they get a
Cluebar.

[1] : Credit goes to mclasen for coining the term Clue bar (= the
firefox style bar in Nautilus that is shown for both trash: and burn:)

 but lets
 add it, it doesn't hurt.

OK, I'll commit it after cleaning it up a bit more.

  First, a small feature list
  
   - Stateful mounts; yes, you actually mount the cdda gvfs filesystem
 driver; there's one instance of gvfsd-cdda per mount. You also have
 to mount the fs manually: gvfs-mount cdda://sr0
 
 You don't actually have to make each cdda mount its own process. If you
 want you can add a well-known dbus name to the cdda.mount.in file (which
 is missing from your patch btw). gvfsd will hand off cdda mount
 operations to that name if it exists, instead of spawning a new copy.

But I actually want a separate process for each mounted disc... seems
easier if I don't have to care about life cycle management at all (e.g.
when unmounted gvfsd will terminate the backend process).

   - Works with multiple clients at the same time as well as when
 a iso9660 filesystem is mounted by a kernel driver. There's seeking
 and it's a bit slow (can be alleviated once we introduce readahead
 in the GVfsBackend base class, yes?) but basically works very well
 
 Readahead is mainly gonna speed up the case where an app does
 read_source()
 write_destination()
 read_source()
 write_destingation()
 ...
 
 I.e. while it blocks writing what it just read we can automatically
 schedule a read from the source so that the next read will finish
 faster. Its not really related to seeks.

It's indirectly related; the thing is that each read operation will get
to read more sectors before the other ones. Thus less seeking is
involved, thus higher throughput.

   2. I have to set GMountSpec in try_mount(); it's not enough just
  setting it in do_mount(). Bug?
 
 Yes, that shouldn't happen. Can you try to look into this?

Will do.

   3. Once mounted, there's no way for the backend to change it's display
  name. I think I understand why you did this; it's because of the
  FUSE daemon right? E.g. you want to ensure that there are no
  name collisions to make it easier to figure out what directories
  to return in ~/.gvfs ...
  
  Anyway, the reason we want this is that initially we probably want
  the display name Audio Disc and if we (much later) acquire meta
  data for the disc we want to change it to Tori Amos - Silent
  all these years or whatever the title is.
  
  (same applies for the icon (think cover art); I haven't tested if
   this doesn't work)
 
 Hmmm. Tricky. Its kinda weird having the name of the actual mountpoint
 change. Especially with it being the identifier for the mount in the
 fuse case. I think the best solution is to have the volume be called
 _(Audio Disc), but then set the display name of the root of the disk
 to the actual disk title. Thats what will be displayed in many places
 like the window title for the toplevel directory.

Maybe we want

 g_vfs_backend_set_display_name (backend, display_name);
 g_vfs_backend_set_local_mount_name (backend, display_name); [1]

where the latter can't change once mounted and is used by the FUSE
daemon. The latter can change as much as we want (AFAICT it's fine to
have collisions in displayable names for both GDrive, GVolume and
GMount.)

[1] : If not apparent already, I suck at naming. Feel free to suggest
alternatives

  This all sounds complicated but I'm not sure it really is. I think
 all
  we need to do is to have some kind of tags we can decorate the
  

[gfvs] cdda backend

[David Zeuthen]

Hey Alex,

(Sorry to continue bombarding you with super long mails and patches)

Here's a cdda:// backend for gvfs. Before going into details (and some
minor, probably easily fixable, architectural issues I've identified)
it's probably useful to answer the question Why a cdda backend? since
that question was asked here

http://mail.gnome.org/archives/gnome-vfs-list/2005-August/msg1.html
http://mail.gnome.org/archives/gnome-vfs-list/2005-August/msg00022.html

It seems the main objections to that new cdda module for gnome-vfs were

 - would pull gstreamer into the client apps 

 - seeking didn't work

 - file manager not a good UI for ripping songs; better to launch
   the cd player

However, that ignores several fundamental problems

 - libcdio / libparanoia isn't the API application programmers
   should use (however, gio is)

 - nasty locking issues when doing things decentralized (if it's
   up to the software to do the raw device access it might do
   uninformed things like using O_EXCL)

 - duplication in every app (extraction, meta data retrieval)

So I wrote the attached cdda module because with gio/gvfs I think it
actually makes sense have a cdda:// backend (also, and sorry for
sounding like a cargo cult follower, to have feature parity with Mac OS
X and Windows). And I also wanted to get a feel / help review the plugin
API before we freeze. 

First, a small feature list

 - Stateful mounts; yes, you actually mount the cdda gvfs filesystem
   driver; there's one instance of gvfsd-cdda per mount. You also have
   to mount the fs manually: gvfs-mount cdda://sr0

 - Seeking just works (try 'totem ~/.gvfs/CD\ Audio\ on\ sr0/Track\
   2.wav' and seek away)

 - Works with multiple clients at the same time as well as when
   a iso9660 filesystem is mounted by a kernel driver. There's seeking
   and it's a bit slow (can be alleviated once we introduce readahead
   in the GVfsBackend base class, yes?) but basically works very well

http://people.freedesktop.org/~david/mixed-cdda-iso9660-copying.png
(Copying two cdda tracks and four files from the iso9660 fs)

 - Puts RIFF tags in the .wav files containing metadata; though no
   metadata framework is currently hooked up (I tried experimentally
   hooking up s-j's libjuicer and it works very well; unfortunately
   that library is pulling in gtk, gnome-vfs, gconf... Ross?)

   (unfortunately #437499 shows these are just ignored. But that's
fixable.)

 - Uses libcdio which I think is portable to Solaris and other
   non-Linux platforms too

 - See the actual patch for remaining TODO's / feature ideas

Some issues I've encounter with gvfs; some are probably small bugs; the
last one is more on an architectural level and probably needs addressing
before freezing..

 1. The GVfs FUSE daemon never class close() on my fs backend when
it's done reading.. this leads to leaks. Have you seen this?

 2. I have to set GMountSpec in try_mount(); it's not enough just
setting it in do_mount(). Bug?

 3. Once mounted, there's no way for the backend to change it's display
name. I think I understand why you did this; it's because of the
FUSE daemon right? E.g. you want to ensure that there are no
name collisions to make it easier to figure out what directories
to return in ~/.gvfs ...

Anyway, the reason we want this is that initially we probably want
the display name Audio Disc and if we (much later) acquire meta
data for the disc we want to change it to Tori Amos - Silent
all these years or whatever the title is.

(same applies for the icon (think cover art); I haven't tested if
 this doesn't work)

 4. There's very little in way of documentation so it was really
confusing to start writing the backend. Once I got the hang of
it, it was a smooth ride though.

 5. There needs to be a way to associate a GDaemonMount to an existing
GVolume object (stemming from the HAL volume monitor). This is
not a problem inherent to the CDDA backend; it applies to any
backend that provides a user space file system driver for a block
device (e.g. NTFS, secure paranoid vfat etc.).

The first problems are probably easily fixable; the last one is more
problematic. Here's how I envision it will work

User inserts audio disc into drive. The HAL volume monitor notices this
and creates a GVolume object representing the unmounted audio disc. The
mount() method on the HAL volume monitor for said GVolume will simply do
the equivalent of

 $ gvfs-mount cdda://sr0

since it knows there a cdda:// backend already. So when this happens the
gvfs-cdda backend is started for sr0 and as a result a GDaemonMount is
created in the process space of all gvfs clients using volume monitoring
(via GDaemonVolumeMonitor). Now, I think all we need to do is

 o  Make the GHalVolume live object for sr0 note that the
new GDaemonMount object was created and associate with it (e.g.
take a weak ref and emit changed. Future calls