maemo.org Bugzilla – Bug 5300
Support sending files via Bluetooth in file manager
Last modified: 2010-03-15 20:56:52 UTC
You need to log in before you can comment on or make changes to this bug.
STEPS TO REPRODUCE THE PROBLEM: Go to the file manager and select a normal file (no image, video, etc) EXPECTED OUTCOME: There is an option in the app menu or context menu to send the file via Bluetooth ACTUAL OUTCOME: It is not possible from the UI to send files via Bluetooth. REPRODUCIBILITY: always
This is not planned to be provided for Fremantle. Bluetooth functionality is provided via "Sharing" in several applications (e.g. image viewer) but not in the file manager itself unfortunately.
HAVING BLUETOOTH SEND CAPABILITY IS A NECESSITY FOR FILE TRANSFER IN FILE MANAGER.
Please allow the transferring of files via Bluetooth.
I think this feature should not be left behind. Even my 3 year old phone does that. Linux is able to do this too.
Not having this or (more generally) the ability to browse OBEX devices is a huge downgrade from Maemo4. Also see this bug: https://bugs.maemo.org/show_bug.cgi?id=5325
Whou, 38 votes in two days. I'm impressed by the community (in a positive way).
Please note, comments should only be used to add relevant information to a bug not more "Me too!"'s. Voting is how you indicate your support of a particular bug.
I would prefer that file manager supports "Sharing" plugin, to be able to send files through bluetooth, network services, email, etc.
Bluetooth shouldn't be the only method of sharing within the File manager. Why not provide the same sharing experience that is available in the other apps? I should be able to choose photos/videos/whatever and share them not only via Bluetooth, but to services from the File manager just like the Media app or the Image app.
Consider Andre Klapper's comments. The maemo word for what we want to do is 'sharing'. Since the vectors / methods of sharing are file TYPE dependent, the sharing is exposed via apps designed to ~share~ with the compatible services (flickr, bluetooth for photos for e.g.). So the workflow envisioned by nokia/maemo (afaik) is to open the file with the viewer app, ~then~ select whatever sharing function is available. I along with other voters would like to have bluetooth file send - filetype agnostic - via file manager though.
Right, but there are really only three methods of "sharing" included with the other applications: 1. Share via Email 2. Share via Service 3. Share via Bluetooth These are included with both the Media Player and the Photos app. Why couldn't the same three options be available within the File manager?
A file manager would then be a catch-all app regarding MIME types. The "service" to use for sharing, from a file manager POV, should be a file server, right? That would allow to include sharing via wifi, as well.
Not exactly... "Service" refers to API (e.g., Flickr). Currently there is not a "share via wifi" option in any official app.
A part from the usage pattern, there is no way, for example, to send PDF files via bluetooth.
(In reply to comment #10) > Consider Andre Klapper's comments. The maemo word for what we want to do is > 'sharing'. > > Since the vectors / methods of sharing are file TYPE dependent, the sharing is > exposed via apps designed to ~share~ with the compatible services (flickr, > bluetooth for photos for e.g.). > > So the workflow envisioned by nokia/maemo (afaik) is to open the file with the > viewer app, ~then~ select whatever sharing function is available. > > I along with other voters would like to have bluetooth file send - filetype > agnostic - via file manager though. And also sending through email. So, I would just enable "Sharing" in file manager (for consistency with other apps). My proposal of use case: 1. Tap on "Share" (be it in menu or in toolbar). 2. Select the files you want to share (in an edit mode). 3. Tap on edit mode "action button", which would be labeled as "Share". 4. Show the sharing dialog with at least bluetooth and email options. 4b. Alternate/would be better. Check the file types of the selected files and show also "share with service" if the mime types allow to send _all_ the files with a service.
(In reply to comment #10) > Consider Andre Klapper's comments. The maemo word for what we want to do is > 'sharing'. > > Since the vectors / methods of sharing are file TYPE dependent, the sharing is > exposed via apps designed to ~share~ with the compatible services (flickr, > bluetooth for photos for e.g.). > > So the workflow envisioned by nokia/maemo (afaik) is to open the file with the > viewer app, ~then~ select whatever sharing function is available. > > I along with other voters would like to have bluetooth file send - filetype > agnostic - via file manager though. > This is a complete misunderstanding of the required workflow. Sharing is the indesriminate availability of information with other parties who may, or may not consume that information. What has been requested is a specific means of transfering file wirelessly to/from the device without the need to have a specific application for it. The process is more akin to email but funnily enough sending yourself things via email just to move it to another device is not always desirable or sensible.
So if most people here agree that the "Sharing" functionality of other apps should be integrated, bug 5930 is a duplicate.
More than "Sharing" (I don't expect FM to share my images via Flickr), I complain about a "Send via" functionality. Aniello
Sorry, but I think it's semantics -- and a pretty major UX issue. If it's called Sharing, it should be called Sharing everywhere (whether it's to Flickr or via Bluetooth). If it's called Sending, it should be called Sending everywhere -- even in the Photo app. My preference is calling it Sharing.
I am speaking from a Developer point of view. There are documented APIs for the "Sending via"[1] functionality and not yet documented APIs for "Sharing via" (services)[2] functionality. What I miss in the FM is the "Sending via" one. Aniello [1] http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Using_Data_Sharing/SendVia_Functionality [2] http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Using_Data_Sharing/Sharing_Plug-in
I would still insist on addressing bug #5325 ("Browsing other devices via BT OBEX in the File Manager") rather than this one though. For following reasons: 1. It is a more useful feature than just "sharing" (or "sending", whatever you prefer) a single file. 2. It has been available in Maemo4, so the current situation is a regression. 3. It is more politically correct, as it does not directly imply sharing [copyrighted] media.
Note: Sharing doesn't just have to do with single files. By selecting "Share" as the function, it puts the user in 'multi-select' mode (see the Photo app). After selecting files and tapping the Share button, the user is prompted to select how to Share. Now, moving onto browsing other devices... That is a great function. But, what about sharing/sending files to an email? If someone is in the FM and would like to attach multiple files to an email, they wouldn't be able to do it -- and would have to attach the files manually from the Email app (which has it's own set of issues).
(In reply to comment #21) > I would still insist on addressing bug #5325 ("Browsing other devices via BT > OBEX in the File Manager") rather than this one though. For following reasons: > > 1. It is a more useful feature than just "sharing" (or "sending", whatever you > prefer) a single file. > 2. It has been available in Maemo4, so the current situation is a regression. > 3. It is more politically correct, as it does not directly imply sharing > [copyrighted] media. Browsing other devices via OBEX is only possible if the devices are paired and "trust one another". That's not the case for a situation where I meet someone and I want to send them a file, but don't want to pair both devices, so it's completely different and each request has its own purpose.
If the file manager would be open source (hint, hint), we could have easily added the send via bluetooth and via e-mail functionality ourselves (and packaged it up as a community package with another name in case Nokia does not want our patches). So, what's the next step to get this implemented? Let me guess: * We need to get a definitive word from the UX designers how the feature should be called/where it should be placed * Release a first update that adds "Send via Bluetooth" and "Send via E-Mail" functionality * Later (when the "Sharing" API is exposed) get the additional features in (I personally don't need this, but the comments suggest that there is a use for that?) Andre, can you help bringing this to the attention of the right people? :)
(In reply to comment #24) > If the file manager would be open source (hint, hint), we could have easily > added the send via bluetooth and via e-mail functionality ourselves (and > packaged it up as a community package with another name in case Nokia does not > want our patches). Osso-XTerm has been open source for quite a while. How many requested enhancements have been added to it by the community?
(In reply to comment #25) > Osso-XTerm has been open source for quite a while. How many requested > enhancements have been added to it by the community? Quite a few (not all of them requested, sometimes it's easier to just do it), though not all have been ported to the Fremantle version yet.
(In reply to comment #25) > Osso-XTerm has been open source for quite a while. How many requested > enhancements have been added to it by the community? That's off-topic, but an easy one: Patch in 4916 was committed. Patch in 3071 became obsolete 2 months later. Patches in 2679 and 3618 did not apply for Fremantle anymore due to UI changes. Patch in 3686: Asked the reporter to upstream as I prefer to keep the list of downstream diff's small and as I'm not sure whether the patch makes sense. Patch in 4914: Still waiting. So what's your conclusion here, luarvique?
(In reply to comment #27) > That's off-topic, but an easy one: > ... > So what's your conclusion here, luarvique? Mmm, maybe I misunderstood something, but I have been asking of whether there were any community releases of the open-sourced Osso-XTerm, not about patches being integrated by Nokia itself. The reason why I asked was to assert whether open sourcing File Manager would lead to a community release of this program.
(In reply to comment #28) > Mmm, maybe I misunderstood something, but I have been asking of whether there > were any community releases of the open-sourced Osso-XTerm, not about patches > being integrated by Nokia itself. The reason why I asked was to assert whether > open sourcing File Manager would lead to a community release of this program. Ah, sorry. I totally got you wrong it seems. :-/
I don't know if this will help the report, but I was just asked to explain how sharing works in the Photos app. Quite possibly, this explanation will allow others to visualioze how it might also work in the File Manager. --- The Photos app (just like many apps) has a "Main Menu" that is accessed by clicking the title bar of the application. In this menu, one of the options is "Share images" (which, imo, should just be "Share," but that's beside the point). Choosing that option sends you back to the thumbnails, with a simple change in the UI: there's now a "Share" button at the top of the thumbnail window. At this point, you can select one, or many, images by simply clicking the thumbnails and highlighting them. When finished, click the "Share" button at the top of the window. Doing this brings up an overlay menu from the bottom of the screen with these options: "Send via Bluetooth," "Share via service," and "Send via E-mail." Selecting "Bluetooth" brings up a "Send to a device" menu where you can choose from a list of trusted Bluetooth devices. Selecting "service" triggers a "Wizard" in which you can title, tag, locate the images, select the service that you want to use, set the options for the service, etc. Clicking "Share" then sends the images to the service. Finally, selecting "E-mail" opens Modest and has auto-attached the image(s) to the new e-mail.
(In reply to comment #28) > Mmm, maybe I misunderstood something, but I have been asking of whether there > were any community releases of the open-sourced Osso-XTerm, not about patches > being integrated by Nokia itself. The reason why I asked was to assert whether > open sourcing File Manager would lead to a community release of this program. The reason why I mentioned "community release" was because I thought that in case Nokia won't accept our patches for UX/UI/QA/legal issues or some other reasons, we would still have an option to do a "fork" and package it up as "Extended File manager" or whatever. My intention was not to suggest that the release of the official file manager is taken over by the community, sorry if "community release" was the wrong wording for that. "Community fork" would have been more to-the-point, I guess. Can we continue the discussion as per comment 24 (i.e. define the next steps and see how we can move this forward)?
(In reply to comment #31) > Can we continue the discussion as per comment 24 (i.e. define the next steps > and see how we can move this forward)? I guess the first thing to do would be to contact Quim about possible open-sourcing of the File Manager. Without that, the rest of the planes does not make sense.
(In reply to comment #32) > I guess the first thing to do would be to contact Quim about possible > open-sourcing of the File Manager. Just file a separate enhancement request in bugs.maemo.org (and provide good arguments).
(In reply to comment #24) > Andre, can you help bringing this to the attention of the right people? :) Voting is definitely welcome. :)
Created an attachment (id=1527) [details] Add "Send via Bluetooth" to Details dialog First things first: This is not a proposed solution, and nor is it intended to be one; it still does not technically add a nice file item in the menu for this. But I am getting worried with 59 votes and no response from Nokia so far. This patch is against the details dialog, part of libhildonfm (the only open-sourced part of the File manager), to add a button which allows a file to be sent via Bluetooth. The details dialog can be accessed from the File manager by doing a tap and hold on a file. Again, it is not a solution but if you really need to send files from the File manager and know how to recompile libhildonfm...
Created an attachment (id=1585) [details] Add "Share" to File manager's Details dialog OK, after figuring out the function signature of one of sharing-dialog's functions (http://qwerty12.qole.org/sharing-dialog-example.c) (Also, see: #6177. Should explain the use of dlsym()...), I thought I'd update the patch to give full sharing ability via a button in the File manager's Details dialog for a chosen file. So you can "Send by Bluetooth", "Send via Service, etc.
(In reply to comment #36) > Created an attachment (id=1585) [details] [details] > Add "Share" to File manager's Details dialog Tried out your patch today and it works great. It might not be obvious for "normal" users, but it allows power users to use that feature. Obviously also works in all apps that use the details dialog (tested with Notes, PDF reader, Sketch), which is great :) One minor problem is that it allows to share arbitrary files with services (e.g. sharing a MP3 file with Flickr), although I have not tried to see what happens when doing so. Any chance of getting this integrated "upstream", so we don't have to patch the source and build our own version every time a new release of libhildonfm comes out?
(In reply to comment #37) > (In reply to comment #36) > > Created an attachment (id=1585) [details] [details] [details] > > Add "Share" to File manager's Details dialog > > Tried out your patch today and it works great. It might not be obvious for > "normal" users, but it allows power users to use that feature. Obviously also > works in all apps that use the details dialog (tested with Notes, PDF reader, > Sketch), which is great :) > There's actually a problem with that... If you use the details dialog from the PDF Reader and press "Share" (or the localised equiv.), close the dialog, and press "Share" again, you'll notice the PDF Reader crashes, due to it trying to load the symbol again. I qill have to move the dlopen() and dlsym() calls to the init functions of the dialog, and dlclose() in the dialog's finalize method... > One minor problem is that it allows to share arbitrary files with services > (e.g. sharing a MP3 file with Flickr), although I have not tried to see what > happens when doing so. > I've noticed that, too, and all I can do is blame the sharing-dialog for not checking. :) (The functions that libsharingdialog calls, BTW, to display that sharing service dialog are also missing publically released headers...) > Any chance of getting this integrated "upstream", so we don't have to patch the > source and build our own version every time a new release of libhildonfm comes > out? > This patch is here as a "just-in-case" thing; i.e. if Nokia continue to ignore this bug forever. ATM, the patch has these problems: * Causes the PDF Reader to lock-up when re-entering the Sharing dialog (will move the dl* calls out of the callback function); * What you said: Allows you to share arbitrary files on a service (WONTFIX: Out of my control, and any functions that may allow me to check for this also do not have publically available headers. Not to mention I have no idea how to actually manipulate the dialog myself.); * It's using dlopen() and co. to utilize a function Nokia would prefer you not know about; * The addition of the button does not take into account any extra fields added by an application to the details dialog (See the Share button in the details dialog activated via the PDF Reader - it's above the Author field, instead of being at the bottom) (Will see if I can figure out a solution) and; * Better error-checking is required. (Will fix.) Anyway, glad you find it useful! :)
Created an attachment (id=1588) [details] [IMPROVED] Add "Share" button to File manager's Details dialog Alas, PDF Viewer still locks up when re-opening the Details dialog after closing it and pressing "Share" again. But after killing my N900 (no, "no-lifeguard-reset" doesn't help as it won't connect to my router. Oh well.) by trying to forgo dlopen, I couldn't care less. If someone does see the problem, please fix it and upload a new patch. On the plus side: * Better error checking; * dlopen stuff carried out at the initialization of the dialog; and * The "Share" button is always at the bottom of the dialog now.
Faheem, YOU ROCK.
how do we apply the patch?
(In reply to comment #41) > how do we apply the patch? You can build a version of libhildonfm2 with the patch applied like this: 1. In the SDK (Scratchbox), switch to the FREMANTLE_ARMEL target ("sb-conf select FREMANTLE_ARMEL") 2. "apt-get build-dep libhildonfm2" 3. "apt-get source libhildonfm2" 4. change into the extracted source directory 5. "patch -p1 < /path/to/faheemspatch" 6. "dpkg-buildpackage -b -rfakeroot" 7. You'll find the binary .debs in the parent directory 8. Copy the libhildonfm .deb to your device and open the X-Terminal 9. "sudo gainroot" 10. "dpkg -i filename.deb" Whenever a new version of the package is released, you have to do the same procedure again (after an "apt-get update").
So the "only" side effects are those mentioned in comment 38 and 39 so far? Can any other testers please also mention any issues they run into here?
Created an attachment (id=1603) [details] Add "Share" button to File manager's Details dialog Made some changes. It now has a nice "Share" icon to go with the label, the GLib whore in me said to use GModule, and the PDF Viewer doesn't crash anymore.
Created an attachment (id=1604) [details] DEB of libhildonfm2 with the above patch applied. Since Andre wants testers, I thought I'd put up a DEB. And in one of my trademark arrogant moments, let me claim: If you don't know how to use dpkg, you're not gonna be a good tester.
First impressions: 1) Installed deb 2) Rebooted 3) Details dialogue needs to be pushed a few pixels taller to get the whole button in; doable? 4) Sent a 32MB file to my windows laptop witout problems. No feedback that I could see that the file was being sent, though.
Just chiming in to state that this is not, of course, a proper bug fix. The FM application should be linked correctly against libsharing and make proper use of it. I hope some Nokian confirms they are willing to add this feature to FM or at least willing to open to us the sharing APIs. Aniello
(In reply to comment #45) > And in one of my > trademark arrogant moments, let me claim: If you don't know how to use dpkg, > you're not gonna be a good tester. > Definitely arrogant, because this is just so utterly not true. (In reply to comment #46) > No feedback that I could see that the file was being sent, though. > Yes, it needs the typical "File sent" yellow info banner that is used if using the "stock" Sharing functionality.
(In reply to comment #46) > First impressions: > > 1) Installed deb > 2) Rebooted > 3) Details dialogue needs to be pushed a few pixels taller to get the whole > button in; doable? Certainly. > 4) Sent a 32MB file to my windows laptop witout problems. > > No feedback that I could see that the file was being sent, though. > Blame Nokia, not me. Nokia's way of telling you is via the Bluetooth icon going blue. With the Details dialog open, the status area is not visible. Short of me hiding the dialog after it's made, it's not going to happen. (In reply to comment #47) > Just chiming in to state that this is not, of course, a proper bug fix. > The FM application should be linked correctly against libsharing and make > proper use of it. > > I hope some Nokian confirms they are willing to add this feature to FM or at > least willing to open to us the sharing APIs. > > Aniello > Of course it's not! I will be extremely pissed off if this bug is closed as FIXED due to this patch. Personally, having to use dlopen pisses me off. (In reply to comment #48) > (In reply to comment #45) > > And in one of my > > trademark arrogant moments, let me claim: If you don't know how to use dpkg, > > you're not gonna be a good tester. > > > > Definitely arrogant, because this is just so utterly not true. > > (In reply to comment #46) > > No feedback that I could see that the file was being sent, though. > > > > Yes, it needs the typical "File sent" yellow info banner that is used if using > the "stock" Sharing functionality. > I'm guessing you have not installed the deb, as that banner does indeed appear when the file has been sent.
(In reply to comment #49) > I'm guessing you have not installed the deb, as that banner does indeed appear > when the file has been sent. > Actually, I did (it's one of the few things I can still do from bed). ;) So, I must have missed it somehow. I will try again and keep my eyes peeled.
I tried Petrovich from Extras... it allows you to send any file from an external file mangager... very nice apps...
*** Bug 6453 has been marked as a duplicate of this bug. ***
Thanks to Faheem now http://maemo.org/downloads/product/Maemo5/petrovich/ exists. If you want to have this functionality out of the box then Brainstorm is the place to lobby for it.
The scope of bugs.maemo.org are bugs and only very specific and no-brainer enhancement requests. This report contains a feature request that is too generic for bugs.maemo.org. Please post this problem and propose your solution in Maemo Brainstorm instead: http://maemo.org/community/brainstorm/ More information: http://wiki.maemo.org/Maemo_brainstorm
Why do we need brainstorm for this? Shall this be changed for example to "Enhancement request"?
yeah this is confusing Brainstorm should be terminated not bugzilla. Bugzilla is not just for bugs but also enhancement request, you can vote for it, you can discuss it.. Now we have 2 different things to do stuff and this is just confusing when is it a brainstorm and when is it bugzilla? Maemo should just have 1 thing to do bugs and feature request. not 2.
(In reply to comment #56) > yeah this is confusing > Brainstorm should be terminated not bugzilla. Bugzilla is not going to be "terminated". Please don't spread false rumours. In general, this has all been discussed several times already. Check the forums, the mailing list archives, .... Bugzilla is definitely *not* the place to discuss Brainstorm. ;-)
While I do agree that Brainstorm is very useful to discuss new requests, I think this is an enhancement request that perfectly fits into the bugzilla "Enhancement Request" severity option. There's nothing more that needs to be discussed rather than "we want it, will you add it to FM?" This is a "little "enhancement", not a brand new idea that fits Brainstorming. My two cents. Aniello
(In reply to comment #58) > This is a "little "enhancement", not a brand new idea that fits Brainstorming. I agree. This is a minor enhancement. Some file types are already supported (images, videos, etc.). All that has to be done is support all files, regardless of file type.
Aniello and Donn remarks exactly back my point that i have with this (pretty much all my monitored and voted bugs are going down this way) I created a talk thread about this. http://talk.maemo.org/showthread.php?p=428802#post428802
(In reply to comment #59) > All that has to be done is support all files, regardless of file type. Codewise that might be true. But often there can be non-coding requirements, like writing docu, get code reviews by a legal department, Protocol implementation conformance statements to get, and and and... (Just trying to make it a bit easier for everybody to understand that things aren't always that easy for companies that sell products with warranties etc)
We need to re-certify the bluetooth stack for this. That makes this a non-trivial effort. We are working on it, but it will take some time.
Simple solution to the confusion: REMOVE ENHANCEMENT FROM SEVERITY :)
(In reply to comment #62) > We need to re-certify the bluetooth stack for this. That makes this a > non-trivial effort. We are working on it, but it will take some time. Why do you need certification for this? It is already working for images for example. What is the difference for a BT between image and "just another format"?
(In reply to comment #64) > (In reply to comment #62) > > We need to re-certify the bluetooth stack for this. That makes this a > > non-trivial effort. We are working on it, but it will take some time. > > Why do you need certification for this? It is already working for images for > example. What is the difference for a BT between image and "just another > format"? Supporting "images" and support "any kind of files" are different categorizations and hence supporting the latter would require re-certification.
what is then exactly the difference for the filemanager if you compare it with the simple app Petrovich? That very simple app is in basic a filemanager that can send any files through bluetooth.. Why would then be extra re-certification be needed for the bluetooth stack if you just change the filemanager to just do what Petrovich already does?
(In reply to comment #66) > what is then exactly the difference for the filemanager if you compare it with > the simple app Petrovich? Petrovich is "private" software, filemanager is official and hence part of a warranty provided by a company. But this is getting offtopic...
I, for one, am interested and glad to hear details about the inner workings of Nokia's product process, like certification. I don't consider that to be off-topic, since knowing the reasons for "it will take some time" is better than just hearing "it will take some time". Now meta-discussion of what is on-topic and what isn't is certainly off-topic, and I apologize for abusing Bugzilla for this.
The above comments are what I also asked as the first thing. Yes, there is a separate check box in the certification papers that states: generic file transfer profile (or something like that), which is different than supporting just some file types (images and video).
Wow, 124 votes! So i'm not the only interested in this feature! Petrovich is great, but it would be very handy sharing through the file manager!
(Please avoid unneeded "me too" comments as they trigger mail to everybody subscribed here. Just vote. Thanks.)
For the file manager, this is still an issue in 2.2009.51-1. At least in the AppMenu and in the longpress (context) menu there is now way to send files via Bluetooth. Petrovich still works fine on 2.2009.51-1 (only tested Bluetooth file sending).
This has been fixed in package osso-filemanager 1:3038.3.1+0m5 which is part of the internal build version 2010.02-5 (Note: 2010 is the year, and the number after is the week.) A future public update released with the year/week later than this internal build version will include the fix. (This is not always already the next public update.) Please verify that this new version fixes the bug by marking this bug report as VERIFIED after the public update has been released and if you have some time. To answer popular followup questions: * Nokia does not announce release dates of public updates in advance. * There is currently no access to these internal, non-public build versions. A Brainstorm proposal to change this exists at http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
(In reply to comment #73) > This has been fixed in package > osso-filemanager 1:3038.3.1+0m5 > Should the keyword "success" (or something) be added as a way to find Maemo Bugzilla success cases? I think we need to start marking those cases in which Bugzilla makes a tangible difference in the OS.
*** Bug 7903 has been marked as a duplicate of this bug. ***
I am unable to find the magic 'Send via Bluetooth' button anywhere in File Manager so would not consider this as fixed.
(In reply to comment #76) > I am unable to find the magic 'Send via Bluetooth' button anywhere in File > Manager so would not consider this as fixed. > See comment #73. This is fixed in 2010.02 release, and we got 2009.51 yesterday. I guess we have to wait for a bit longer.
Also, please note that this will only be available in pr1.2. Having said that, in there, we also enable all of the other sharing options from FM, so, it's fun for all.
*** Bug 5930 has been marked as a duplicate of this bug. ***
Has this only been implemented to the file manager or also in other places (like the media player)
Setting explicit PR1.2 milestone (so it's clearer in which public release the fix will be available to users). Sorry for the bugmail noise (you can filter on this message).