Comment 1 Andre Klapper 2009-10-10 14:26:03 UTC

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

Comment 6 Andre Klapper 2009-10-14 18:51:02 UTC

Whou, 38 votes in two days. I'm impressed by the community (in a positive way).

Comment 7 Ryan Abel 2009-10-14 19:30:52 UTC

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.

Comment 9 Tim Samoff 2009-10-21 21:58:29 UTC

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.

Comment 11 Tim Samoff 2009-10-22 06:39:25 UTC

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.

Comment 13 Tim Samoff 2009-10-22 16:41:38 UTC

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.

Comment 17 Andre Klapper 2009-10-30 14:53:18 UTC

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

Comment 19 Tim Samoff 2009-10-30 15:19:44 UTC

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.

Comment 22 Tim Samoff 2009-10-30 15:40:06 UTC

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.

Comment 27 Andre Klapper 2009-10-30 17:14:13 UTC

(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.

Comment 29 Andre Klapper 2009-10-30 17:25:21 UTC

(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. :-/

Comment 30 Tim Samoff 2009-10-30 17:30:56 UTC

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.

Comment 33 Andre Klapper 2009-10-30 18:00:37 UTC

(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).

Comment 34 Andre Klapper 2009-10-30 18:42:55 UTC

(In reply to comment #24)
> Andre, can you help bringing this to the attention of the right people? :)

Voting is definitely welcome. :)

Comment 35 Faheem Pervez 2009-11-02 04:09:47 UTC

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...

Comment 36 Faheem Pervez 2009-11-15 03:05:06 UTC

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?

Comment 38 Faheem Pervez 2009-11-16 01:17:17 UTC

(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! :)

Comment 39 Faheem Pervez 2009-11-16 19:57:58 UTC

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").

Comment 43 Andre Klapper 2009-11-19 13:45:12 UTC

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?

Comment 44 Faheem Pervez 2009-11-20 09:48:57 UTC

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.

Comment 45 Faheem Pervez 2009-11-20 09:50:45 UTC

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.

Comment 46 Andrew Flegg 2009-11-20 12:42:54 UTC

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

Comment 48 Tim Samoff 2009-11-20 13:39:58 UTC

(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.

Comment 49 Faheem Pervez 2009-11-20 16:10:56 UTC

(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.

Comment 50 Tim Samoff 2009-11-20 16:24:44 UTC

(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...

Comment 52 Andre Klapper 2009-11-30 15:12:45 UTC

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

Comment 53 Quim Gil 2009-12-07 09:46:11 UTC

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.

Comment 54 Quim Gil 2009-12-15 07:48:09 UTC

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.

Comment 57 Andre Klapper 2009-12-15 13:46:59 UTC

(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

Comment 61 Andre Klapper 2009-12-15 14:28:33 UTC

(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"?

Comment 65 Andre Klapper 2009-12-16 15:46:47 UTC

(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?

Comment 67 Andre Klapper 2009-12-16 15:57:55 UTC

(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!

Comment 71 Andre Klapper 2009-12-21 18:38:38 UTC

(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).

Comment 73 Andre Klapper 2010-01-13 15:54:21 UTC

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/

Comment 74 Tim Samoff 2010-01-13 16:06:02 UTC

(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.

Comment 75 Johan Hedberg 2010-01-13 16:37:03 UTC

*** 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)

Comment 81 Andre Klapper 2010-03-15 20:56:52 UTC

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).