should allow opening non-removable partitions (port to Gio)

Bug #136940 reported by Jani Monoses
34
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Xfce4 Places Plugin
Fix Released
Wishlist
xfce4-places-plugin (Ubuntu)
Fix Released
Wishlist
Unassigned

Bug Description

Binary package hint: xfce4-places-plugin

currently, unlike in thunar and xfdesktop, the volumes that are non-removable are greyed out. Our thunar is patched to do that, and the places plugin should behave similarly. When such a volume is opened gnome-mount is invoked, the user asked for admin password via gksu and if entered correctly
the volume is mounted and opened.

Revision history for this message
Jani Monoses (jani) wrote :

high prio, for consistency with the rest of the default desktop

Changed in xfce4-places-plugin:
importance: Undecided → High
Revision history for this message
Jani Monoses (jani) wrote :

I have just noticed there's a way to mount by clicking on the small context menu that appears on greyed out volumes. Is there a disadvantage to just mounting without showing that menu at all? That is how thunar an dnautilus behave.

Revision history for this message
Diego Ongaro (ongardie) wrote :

"currently, unlike in thunar and xfdesktop, the volumes that are non-removable are greyed out. Our thunar is patched to do that, and the places plugin should behave similarly."

I feel like I entirely missed your request. Please explain.

"high prio, for consistency with the rest of the default desktop"
"I have just noticed there's a way to mount by clicking on the small context menu that appears on greyed out volumes. Is there a disadvantage to just mounting without showing that menu at all? That is how thunar an dnautilus behave."

Let's clarify a couple things. Nautilus is irrelevant. Thunar was designed to look like GTK's open/save dialog, which on my system doesn't even show removable media. I prefer the context menu because *I* tell the thing when to mount and when to unmount. For example, I don't want to accidentally mount my external hard drive (which I find too easy to do in Thunar), kill the switch on it later, and have the filesystem end up unhappy.

Now, I think there are four options on how we can reasonably close this bug:
1) Reject it as a non-issue
2) Open a bug in Xfce's bugzilla, and I'll be willing to (hackishly) make a preference sometime
3) Open a bug in Xfce's bugzilla, and submit a hackish patch for a preference
4) Make Thunar use a context menu

Note that 2 and 3 involve opening a bug in Xfce's bug tracker. Try to be a bit more respectful of my time and efforts, too: take your time such that you make sense, write less typos, get all your thoughts out in the initial description (not subsequent comments), and mark something like this low priority.

Thanks,
Diego Ongaro

Changed in xfce4-places-plugin:
importance: High → Wishlist
Changed in xfce4-places-plugin:
status: New → Triaged
Revision history for this message
In , Mathias Brodala (mathbr) wrote :

Since Thunar itself now uses Gio and Udev for device handling, the places plugin should follow and use the same framework. This would make the dependency on ThunarVFS obsolete and would allow me to get rid of HAL for good.

Revision history for this message
In , Diego Ongaro (ongardie) wrote :

*** Bug 6674 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Diego Ongaro (ongardie) wrote :

Yes, you're absolutely right, places needs to be ported over. Let me know if you want to work on this; my time for the project has been quite limited lately.

Revision history for this message
In , Yves-Alexis Perez (corsac) wrote :

Damn, bugzilla (and/or me) really has searches issues. Sorry for duplicate.

No I don't really have time to port it (I barely have time to maintain Xfce stuff these days) but thought it'd be nice to track it, except I didn't see it was already tracked.

For people interested, it might be worth giving some infos about the current state (how it is done at the moment) and how it should be done in a Gio world (the latter needing info from people aware, maybe Jannis could give some doc?)

Cheers and thanks for your work.

Revision history for this message
In , Jannis Pohlmann (jannis-xfce) wrote :

I haven't looked at the code yet but I remember the plugin vaguely and it should be as simple as replacing the portions of code related to thunar-vfs with usages of GIO. I don't think there's anything special (like integrating udev) that needs to be taken care of.

Revision history for this message
In , Lionel Le Folgoc (mrpouit) wrote :

*** Bug 6966 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Frivoal-m (frivoal-m) wrote :

I use places myself, so I'll be sure to get to this eventually. But if someone can contribute a patch before I get there, that would be great.

Revision history for this message
Jani Monoses (jani) wrote :

Is this still an issue with current xfce?

Revision history for this message
Lionel Le Folgoc (mrpouit) wrote :

Yes, otherwises the bug would have been closed (it needs someone to port it to gio & udev, cf. upstream bug).

Revision history for this message
In , Jan Rękorajski (baggins-pld-linux) wrote :

Created attachment 3497
port to gio

Here is the patch :)
Please check and test, this patch is a shameless rip from xfdesktop.

Revision history for this message
In , Mathias Brodala (mathbr) wrote :

(In reply to comment #7)
> Created attachment 3497 [details]
> port to gio
>
> Here is the patch :)
> Please check and test, this patch is a shameless rip from xfdesktop.

What to apply this patch to? Neither the latest 1.2.0 nor the latest git seems to work. Here’s the output from trying to patch the git version:

patching file config.h.in
Hunk #2 succeeded at 67 with fuzz 2 (offset 4 lines).
Hunk #3 succeeded at 92 with fuzz 2 (offset 7 lines).
patching file configure.in
Hunk #1 FAILED at 15.
1 out of 1 hunk FAILED -- saving rejects to file configure.in.rej
patching file panel-plugin/Makefile.am
Hunk #3 FAILED at 47.
1 out of 3 hunks FAILED -- saving rejects to file panel-plugin/Makefile.am.rej
patching file panel-plugin/model.h
patching file panel-plugin/model_system.c
patching file panel-plugin/model_user.c
patching file panel-plugin/model_volumes.c
Hunk #5 FAILED at 405.
Hunk #6 succeeded at 420 (offset 3 lines).
Hunk #7 succeeded at 474 (offset 3 lines).
Hunk #8 succeeded at 484 (offset 3 lines).
Hunk #9 succeeded at 518 (offset 3 lines).
Hunk #10 succeeded at 540 (offset 3 lines).
Hunk #11 succeeded at 548 (offset 3 lines).
1 out of 11 hunks FAILED -- saving rejects to file panel-plugin/model_volumes.c.rej
patching file panel-plugin/model_volumes_notify.c
patching file panel-plugin/model_volumes_notify.h
patching file panel-plugin/view.c
Hunk #1 succeeded at 59 (offset 2 lines).
Hunk #2 succeeded at 69 (offset 2 lines).
Hunk #3 succeeded at 458 (offset 2 lines).
Hunk #4 FAILED at 541.
Hunk #5 succeeded at 950 (offset -10 lines).
1 out of 5 hunks FAILED -- saving rejects to file panel-plugin/view.c.rej
patching file panel-plugin/xfce46-compat.c
patching file panel-plugin/xfce46-compat.h

Revision history for this message
In , Jan Rękorajski (baggins-pld-linux) wrote :

Created attachment 3507
patch for clean 1.2.0

This patch applies to clean 1.2.0 sources.

Revision history for this message
In , Jan Rękorajski (baggins-pld-linux) wrote :

(In reply to comment #8)
> (In reply to comment #7)
> > Created attachment 3497 [details]
> > port to gio
> >
> > Here is the patch :)
> > Please check and test, this patch is a shameless rip from xfdesktop.
>
> What to apply this patch to? Neither the latest 1.2.0 nor the latest git seems
> to work. Here’s the output from trying to patch the git version:
>

It applies to 1.2.0 on top of exo-1 (id:5754) and libxfce4ui (id:7317) patches.
I added a patch for clean 1.2.0 sources.

summary: - should allow opening non-removable partitions
+ should allow opening non-removable partitions (port to Gio)
Revision history for this message
In , sledgehammer999 (sledgehammer-999) wrote :

Would you guys be interested in a complete rewrite instead? (using C++ and gtkmm/glibmm)

Revision history for this message
In , Yves-Alexis Perez (corsac) wrote :

(In reply to comment #11)
> Would you guys be interested in a complete rewrite instead? (using C++ and
> gtkmm/glibmm)

Definitely not.

Revision history for this message
In , Jannis Pohlmann (jannis-xfce) wrote :

Let's put it this way: we don't use C++ anywhere in Xfce core, so if it can be avoided, extensions should be written without additional dependencies/libraries to be loaded.

Revision history for this message
In , sledgehammer999 (sledgehammer-999) wrote :

Ok. I totally get Jannis Pohlmann's reasons. But from Yves-Alexis Perez's reply I have to ask this. Is the Xfce's team stance against C++(in general) the same as the Gnome's/Gtk's team? (not exactly hating it but not actively supporting it etc etc)

Revision history for this message
In , Yves-Alexis Perez (corsac) wrote :

(In reply to comment #14)
> Ok. I totally get Jannis Pohlmann's reasons. But from Yves-Alexis Perez's reply
> I have to ask this. Is the Xfce's team stance against C++(in general) the same
> as the Gnome's/Gtk's team? (not exactly hating it but not actively supporting
> it etc etc)

(note that I'm not in the Xfce team, not as an active developer at least, I'm a Debian maintainer)

As Jannis said, the whole Xfce stack uses C/GTK+. C++ and Gtkmm looks to me more like a cludge.

Personally, I'm really not a huge fan of C++, but there are people using Vala, in case you'd be interested.

Revision history for this message
In , Jannis Pohlmann (jannis-xfce) wrote :

We evenhave our own GLib/GTK+ C++ bindings but they are not really actively maintained, I think, and they are not used anywhere. We also don't use glibmm/gtkmm anywhere as it makes little sense for us.

The benefit of C++ over C is rather small overall.

Revision history for this message
In , sledgehammer999 (sledgehammer-999) wrote :

I'd love to continue this but I don't want to pollute the bug report.
For now, I hope that the patch gets finally in git. It seems to work fine in Debian. But before that please clean up the code that is related to this report of mine: https://bugzilla.xfce.org/show_bug.cgi?id=7666

Revision history for this message
intherye (intherye) wrote :

I recommend this package for SRU, because it (1) has an obviously safe patch and (2) affects an application rather than critical infrastructure packages (like X.org or the kernel).

- It impacts all users of xfce4 using the default config, confronting them with an error message when they try to mount a removable device: "Failed to mount "DATA. Failed to execute child process "exo-mount" (No such file or directory)."

- This bug has been fixed in xfce4-places-plugin-1.2.0-3 from oneiric. I installed this version in natty and didn't have any problems so far, the error message disappeared and the plugin is working as expected. Version 1.2.0-3 fixes upstream bug #6663

- TEST CASE: Plug in an USB drive. Try to mount and unmount the drive. Receive above error message.

Changed in xfce4-places-plugin (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Micah Gersten (micahg) wrote :

Thank you for recommending the SRU. However, since it's a 1600+ line patch and a new feature (places accessing volumes through GIO), I don't think this would be a good candidate for an SRU. However, you can file a backport request against the natty-backports project. Instructions for filing this request are here: https://help.ubuntu.com/community/UbuntuBackports

Revision history for this message
intherye (intherye) wrote :

I would rather call it a bug fix, not a new feature, because exo-mount is no more present in natty, and thus the user gets an error message. I don't think that's desired for a default installation.

Revision history for this message
Micah Gersten (micahg) wrote :

The plugin isn't in the default installation. This was one of the reasons it was dropped IIRC.

Revision history for this message
Nick Holloway (nwholloway) wrote :

Although it may not be default in 11.04, it was included and part of the default panel configuration for earlier Xubuntu releases, so anyone upgrading to 11.04 will be met with the error message.

This is a functionality regression for existing Xubuntu users.

Revision history for this message
Lionel Le Folgoc (mrpouit) wrote :

Yup, the patch is not suitable for SRU (also, I didn't include it in natty because of that, too big and too late). It's fine for a backport though, feel free to request it.

Indeed, xfce4-places-plugin was dropped from the default install because it wasn't ported and still using exo-mount at that time. Yes, this is a regression, that's unfortunate, but it'll stay like that in natty, sorry.

Revision history for this message
In , Landry-o (landry-o) wrote :

Mass-reassign all bugs from florian@ to goodies-dev@, thanks for the maintenance work! (and sorry for the bugmail spam..)

Changed in xfce4-places-plugin:
importance: Unknown → Wishlist
status: Unknown → Confirmed
Changed in xfce4-places-plugin:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.