After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 626553 - First pass at implementing new sharing UI
First pass at implementing new sharing UI
Status: RESOLVED OBSOLETE
Product: nautilus-sendto
Classification: Applications
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: nautilus-sendto-maint
nautilus-sendto-maint
: 620393 (view as bug list)
Depends on: 626622 627732
Blocks:
 
 
Reported: 2010-08-10 17:44 UTC by Bastien Nocera
Modified: 2013-07-03 07:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
First pass at implementing new sharing UI (41.45 KB, patch)
2010-08-10 17:44 UTC, Bastien Nocera
none Details | Review
New UI (77.36 KB, patch)
2010-08-11 16:48 UTC, Bastien Nocera
none Details | Review
New UI (81.91 KB, patch)
2010-08-11 17:33 UTC, Bastien Nocera
none Details | Review
New UI (123.77 KB, patch)
2010-08-14 14:42 UTC, Bastien Nocera
none Details | Review

Description Bastien Nocera 2010-08-10 17:44:30 UTC
As seen on:
http://live.gnome.org/Nautilus/Future/Sharing
Comment 1 Bastien Nocera 2010-08-10 17:44:33 UTC
Created attachment 167533 [details] [review]
First pass at implementing new sharing UI
Comment 2 daniel g. siegel 2010-08-10 17:46:46 UTC
mockup is here: http://www.dgsiegel.net/files/gnome-sharing-service.png
Comment 3 Bastien Nocera 2010-08-10 17:56:46 UTC
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".
Comment 4 daniel g. siegel 2010-08-10 18:12:49 UTC
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
Comment 5 Bastien Nocera 2010-08-10 18:25:16 UTC
(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.
Comment 6 daniel g. siegel 2010-08-10 18:30:27 UTC
(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
Comment 7 Bastien Nocera 2010-08-11 16:48:22 UTC
Created attachment 167638 [details] [review]
New UI

This time tentatively powered by libpeas
Comment 8 Bastien Nocera 2010-08-11 17:33:40 UTC
Created attachment 167643 [details] [review]
New UI

This time tentatively powered by libpeas
Comment 9 Bastien Nocera 2010-08-11 17:36:06 UTC
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.
Comment 10 daniel g. siegel 2010-08-11 23:33:59 UTC
do you want to move the patch to a new branch in n-s? that way i could more easily add fixes and changes.
Comment 11 Bastien Nocera 2010-08-12 09:06:30 UTC
(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.
Comment 12 Bastien Nocera 2010-08-14 14:42:13 UTC
Created attachment 167870 [details] [review]
New UI

This time tentatively powered by libpeas
Comment 13 Bastien Nocera 2010-08-16 13:13:13 UTC
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
Comment 14 Bastien Nocera 2010-08-16 18:21:49 UTC
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 :)
Comment 15 Danilo Segan 2010-08-31 14:18:02 UTC
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. :)
Comment 16 Bastien Nocera 2010-09-01 09:40:45 UTC
*** Bug 620393 has been marked as a duplicate of this bug. ***
Comment 17 Bastien Nocera 2010-09-01 13:53:13 UTC
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
Comment 18 Bastien Nocera 2012-06-27 15:19:55 UTC
See also bug 678875 for Empathy's updated nautilus-sendto plugin.
Comment 19 Bastien Nocera 2013-07-03 07:44:30 UTC
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).