unity-design team mailing list archive

[Dylan McCall <dylanmccall@xxxxxxxxx>]

On Tue, Mar 13, 2012 at 5:42 PM, balint777@xxxxxxxxx
<balint777@xxxxxxxxx> wrote:
> Sorry if it was discussed before, anyway...
> I have been using Android and Windows 8 recently quite a lot. These two guys
> have one pretty clever feature, i would certainly like to have in Ubuntu.
> Its their data-sharing protocoll.
> Basically applications have the ability to register one of their methods to
> share data held by them through a protocoll to an other application. This
> makes literally every application compatible with each other.
>
> Applications would be able to:
>
> Register a method for messaging -> no need to iplement switches in every
> application to turn notifications off, because the desktop can control it.
> Register method for sharing the data it holds -> Files could be immediately
> retrieved from various sources.
> Register itself for certain file types -> User immediately offered those
> apps when opens a file.
>
> Well... there could be tons of roles an application could be regitered to.
> There is an initiative in elementary os
> already: http://elementaryos.org/docs/human-interface-guidelines/desktop-integration/contractor
>
> What do you think we could use this for? Do we have something likely
> already?

Contractor doesn't look like quite the right thing. Seems like a
possibly more sophisticated gnome-send-to. I'd love to be shown
otherwise.

I was kind of poking at something for a while, and then I wasn't, and
then I got carried away with other stuff, then I forgot. I was
recently in the "despair and convince self it wouldn't have been
necessary" stage, and now you're reminding me it probably is. So,
thanks, I don't know what I should feel now, but, yeah, I probably
won't be getting to it any time soon :(

There are two distinct problems here, and I think each is its own
solution, really:

There's sending a file to an application, indefinitely, for some
reason (opening a file?). This could be amended to include telling an
application to create a file, which is standard with a CLI but rare
with a GUI. (You can do gedit some_file_that_doesn't_exist and it'll
create the file. GIMP will freak out). File browsers could certainly
be nicer about presenting choices; I think there's a case for
revisiting the whole "default file handler" idea. Android does it
rather well, I think, presenting a choice up front with an obvious
checkbox to make your selection the default. I don't think Ubuntu
provides many redundant file handlers by default, so it seems silly
that users have to do the extra step of going to Open With when
they've already made the choice of installing another application with
which to open a particular file type.

Then there's asking a service (which is, incidentally, another
application) to save or to open a file. This one is quite different,
and I think there are a lot of neat directions it can go. What I was
doing (and then not doing) was basically implementing GtkFileChooser /
QtFileChooser as a dbus service, with some extra things to make it
flexible. Various applications would register file provider and / or
receiver services, all with the same interface (mostly provided via a
library).

This way the file chooser lives in a different service, which either
receives file URLs from the client or sends them back, depending on
the operation. Installed applications could provide special file
choosers for specific file types — like a music chooser and a photo
chooser, and a Nautilus file chooser and a Dolphin file chooser. An
example I like playing with is a file provider that uses libcheese to
take a photo, fitting in the same workflow as a file chooser would be.
Some standard hints could specify things like desired image size and
all that, and I'm pretty sure it could all fit pretty snug with what
already exists. Importantly, I think it would be possible to just
implement a basic file chooser over dbus, then actually make it
interesting (with design and all that!) in the future — rather than
targeting the shiny all at once.

Having an external file chooser opens up some neat possibilities for
information security, too. I think MacOS does such a thing with their
sandboxing now, although they just use the one file chooser.
Basically, don't let an application access a file created by another
application, unless permission has been granted. Opening a file with a
file chooser implicitly grants permission. (And that's possible,
because the file chooser has fancier privileges).

There is some weirdness there with window managers, modal dialogs,
asynchronous two-way protocols, and all that stuff, so it started to
feel fussy and miserable really early on, and my first attempt didn't
get far. It's weird having a dbus service providing a UI that tries to
fit with another application (instead of its own thing), and I wonder
if window managers could help. Maybe in a few months I'll have some
fussy and miserable to spare and I can try again, if nobody does it
first.

There's also a weird question about sending arbitrary data that
_isn't_ a file. Maybe it would work to just write stuff like contact
data to /tmp during transit — this is Unix, after all, so there's no
shame in that — or perhaps specific types of data would be sent
through some horrid extension of the dbus file chooser protocol…

I think what Microsoft is doing is interesting but limited. It looks
like they have a single file chooser that has pluggable data sources.
It's a lot like Explorer so it kind of fits their philosophy there,
but it uses the same view for all types of files whether they're
illustrations, photos, spreadsheets or videos. Granted, it's a
flexible view with shiny previews, but it's still limited to how files
behave. With separate choosers, you can choose photos using the
application you actually use to store your photos  — like how Android
does it — and users don't need to worry about file names (and folders)
unless they really want to.

Dylan