Bug 450784
Summary: | RFE: Enhance Thunar's 'Send to' menu | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Christoph Wickert <christoph.wickert> |
Component: | Thunar | Assignee: | Kevin Fenzi <kevin> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | christoph.wickert, pertusus, sundaram |
Target Milestone: | --- | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | 0.9.3-1.fc10 | Doc Type: | Enhancement |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-10-28 10:09:17 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Attachments: |
Description
Christoph Wickert
2008-06-10 23:51:30 UTC
Created attachment 308872 [details]
Screenshot of my Thunar 'Send to' menu
Created attachment 308873 [details]
Send to "Bluetooth OBEX Recipient" using sendto-bluetooth
Created attachment 308875 [details]
Send to "Audacious Playlist"
Note that this only is available for the filetypes that are listed in the
"MimeType" field.
Created attachment 308876 [details]
Send to "Bluetooth OBEX Recipient" using gnome-obex-send
This one is for Fedora <= 8
Created attachment 308877 [details]
Send to "Printer" using xfprint
Not sure if we should ship this because we don't want to encourage users to use
xfprint.
I don't object with adding those, but they should be added by the application that are launched. And it seems wrong to do this for thunar/xfce only, it should certainly be shared by freedesktop compliant desktops. Patrice, I can't follow you: /usr/share/Thunar/sendto is specific to Thunar, Nautilus doesn't have a counterpart and I doubt that Dolphin has. If we add these desktop files to their applications we would need to make them depend on Thunar, otherwise we will have (potentially) unowned directories. (In reply to comment #7) > Patrice, I can't follow you: /usr/share/Thunar/sendto is specific to Thunar, > Nautilus doesn't have a counterpart and I doubt that Dolphin has. Indeed, I am not saying that it exists in other desktops, but that it doesn't really makes sense to do it only in one desktop. This is something that should be submitted to freedesktop such that something common emerges. > If we add these desktop files to their applications we would need to make them > depend on Thunar, otherwise we will have (potentially) unowned directories. There are more than one way to solve that issue (very similar with the plugins issue), they can either be in a subpackage that depends on thunar, os own /usr/share/Thunar and /usr/share/Thunar/sendto too, or have those 2 directories be in a filesystem-like package. The other possibility would be to have thunar itself depend on the application referred to in the sendto .desktop files. But in any case it seems wrong to me to add this in thunar without making sure that the corresponding application is installed. (In reply to comment #8) > Indeed, I am not saying that it exists in other desktops, but that it > doesn't really makes sense to do it only in one desktop. This is > something that should be submitted to freedesktop such that something > common emerges. I agree that this feature is interesting for other desktops/file managers as well, but as long as it's not for me it's perfectly fine to support/enhance it in those file mangers where it's available. > There are more than one way to solve that issue (very similar with > the plugins issue), they can either be in a subpackage that depends on > thunar, os own /usr/share/Thunar and /usr/share/Thunar/sendto too, > or have those 2 directories be in a filesystem-like package. > > The other possibility would be to have thunar itself depend on the > application referred to in the sendto .desktop files. But in any case > it seems wrong to me to add this in thunar without making sure that > the corresponding application is installed. As mentioned before Thunar will take care of this. If the command is not found in $PATH thunar will not display the menu entry, so I don's see a problem here. (In reply to comment #8) > The other possibility would be to have thunar itself depend on the > application referred to in the sendto .desktop files. To me this is a _really_ bad idea, because this would mean making Thunar depend in audacious, xfprint and so on. Subpackages might be a working approach, but IMO this is just to much overhead for a single 1 or 2 KB file. If an application has the ability to detect things at runtime IMHO we don't need to introduce superfluous deps. (In reply to comment #9) > I agree that this feature is interesting for other desktops/file managers as > well, but as long as it's not for me it's perfectly fine to support/enhance it > in those file mangers where it's available. Indeed, I agree that this should stop us from doing something for thunar. (In reply to comment #10) > Subpackages might be a working approach, but > IMO this is just to much overhead for a single 1 or 2 KB file. If > an application has the ability to detect things at runtime IMHO we > don't need to introduce superfluous deps. To it would be more logical to have those files installed by the packages themselves even if there is auto-detection. There is no need of subpackage if the packages installing the .desktop file also own the directories, or there is a -filesystem package. (In reply to comment #11) > (In reply to comment #9) > > > I agree that this feature is interesting for other desktops/file managers as > > well, but as long as it's not for me it's perfectly fine to support/enhance it > > in those file mangers where it's available. > > Indeed, I agree that this should stop us from doing something for thunar. Should have been 'I agree that this should not stop us from doing something for thunar'. It would be nice if upstream tried to do something in freedesktop, though. (In reply to comment #11) > To it would be more logical to have those files installed by the > packages themselves even if there is auto-detection. I agree it would be more logical but IMHO it is more important that we - the Xfce maintainers - remain in control of what is installed in /usr/share/Thunar/sendto. Think about updates, for example if Thunar switches to another approach in Xfce 4.6 or if fdo specs change. Do you really want to push updates for audacious, bluez-gnome and so on then? (In reply to comment #13) > (In reply to comment #11) > > To it would be more logical to have those files installed by the > > packages themselves even if there is auto-detection. > > I agree it would be more logical but IMHO it is more important that we - the > Xfce maintainers - remain in control of what is installed in > /usr/share/Thunar/sendto. Think about updates, for example if Thunar switches to > another approach in Xfce 4.6 or if fdo specs change. Do you really want to push > updates for audacious, bluez-gnome and so on then? If fdo specs change, yes. But if solely xfce changes, no. Indeed centralized management of the sendto menu is possible, still I think decentralizing it would be better. There are examples of both type, selinux is still very centralized, while pam configuration or the hicolor theme are decentralized. In the end, doing how you prefer is best since there is no obvious better way. Added thunar-sendto-bluetooth.desktop and thunar-sendto-audacious-desktop to thunar-0.9.3 in rawhide. Closing. |