Closed Bug 582621 Opened 14 years ago Closed 14 years ago

Sharing back-end for MeeGo

Categories

(Firefox for Android Graveyard :: General, defect)

All
MeeGo
defect
Not set
normal

Tracking

(fennec2.0b2+)

RESOLVED FIXED
Tracking Status
fennec 2.0b2+ ---

People

(Reporter: mbrubeck, Assigned: moz_poro)

References

Details

Attachments

(2 files, 1 obsolete file)

Allow the new Sharing feature in Fennec 2.0 to discover, list, and launch
third-party Maemo/MeeGo applications.
Blocks: 583135
We need to look into the Maemo/Meego application registry, or maybe the *.desktop files. We need to come up with a way to discover that an application can handle certain types of data.

Or maybe we need a way for an application to say "You can pass me data, like text snippets and URLs, using this DBus method"
tracking-fennec: ? → 2.0b1+
Assignee: nobody → mbrubeck
For your information, MeeGo Touch ShareUI provides ShareUiInterface() class with Share() method to share data of following form with supported methods (email, sms, ?).

"data:text/x-url;title=This%20is%20title;description=And%20this%20is%description,http%3A%2F%2Fstore.ovi.com"

In addition to actual content (url, text snippets, ...), it supports "title" and "description" fields that are included in shared data. 

Attached is relevant parts of our test extension that uses this share-ui interface to share bookmark URLs. This results MeeGo Touch Share UI being shown which user can use to select the method of sharing.
Arto - is the share-ui interface documented anywhere? I am wondering if we can do more than just blindly hand off to the app. I want to be able to enumerate the possible handlers too.
I don't know if there's public documentation available or what's the status of the API. I'll ask around and study the code to see what is and will be there.
Mark, we spoke to MeeGo people in charge of the API and their take is simple. Apps are expected to blindly set mime type for data and let the framework do the dirty work. They are quite solid in their opinion, because it was revisited several times already. 
Currently for media they support already Youtube, Picasa, Flickr and Bluetooth/MMS
For url they support already Facebook, Twitter, Email, and SMS.

So that doesn't sound really bad to me at all.
Also, Sharing framework is now in the process of going open.
Additionally, by using Share FW users immediately take advantage of SSO built-in.
Unassigning - somebody with a MeeGo dev environment should work on integrating this into Fennec.  It will eventually use the interface sketched out here:  http://etherpad.mozilla.com:9000/sharing-interface

I can try to work on this if necessary, but I'll need to see if I can run MeeGo under scratchbox/x86 with Xephyr.
Assignee: mbrubeck → administration
Note: If getSharingApps returns just one result on MeeGo, then we will invoke that app immediately rather than displaying an in-browser UI to select an app.
I have access to MeeGo dev environment, so I can take this.
Assignee: administration → nobody
moving to beta 2, but we definitely need some Meego help to move this forward.
tracking-fennec: 2.0b1+ → 2.0b2+
Assignee: nobody → moz_poro
Status: NEW → ASSIGNED
Depends on: 598268
tero any update?
(In reply to comment #11)
> tero any update?

I have a working MeeGo back end which is based on bug 582616. However, my work depends on a yet unfixed bug on MeeGo libraries, so it is not really generally usable yet. Basically a MeeGo sharing interface is currently missing pkg-config support.
> usable yet. Basically a MeeGo sharing interface is currently missing pkg-config
> support.

Tero do we have blocker bug against Meego sharing interface component?
Attached patch Patch (obsolete) — Splinter Review
Patch which uses the interfaces and services introduced in bug 582616. Works with Fennec version which has the patch from bug 598269.

Meego sharing interface has been updated in their repository (the missing pkg-config...). I don't know yet when it will be released.
Attachment #480585 - Flags: review?(mark.finkle)
Comment on attachment 480585 [details] [diff] [review]
Patch

stealing review.
Attachment #480585 - Flags: review?(mark.finkle) → review?(doug.turner)
Comment on attachment 480585 [details] [diff] [review]
Patch

how is MEEGOTOUCH different than MEEGOTOUCHSHARE?  Can you ever have a MEEGOTOUCH thing without MEEGOTOUCHSHARE being defined?  Can we use MEEGOTOUCH?

@@ -115,6 +115,8 @@ NS_GENERIC_FACTORY_CONSTRUCTOR(nsDBusHan
 #endif 
 #ifdef ANDROID
 NS_GENERIC_FACTORY_CONSTRUCTOR(nsExternalSharingAppService)
+#elif defined(MOZ_ENABLE_MEEGOTOUCHSHARE)
+NS_GENERIC_FACTORY_CONSTRUCTOR_INIT(nsExternalSharingAppService, Init)
 #endif


It would be really neat if you didn't need this Init() method.

 
+#ifdef MOZ_ENABLE_MEEGOTOUCHSHARE
+  mShareUiIf = new ShareUiInterface();
+#endif

you probably can just use this on first use.

+++ b/uriloader/exthandler/unix/nsExternalSharingAppService.cpp	Mon Oct 04 12:26:47 2010 +0100

How about making this specific to MEEGO and drop the #ifdefs inside this file?


+#ifdef MOZ_ENABLE_MEEGOTOUCHSHARE
+  delete mShareUiIf;
+#endif

You can just make mShareUiIf use nsRefPtr{} and this object will be deleted when the app service object is deleted.


+  if (!aMime.IsEmpty())
+    uri.setMimeType(QString::fromUtf16(aMime.BeginReading(), aMime.Length())); 
+  if (!aTitle.IsEmpty())
+    uri.setAttribute("title", QString::fromUtf16(aTitle.BeginReading(), aTitle.Length()));
+

Do you really have to test for emptiness?  


+  ShareUiInterface *mShareUiIf;

Please call this mShareUi.

Otherwise looks nice.
Attachment #480585 - Flags: review?(doug.turner) → review-
(In reply to comment #16)
> how is MEEGOTOUCH different than MEEGOTOUCHSHARE?  Can you ever have a
> MEEGOTOUCH thing without MEEGOTOUCHSHARE being defined?  Can we use MEEGOTOUCH?

I'll check this.

> It would be really neat if you didn't need this Init() method.

I will remove it.

> +++ b/uriloader/exthandler/unix/nsExternalSharingAppService.cpp    Mon Oct 04
> 12:26:47 2010 +0100
> 
> How about making this specific to MEEGO and drop the #ifdefs inside this file?

If is already MeeGo specific on the Makefile. I was thinking that maybe some day somebody will somewhere need to implement this for some other unix-variant. But how about if I rename it to something like nsMeegoExternalSharingAppService.cpp and remove the #ifdefs.

> +#ifdef MOZ_ENABLE_MEEGOTOUCHSHARE
> +  delete mShareUiIf;
> +#endif
> 
> You can just make mShareUiIf use nsRefPtr{} and this object will be deleted
> when the app service object is deleted.

I don't understand this. I think nsRefPtr objects should implement reference counting with AddRef and Release. ShareUiInterface does not do that, as it is a MeeGo object and not Mozilla object.

> +  if (!aMime.IsEmpty())
> +    uri.setMimeType(QString::fromUtf16(aMime.BeginReading(), aMime.Length())); 
> +  if (!aTitle.IsEmpty())
> +    uri.setAttribute("title", QString::fromUtf16(aTitle.BeginReading(),
> aTitle.Length()));
> +
> 
> Do you really have to test for emptiness?  

In fact no. The end result seems to be exactly the same. Will remove the test.
>But how about if I rename it to something like
>nsMeegoExternalSharingAppService.cpp and remove the #ifdefs.

Sounds great

> You can just make mShareUiIf use nsRefPtr{} and this object will be deleted
> when the app service object is deleted.

Sorry, I meant: nsAutoPtr
OS: Maemo → MeeGo
Summary: Sharing back-end for Maemo/MeeGo → Sharing back-end for MeeGo
Attached patch Updated patchSplinter Review
> Can you ever have a
> MEEGOTOUCH thing without MEEGOTOUCHSHARE being defined?  Can we use MEEGOTOUCH?

Ok, the current situation is that you can have Meego Touch without the sharing interface so currently this check is needed. However, this will propably change in the future. Maybe we should however now go with the current situation?
Attachment #480585 - Attachment is obsolete: true
Attachment #482447 - Flags: review?(doug.turner)
Doug - Review ping
Comment on attachment 482447 [details] [diff] [review]
Updated patch


>+nsExternalSharingAppService::nsExternalSharingAppService()
>+  : mShareUi(NULL)

nsnull instead of NULL.

nice work!
Attachment #482447 - Flags: review?(doug.turner) → review+
(In reply to comment #21)
> >+nsExternalSharingAppService::nsExternalSharingAppService()
> >+  : mShareUi(NULL)
> 
> nsnull instead of NULL.

Will somebody land this with this nsnull fix or will I make an updated patch?
i can push tomorrow w/ the fix.  thanks Tero
http://hg.mozilla.org/mozilla-central/rev/5176c8f2691e
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Depends on: 658725
You need to log in before you can comment on or make changes to this bug.