On Tue, Mar 13, 2012 at 5:42 PM, balint...@gmail.com <balint...@gmail.com> 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 -- Mailing list: https://launchpad.net/~unity-design Post to : unity-design@lists.launchpad.net Unsubscribe : https://launchpad.net/~unity-design More help : https://help.launchpad.net/ListHelp
