Created attachment 167533 [details] [review]
First pass at implementing new sharing UI

mockup is here: http://www.dgsiegel.net/files/gnome-sharing-service.png

This is what it currently looks like:
http://img25.imageshack.us/img25/3198/newnst.png

What we need is:
- list of acceptable targets, including reasons why we should remove existing ones (such as the CD creator one, or the removable drives and shares one)
- review of the plugin API (possibly cleanups)
- UI mockups for in-application uploading
- proof of concept implementation of one of the facebook, flickr, picasa, youtube plugins
- Implementing a rough "type" detection, so we can fairly accurately mention "sharing 2 photos" or "sharing one video".

find my comments about the current plugin api below:

NstPluginInfo
  gchar *description;
  this is probably not needed anymore, except we want to use it as a tooltip

  get_contacts_widget ()
  we should rename this to simply get_widget, as the plugin will provide a 
  widget suitable for its service (see mockup for 2 examples). however, we
  could provide some sample widgets, as most services use a similar layout.

  init () and NstPluginCapabilities capabilities
  checking if folders and files are supported is a very good idea. additionally
  we should check if a service supports a mime type, either by letting the 
  plugin check it in init () and returning TRUE or FALSE or by adding a further 
  capabilities struct

a further thing we should consider is different languages: for example, python 
is a very nice language handling web stuff, c or vala are good enough to use
the local bindings, e.g. bluetooth or gnome stuff. 

afaik libpeas won't allow us to use different languages in the _same_ process,
is there a way to add more languages to it?
for us it is enough to have c only, but think about some users, who know some 
scripting languages like javascript or python. this way we could get many more plugins done

(In reply to comment #4)
> find my comments about the current plugin api below:
> 
> NstPluginInfo
>   gchar *description;
>   this is probably not needed anymore, except we want to use it as a tooltip

That's the label used in the treeview.

>   get_contacts_widget ()
>   we should rename this to simply get_widget, as the plugin will provide a 
>   widget suitable for its service (see mockup for 2 examples). however, we
>   could provide some sample widgets, as most services use a similar layout.

If we change the name, then we can probably provide "compat" API for older plugins (so we'd pack them properly within the UI, reducing maintainer anger :)

>   init () and NstPluginCapabilities capabilities
>   checking if folders and files are supported is a very good idea. additionally
>   we should check if a service supports a mime type, either by letting the 
>   plugin check it in init () and returning TRUE or FALSE or by adding a further 
>   capabilities struct

we probably want to support mime wildcards ("image/jpeg" for flickr, but "video/*" for youtube). The easiest would be to add a new vfunc for that.

> a further thing we should consider is different languages: for example, python 
> is a very nice language handling web stuff, c or vala are good enough to use
> the local bindings, e.g. bluetooth or gnome stuff. 
> 
> afaik libpeas won't allow us to use different languages in the _same_ process,
> is there a way to add more languages to it?
> for us it is enough to have c only, but think about some users, who know some 
> scripting languages like javascript or python. this way we could get many more
> plugins done

libpeas is probably good enough for our use case, though the API is probably a bit complicated for nautilus-sendto. Will need to experiment.

(In reply to comment #5)
> (In reply to comment #4)
> > find my comments about the current plugin api below:
> > 
> > NstPluginInfo
> >   gchar *description;
> >   this is probably not needed anymore, except we want to use it as a tooltip
> 
> That's the label used in the treeview.
> 
> >   get_contacts_widget ()
> >   we should rename this to simply get_widget, as the plugin will provide a 
> >   widget suitable for its service (see mockup for 2 examples). however, we
> >   could provide some sample widgets, as most services use a similar layout.
> 
> If we change the name, then we can probably provide "compat" API for older
> plugins (so we'd pack them properly within the UI, reducing maintainer anger :)

i hate compatibility, so i would gladely port the plugins to the new api instead
of having a compatibility thing

> 
> >   init () and NstPluginCapabilities capabilities
> >   checking if folders and files are supported is a very good idea. additionally
> >   we should check if a service supports a mime type, either by letting the 
> >   plugin check it in init () and returning TRUE or FALSE or by adding a further 
> >   capabilities struct
> 
> we probably want to support mime wildcards ("image/jpeg" for flickr, but
> "video/*" for youtube). The easiest would be to add a new vfunc for that.

agreed

> 
> > a further thing we should consider is different languages: for example, python 
> > is a very nice language handling web stuff, c or vala are good enough to use
> > the local bindings, e.g. bluetooth or gnome stuff. 
> > 
> > afaik libpeas won't allow us to use different languages in the _same_ process,
> > is there a way to add more languages to it?
> > for us it is enough to have c only, but think about some users, who know some 
> > scripting languages like javascript or python. this way we could get many more
> > plugins done
> 
> libpeas is probably good enough for our use case, though the API is probably a
> bit complicated for nautilus-sendto. Will need to experiment.


another thing which is missing is a utility library for compression, transformation etc.

most social networks only accept a set of specific data, so we should transform our file to their requirements, e.g. 460x480 jpeg on facebook, avi or mpeg on youtube etc..
the plugin should then decide if it should make that visible and if it wants to use it

Created attachment 167638 [details] [review]
New UI

This time tentatively powered by libpeas

Created attachment 167643 [details] [review]
New UI

This time tentatively powered by libpeas

Right. This kind of works. The plugin system now uses libpeas, and the API just needs a little tweaking to implement the features discussed above (get_widget returning NULL when the mime-type isn't supported?).

After that, the compression system needs to be moved into the common library, and the main UI fixed up a whole lot.

do you want to move the patch to a new branch in n-s? that way i could more easily add fixes and changes.

(In reply to comment #10)
> do you want to move the patch to a new branch in n-s? that way i could more
> easily add fixes and changes.

I'll do that when the patch is in order. I wouldn't want you to start porting plugins when we haven't got the rest sorted.

Created attachment 167870 [details] [review]
New UI

This time tentatively powered by libpeas

Committed a newer version of the patch to master. Still TODO:
- Fix packer UI (initial state, force packing for folders)
- Make uninstalled build run properly
- Port other plugins
- Make it possible to change the state of "Send" from plugins, when they're selected

Here's a sample list for the mime-types handling:
mime-types: image/jpeg
title: "Sharing %d photos"

mime-types: image/jpeg image/png
title: "Sharing %d images"

mime-types: image/jpeg inode/directory [1]
title: "Sharing %d files and %d folders"

mime-types: video/mpeg image/jpeg
title: "Sharing %d files"

mime-types: video/mpeg
title: "Sharing %d videos"

mime-types: text/plain
title: "Sharing %d text files"

Make sure to use dgettext() when creating plurals, the [1] case will be especially hard to get right. And create a test program for it too :)

Coming from pgo, here's a suggestion for [1]:
 - mark "%d files" and "%d folders" for translation separately (preferably using a context and comment explaining how it's going to be used)
 - combined sentence should be "Sharing %s and %s" with a comment explaining that the above messages are combined in

It's not nice, but it will be as right as it can be. :)

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

Current status is:
- libsocialweb pages are done, missing icons:
http://bugs.meego.com/show_bug.cgi?id=5944
- sending through libsocialweb is blocking on:
https://bugs.meego.com/show_bug.cgi?id=6178
- folks backend isn't started
- the folks backend would need e-d-s support before it can replace the evolution plugin
- support for sending "text" isn't supported yet (pushing text to pastebin, or status updates to twitter)
- most of the other plugins need porting, and re-integration into nautilus-sendto

See also bug 678875 for Empathy's updated nautilus-sendto plugin.

nautilus-sendto for GNOME 3.8 only supports sending files through an email client. In the future, other sharing options will be implemented through portals (an equivalent system to Android intents).