Created attachment 102967 [details] [review]
patch

Created attachment 102968 [details] [review]
another patch

Of course, just setting the defaults to false is not good enough for upgrades, where the user has modified settings. Here is a patch that makes g-v-m ignore the
keys that are handled by nautilus by treating them as FALSE, regardless of the actual value in gconf.

does nautilus handle running of Win32 autorun.exe's and autorun.inf's?

g-v-m does, and I /really/ want that feature to continue working.

It doesn't currently, I think.

We could make it do that, if the nautilus people don't consider it too crazy.

I wouldn't mind, but i'm not sure how you run a .exe file...

(In reply to comment #3)
> does nautilus handle running of Win32 autorun.exe's and autorun.inf's?
> 
> g-v-m does, and I /really/ want that feature to continue working.
> 

I was planning to add support for the fd.o autostart stuff; if g-v-m already does win32 autorun.exe and autorun.inf I'll support that too (through copy-paste). Won't be able to test it though.

alexl: you can probably copy/paste the code from g-v-m, lemme know if you have any questions.

DavidZ: awesome, if you have any questions about the code, ask away - I will try to answer :)

autorun.exe support is the easiest of the 2, it just involves invoking wine (which you can check for in your path) - for autorun.inf, it's a little harder because you have to parse the .inf file to get the path and arguments, but I have some code that does that in g-v-m already.

When you change the way *.exe files are treated, can you please make sure that you never (automatically or manually) run *.exe files through wine which don't have the e'x'ecutable bit set?

Usually, wine packages for distributions should be set up to register .exe through /proc/sys/fs/binfmt_misc, so that the 'x' bit is enforced. Running it through desktop/MIME-type magic doesn't enforce this and thus opens up a wide security trap for inadvertedly downloading and running viruses, worms, etc. 

Thanks for considering!

the g-v-m code already checks the x bit, so if you just copy that then all should be fine :)

The second patch to filter out media handling is a bit strange and doesn't build: Neither of two calls of filter_out_media_handling() matches the function declaration.

Created attachment 106263 [details] [review]
filter out media handling keys from gconf

This patch makes more sense IMHO, and actually works. Thanks for considering!

I wonder if the name gnome-volume-manager makes sense anymore after this... and most of all, the title of the preferences window ("removable drives and media preferences") is strange, I think we need to come up with a new name here.

Or better retire gnome-volume-manager all together. Sorry to sound like I'm flaming but the remaining tabs that Nautilus don't handle are

 PDA                   <- should be handled by gnome-pilot

 Printers & Scanners   <- normally handled by distro tools (e.g. system-
                          config-printer on Fedora and now also Ubuntu)

 Input Devices         <- should be handled by an X configuration tool
                          now that X.org supports hot plugging

and the way it's handled (run this command) is less than useful.

The biggest remaining job of g-v-m so far is to handle digital cameras (call gthumb, or f-spot). This still needs to be adopted by something else then.

(In reply to comment #14)
> The biggest remaining job of g-v-m so far is to handle digital cameras (call
> gthumb, or f-spot). This still needs to be adopted by something else then.

It's already in nautilus.

(In reply to comment #15)
> It's already in nautilus.

Right... but is there a also an x-content/ for photo management apps? Right now the dropdown shows no apps installed for this task.

As discussed on IRC, x-content/image-dcf has to be used.

BTW, is there a nautilus replacement for the 'low disk space' notifications? Although this has been subject to eternal disagreements for at least removable drives (where they are quite pointless IMHO), they are very useful for early catching space problems of the system partition.

(In reply to comment #18)
> BTW, is there a nautilus replacement for the 'low disk space' notifications?

Nope, I forgot to port this over sorry... We should do it for Nautilus 2.23/24.

Jeffrey: Can we get the patches committed? Right now, all distros have to ship a patch for this...

as has been mentioned, it seems that g-v-m has been antiquated by nautilus now and might as well be deprecated, really.

I'm not sure I see the point of g-v-m if we remove all this functionality from it.

Well, as long as we don't have tools for PDA/Input devices, we still need g-v-m for some stuff... So let's just remove the things we don't need for now, and keep it for the other features until it gets totally deprecated.

Please note that in order to fix this properly, you need an additional hunk to the filter patch:

--- gnome-volume-manager-2.22.1/src/manager.c
+++ gnome-volume-manager-2.22.1.new/src/manager.c
@@ -3294,7 +3315,9 @@
        libhal_ctx_set_device_new_capability (ctx, hal_device_new_capability);
        libhal_ctx_set_device_lost_capability (ctx, hal_device_lost_capability);
        libhal_ctx_set_device_property_modified (ctx, hal_property_modified);
+        /* only needed for eject ATM, which is done by nautilus; disable
        libhal_ctx_set_device_condition (ctx, hal_device_condition);
+        */

        dbus_error_init (&error);
        if (!libhal_device_property_watch_all (ctx, &error)) {

(see https://bugs.launchpad.net/bugs/202931) which will solve the bogus error dialog box for CD-ROM ejects.

To solve the race for mounting CDs when /desktop/gnome/volume_manager/automount_media is enabled in the user's gconf, you need to apply the patch I submitted to bug 525345 (which you should do anyway, since it should fix a lot of ominous "configuration does not work"-type bugs).

autophoto should be disabled as well, that's done by nautilus now, too.

Jeffrey: would really be nice to have a new tarball with this patch. Right now, all distros have to ship the patch...

Putting the media handling policies into the Nautilus preferences is a serious usability regression.

The Nautilus preferences are non-obvious. It doesn't make sense that Nautilus should handle things like audio CDs. Why would the user think of looking in the file manager preferences (which are accessed only through a file manager window) to change a system level policy!?

This problem is compounded by having a "removable drives and media capplet", which is where a user might expect to find the settings for removable drives and media - NOT NAUTILUS PREFERENCES.

If this is being done in order that g-v-m can be removed, then some more thought needs to be given to how the preferences should be placed.

(In reply to comment #26)
<snip>
> Why would the user think of looking in the
> file manager preferences (which are accessed only through a file manager
> window) to change a system level policy!?

System->Preferences->File management

>> Why would the user think of looking in the
>> file manager preferences (which are accessed only through a file manager
>> window) to change a system level policy!?

>System->Preferences->File management

This isn't the case downstream in Ubuntu (which of course is not your problem). However, it still doesn't address the more fundamental point that handling an audio CD is not a file manager issue. The point of abstraction is all wrong. Why should a file manager deal with the concept of a physical medium? My camera's SD card is where I put photos, it isn't where I manage files (well, I might, but that's a secondary use).

(In reply to comment #26)
> Putting the media handling policies into the Nautilus preferences is a serious
> usability regression.
> 
> The Nautilus preferences are non-obvious. It doesn't make sense that Nautilus
> should handle things like audio CDs. Why would the user think of looking in the
> file manager preferences (which are accessed only through a file manager
> window) to change a system level policy!?
> 
> This problem is compounded by having a "removable drives and media capplet",
> which is where a user might expect to find the settings for removable drives
> and media - NOT NAUTILUS PREFERENCES.
> 
> If this is being done in order that g-v-m can be removed, then some more
> thought needs to be given to how the preferences should be placed.

Don't mean to patronize you but am pretty sure your reaction caused by us messing with your muscle memory; e.g. moving things around. Which is a natural thing. Also with the extra clue bar for detected media e.g.

http://people.freedesktop.org/~david/nautilus-cluebar-musicplayer.png
http://people.freedesktop.org/~david/nautilus-x-content-cluebar-1.png

So I think it should be evident, at least over time, that you use the file manager to manage media. Maybe it would make sense to rename the "File Management" preferences item to "Files and Media", I dunno. If you feel strongly about that suggest to file a bug against Nautilus (and please add me as Cc or paste the bug number here) to change the name and icon.

It also seems you are not appreciating that most normal users will never need to change the defaults. In such situations it's almost always a good idea to hide the preference to a less prominent position (god knows we have enough preferences capplets already) to mentally overloading the users with choice.

(In reply to comment #29)
<snip>
> 
> Don't mean to patronize you but am pretty sure your reaction caused by us
> messing with your muscle memory; e.g. moving things around. Which is a natural
> thing. 

This isn't the case. I totally agree that there are too many capplets and something needs to be done about it. But the point is that the Nautilus preferences dialogue is not the correct place this option. You only need to look at the existing tabs:
Views, Behaviour, Display, List Columns, Preview

These all refer to actions or representations on or of the file (which for most users is the icon with words under it). The dialogue is about how NAUTILUS deals with files. Media on the other hand is a completely different idea. It refers to something totally distinct from files which is, from a users perspective, the physical object (e.g. a DVD, or an SD card, or a camera). Nautilus doesn't even deal with these things (except in a "this is also a video DVD" way - which is sensible).

> 
> So I think it should be evident, at least over time, that you use the file
> manager to manage media. Maybe it would make sense to rename the "File
> Management" preferences item to "Files and Media", I dunno. If you feel
> strongly about that suggest to file a bug against Nautilus (and please add me
> as Cc or paste the bug number here) to change the name and icon.
> 

That doesn't make sense. Why should you use the file manager to manage media except because that's what you've learned to do? It still doesn't answer the fundamental question, why is the file manager being used to handle media?

Don't get me wrong, I am not against change. However, I think that this change is an attempt to retrofit a file manager with something that doesn't quite fit. Nautilus may well be the best place to put these sort of options, and perhaps your suggestion to rename the preferences dialogue is the correct one, but if this is the case then Nautilus is no longer just a file manager and design decisions should respect this. Sticking a new tab onto the preferences dialogue is a poor solution.

> It also seems you are not appreciating that most normal users will never need
> to change the defaults. In such situations it's almost always a good idea to
> hide the preference to a less prominent position (god knows we have enough
> preferences capplets already) to mentally overloading the users with choice.
> 

I agree. However, they should still be easily found (otherwise why not just say edit them in gconf editor and be done). I strongly refute the view that putting them in the file management preferences is easily found.

> That doesn't make sense. Why should you use the file manager to manage media
> except because that's what you've learned to do? It still doesn't answer the
> fundamental question, why is the file manager being used to handle media?
>
> Don't get me wrong, I am not against change. However, I think that this change
> is an attempt to retrofit a file manager with something that doesn't quite
> fit. Nautilus may well be the best place to put these sort of options,
> and perhaps your suggestion to rename the preferences dialogue is the
> correct one, but if this is the case then Nautilus is no longer just a
> file manager and design decisions should respect this. Sticking a new 
> tab onto the preferences dialogue is a poor solution.

Nautilus already been handling media for a long long time e.g. 

 - icons for volumes on the desktop
 - the icons computer:///
 - the sidebar in the file manager
 - burn:/// and so on. 

Not to mention the specific names and icons for media / drives e.g. "Blank CD-R Disc". 

Pretending that the file manager isn't used for browsing removable media / drives is not exactly realistic. The indisputable fact is that Nautilus been handling media for quite a while.

(And with gvfs it's just a lot more integrated insofar that we have a good VFS system to provide a file system view of storage devices/media using weird protocols such as cdda:// and gphoto2://.)

> I strongly refute the view that putting
> them in the file management preferences is easily found.

Actually I didn't claim that; I claimed the exact opposite. That it would be hard to find. And this is _absolutely_ intended as most users, on a properly configured system or distribution, should never need to change the defaults. But if you want to change the defaults there's still a place to do that: We don't make the 1% use case impossible, we just make it (a bit) harder (just punting it to gconf is not an option in this case).

(In reply to comment #31)

> Actually I didn't claim that; I claimed the exact opposite. That it would be
> hard to find. And this is _absolutely_ intended as most users, on a properly
> configured system or distribution, should never need to change the defaults.
> But if you want to change the defaults there's still a place to do that: We
> don't make the 1% use case impossible, we just make it (a bit) harder (just
> punting it to gconf is not an option in this case).
> 

That's just crazy talk! why would you even bother making a dialogue *hard* to find. May as well just remove it entirely and let people use gconf editor to fix it. Either include it, and make it easy to find, or remove it entirely.

Note, "easy to find" does not mean "cluttering everything up" or "in your face", it means carefully placed such that when the user wonders if it's possible to fix, lo, it is!

> Actually I didn't claim that; I claimed the exact opposite. That it would be
> hard to find. And this is _absolutely_ intended as most users, on a properly
> configured system or distribution, should never need to change the defaults.
> But if you want to change the defaults there's still a place to do that: We
> don't make the 1% use case impossible, we just make it (a bit) harder (just
> punting it to gconf is not an option in this case).

GNOME is supposed to be usable, _WHY_ on earth would you want to deliberately
hide a _safe_ preference someone might concievably want to change?

It is my opinion that moving this into Nautilus is a step backwards.. why does
it even justify the time required to move all the code out of
gnome-volume-manager?

If I insert media (camera memory card, DVD etc..) I don't necessary want it to
open in Nautilus - why make it an intermediary to the process.

I realise this doesn't fit with the "GNOME is simple out of the box" strategy,
but I will often kill nautilus when I don't want to use it (no desktop with
files etc..).

Moving everything into nautilus and integrating so it is critical to desktop
operations rather seems to fly in the face of the general UNIX philosophy of
providing small tools which are _good_ at a particular task, then gluing those
parts together to make a powerful system.

(In reply to comment #32)
> That's just crazy talk! why would you even bother making a dialogue *hard* to
> find. May as well just remove it entirely and let people use gconf editor to
> fix it. Either include it, and make it easy to find, or remove it entirely.
> 
> Note, "easy to find" does not mean "cluttering everything up" or "in your
> face", it means carefully placed such that when the user wonders if it's
> possible to fix, lo, it is!

I maintain disagreeing that it's impossible / super hard to find while still agreeing we can do better such as renaming the Nautilus preference capplet name from "File Management" to "Files & Media". Either way you're barking up the wrong tree in the bug (you're complaining about Nautilus in a g-v-m bug).

(In reply to comment #33)
> GNOME is supposed to be usable, _WHY_ on earth would you want to deliberately
> hide a _safe_ preference someone might concievably want to change?

Because it's a rarely used option and there is little point in cluttering the UI with an entire capplet for this..

> It is my opinion that moving this into Nautilus is a step backwards.. why does
> it even justify the time required to move all the code out of
> gnome-volume-manager?

Obviously you never read that code or realize that it needed to be rewritten _anyway_ to do automounting of gvfs mounts.

(This bug report is turning into a bike shed discussion and I won't reply on this particular topic any more. Good luck!)

(In reply to comment #29)
> So I think it should be evident, at least over time, that you use the file
> manager to manage media. Maybe it would make sense to rename the "File
> Management" preferences item to "Files and Media", I dunno. If you feel
> strongly about that suggest to file a bug against Nautilus (and please add me
> as Cc or paste the bug number here) to change the name and icon.

(Filed as bug 527197)

> Because it's a rarely used option and there is little point in cluttering the
> UI with an entire capplet for this..

I didn't say it should have - but you seemed to want to deliberately hide the options where people wouldn't find them.

I don't actually care too much whether the capplets are refactored to provide more tabs (assuming the naming is intuitive). There is no reason a particular capplet can't control Nautilus properties as well as gnome-volume-manager ones. This allows the capplet to gather logically related preferences which affect different backend programs.

>> why does it even justify the time required to move all the code out of
>> gnome-volume-manager?

> Obviously you never read that code or realize that it needed to be rewritten
> _anyway_ to do automounting of gvfs mounts.

I didn't until now, and am sorry if I appeared to trivialise the code changes. I was only trying to understand why there is a move to take functionality out of gnome-volume-manager and re-implement it in Nautilus, which seems (IMO) the wrong place to add it. Looking back at the previous comments to this bug, there are a good number of features in g-v-m which would have to be moved to Nautilus.. my question is just "why".

> (This bug report is turning into a bike shed discussion and I won't reply on
> this particular topic any more. Good luck!)

That wasn't my intention. Henry is a friend of mine, and pointed me at the bug as he thought I'd be interested. I happened to agree with his point about the _current_ File management preferences capplet being an unintuitive place for media mounting options, but was more concerned about the attitude that you _intended_ to make those properties hard to find.

The question I really have, is what are the technical reasons why it is useful to move this functionality out of g-v-m and into Nautilus? Perhaps this bug isn't the best place to discuss that though.

Reading the comments here,my understanding is that g-v-m will no longer be handling the mounting of devices (by calling gnome-mount, or whatever) and instead that will be handled by nautilus.  Is that right?

If that's correct, I strongly disagree with this change.  I work on a project that uses GNOME in more of an appliance-like manner, and we do not run nautilus at all since there is no need for a file manager.  However, we still want USB sticks to be mounted for usage by applications.  This change would force us to run nautilus, or more likely to write our own daemon for mounting volumes.

Searching for anything regarding this change on relevant mailing lists reveals nothing, which is more than a little alarming.  Surely there is a process in place for deprecating a module that requires more than filing a bug?  Hopefully I am just missing something here.

gnome-volume-manager-2.22.3's configure script optionally disables all the volume options/functionality from both the daemon and the properties dialog.

g-v-m 2.22.3 still runs a media plyaer when a suitable device is inserted; and so does Nautilus. This should probably be removed too.

Sam, agreed there shouldn't be duplicate functionality, but should it be removed from Nautilus or removed from g-v-m?

I don't know, I'm just a (Debian) packager trying to come up with a sane set of GNOME packages for our next release. ;)

BTW, I have created a page on our wiki that lists the overlapping features between nautilus and gnome-volume-manager; it can be found at <http://wiki.debian.org/Gnome/nautilus_vs_gnome-volume-manager>.

Sorry, reading back I realise I was probably trolling with that last comment.

I still think media insertion should be able to work on a kiosk or other restricted system where Nautilus has been disabled.

Attempting to be more constructive, here are a few ideas off the top of my head...

System running with no open programs:

Media inserted -> Mount and inspect:
  Found files -> Open Nautilus window
  Found auto-run -> Might try to auto-run / Nautilus window?
  Found pictures -> F-Spot / Nautilus window / other?
  Found music / video -> Open appropriate media player

What if I already have a particular media player open?

Would it be appropriate for that media player to handle the auto-play of any music / video, rather than going back via the main "media-inserted" dispatcher?

Does it violate the principle of least surprise if having F-Spot open causes my digital camera cards to load into F-Spot without an "Open in F-Spot" prompt, just because I already had F-Spot already loaded?

I guess what I'm getting at here is the idea of having some process responsible for auto-launching actions on media insertion, like g-v-m does now, but to allow applications such as Nautilus, F-Spot, Totem, Rhythmbox which are media-aware, to communicate with that process and register more specific ways of handling media, or to query actions which are appropriate.

A Nautilus browser window's clue-bar could then present the same launch options as would have been available without Nautilus running. A running copy of Rhythmbox could grab iPods plugged into the system without a prompt, leaving the popup of a Nautilus window with files a default for unhandled media.

It may also be useful in some cases to allow applications to notify that they want / have some level of exclusive "ownership" of a particular media, e.g. during a write operation to an iPod music database: 

Can't eject "Peter's iPod"
Rhythmbox is writing data.

The usability folks will probably be able to work out what the right interactions are.

g-v-m 2.22.5 disables eject events now too.

remind me what the point of having g-v-m is again?

So, all the patches in this bug are no longer necessary. Perhaps it can be closed?

Nautilus still does one thing that g-v-m also does: handles the launching of a program like gphoto when a camera is inserted. Though if it is going to do this, it should also take over the other tasks from gnome-volume-manager's gnome-volume-properties' "cameras" tab; that is, launching a video editor when a camcorder is attached, and launching a program like Cheese when a webcam is attached.

PS - Jeffrey, check the page at http://wiki.debian.org/Gnome/nautilus_vs_gnome-volume-manager for a list of g-v-m's features that Nautilus has not taken over. ;)

(In reply to comment #45)
> Nautilus still does one thing that g-v-m also does: handles the launching of a
> program like gphoto when a camera is inserted. 

This actually worked just fine until alexl broke gvfs by deciding that automounting gphoto2 file systems would not happen for 2.22. This is because some applications wouldn't be able access the underlying USB device. The general point of view of alexl (and the release team) was that we hadn't given these applications enough time to move to gio so it was decided to break the gphoto2 gvfs backend for 2.22 but enable it for HEAD (which is done already). So for 2.24 automounting of gphoto2 device will work from Nautilus and users will get the dialog if they have pictures on their digital camera camera.

(FWIW, in Fedora 9, we actually decided to revert that breakage and automount gphoto2 devices (and passing POSIX paths to apps, see bug 528670) so there things actually just fine. Other vendors can do the same.)

> Though if it is going to do
> this, it should also take over the other tasks from gnome-volume-manager's
> gnome-volume-properties' "cameras" tab; that is, launching a video editor when
> a camcorder is attached, and launching a program like Cheese when a webcam is
> attached.

I don't think we want Nautilus to be a dumping ground for handling all kinds of devices. Nautilus should only handle storage devices (e.g. devices with either kernel-level block devices or a gvfs backend).

IIRC most newer camcorders appear as USB mass storage devices so we should handle these by adding an x-content/video-camcorder type and a) adding quirks to HAL; and b) see if camcorders have something akin to DCF (e.g. a DCIM/ folder structure), much like we do for audio players (x-content/audio-player) and digital cameras (x-content/image-dcf) already.

However older camcorders (using e.g. Firewire and DV), web cams and other hardware that surely isn't storage devices will need to be handled elsewhere; either in a new project or by still using gnome-volume-manager. My suggestion here would be to extend gnome-settings-daemon to handle these cases as it already handles hotplug of monitors via X.org's XRandR 1.2 interfaces. I think these days g-s-d even sports a plug-in interface so maybe that would be one thing to start with.

     David

For the record, in Ubuntu Hardy we disabled gvfs's gphoto module, since it's still too broken. We continue to use g-v-m for handling photo cameras, which also fits much better into the currrent UI.

(In reply to comment #47)
> For the record, in Ubuntu Hardy we disabled gvfs's gphoto module, since it's
> still too broken. 

Somehow you forgot to forward these bugs to upstream. Can you do that please? I did remember seeing some Ubuntu bugs and most of these were caused by libphoto2 crashers (e.g. NOTGNOME).

      David

Right, that came across a bit bad, sorry. What I meant is, that with Gnome 2.22 final, the integration of the backend is insufficient, since many of GNOME's applications are not ported to gvfs yet. For example, clicking on a picture in nautilus' gphotofs view doesn't work, because eog does not understand gvfs. I filed that as bug 530371 now.

Due to the incomplete porting/integration, the user experience is currently very bad. gphotofs is not automounted, thus nothing particular happens if you plug in a camera. That's deliberate, I guess, since it prevents f-spot/gthumb/gphoto CLI from working (since the device is already blocked). Due to that we disabled gphotofs for the stable 8.04 Ubuntu release.

(In reply to comment #49)
> Right, that came across a bit bad, sorry. What I meant is, that with Gnome 2.22
> final, the integration of the backend is insufficient, since many of GNOME's
> applications are not ported to gvfs yet. For example, clicking on a picture in
> nautilus' gphotofs view doesn't work, because eog does not understand gvfs. I
> filed that as bug 530371 now.

OK, I thought you were talking about actual bugs in the backend (I am not aware of any open bugs there). Right, the integration points are a problem. FWIW, see bug 528670 (in particular bug 528670 comment 5 for a nicer solution) - in Fedora we do something like this and it seems to work very well; e.g. I can happily run gedit or eog on gphoto2 and archive mounts. Even the gthumb photo importer works fine. Something to consider for 2.24 but definitely not a change I want to do without having it approved by alexl (who is on paternity leave for the next five monts).

> Due to the incomplete porting/integration, the user experience is currently
> very bad. gphotofs is not automounted, thus nothing particular happens if you
> plug in a camera. That's deliberate, I guess, since it prevents
> f-spot/gthumb/gphoto CLI from working (since the device is already blocked).
> Due to that we disabled gphotofs for the stable 8.04 Ubuntu release.

Fair enough.

Granted, I am very late to this party (having just made the jump from FC4 to FC10), but I heartily agree with Mr. Clifton and Mr. Gomersall.  I've been using FVWM since before-Linux and under FC4, I was patching in the bits of gnome that were useful (like g-v-m).

Requiring Nautilus to get automounting of usb sticks seems heavy handed (and decidedly un-unixy, to echo Mr. Clifton).  This is such a big step backwards.  I'm rather shocked and appalled at this turn of events.

According to its maintainers, "g-v-m hasn't seen a change in three years, it definitely qualifies as unmaintained."

It is highly unlikely that there will be any further active development
(especially as functionality has been superseded by other modules).

Closing this report as WONTFIX as part of Bugzilla Housekeeping - Please feel
free to reopen this bug report in the future if anyone takes the responsibility
for active development again.