elementary-dev-community team mailing list archive

["Sergey \"Shnatsel\" Davidoff" <sergey@xxxxxxxxxxxxxxxx>]

Thanks! Could you write what you want to see changed in the API to make it
easier to use on the merge request?


2013/4/14 Victor <victoreduardm@xxxxxxxxx>

> Awesome work on Contractor!
>
> As for the Granite wrapper, I don't really see a lot of value in it since
> it's still a string-based API similar to the one we had before. It doesn't
> exploit Vala's object capabilities either. Is it really too much to ask to
> request OO APIs for Granite?
>
> Vala is object-oriented. Structured designs will most of the time produce
> bad client code in such languages.
>
> If you are proposing a new API for Granite and breaking an old one, make
> it worth it. Keep in mind that after Luna is released API breaks will be
> more difficult to handle, and ABI breaks forbidden.
>
> On Sun, Apr 14, 2013 at 1:10 AM, Sergey Shnatsel Davidoff <
> sergey@xxxxxxxxxxxxxxxx> wrote:
>
> Hey guys,
>
> We have a lot of progress to report! Thanks to Michael Lazarski, Akshay
> Shekher and Tom Beckmann we now have a working implementation of Contractor
> daemon using the new API. It's already much less buggy than the older one.
>
> Akshay has also transitioned Granite's wrapper to Contractor D-bus API to
> the new API, it just needs one final round of review:
> https://code.launchpad.net/~voldyman/granite/contractor-wid-dep-new-Contractor/+merge/158161
> As soon as that's merged I'll land the new Contractor to the daily PPA.
>
> He has also transitioned the Contractor widgets to the new API, but Dan
> doesn't want any widgets interfacing with Contractor in Granite, so the
> merge request deprecates them instead of updating them.
>
> All that's left is to document the API (unfortunately the old Contractor
> API is undocumented too) and to transition applications to the new API.
> It's easy and will instantly fix multiple bugs (e.g. Scratch printing
> problems Cassidy complained about).
>
>
>
> 2013/3/30 Sergey "Shnatsel" Davidoff <sergey@xxxxxxxxxxxxxxxx>
>
>> Hey guys,
>>
>> I have some unpleasant things to bring up. Sorry for the long post, I
>> hope it will not end up being another "TL;DR". (Come on, this is important!)
>>
>> As I've already reported, the current Contractor API is flawed. It relies
>> on the client app calling Process.spawn_command_line_async<http://www.valadoc.org/#!api=glib-2.0/GLib.Process.spawn_command_line_async>on the string Contractor returns, which is bad for a long list of reasons.
>> The most apparent one is being unable to handle filenames with spaces in
>> them <https://bugs.launchpad.net/contractor/+bug/1123040>! This
>> particular bug can be worked around in Contractor in an ugly way, but other
>> issues remail and the API is not future-proof, so *we'll have to break
>> it and Granite API/ABI* sooner or later (because Granite provides
>> widgets and convenience functions for accessing Contractor API). Obviously
>> it's better done sooner than later, while we don't have much code to
>> transition and before the relevant Granite widgets get into a stable
>> release.
>>
>> The more future-proof approach is to return a contract identifier to the
>> client app and make the app call Contractor again to execute an action,
>> passing it the identifier and the filename. This way Contractor can use
>> proper process-launching functions or use completely different last-mile
>> data transfer mechanisms<https://docs.google.com/document/d/1_w6-XBtr9qXXteytC9Mz0JqXZZoMsOPdfTDXVcoswUY/edit#>,
>> so we'll be able to add support for streaming data without writing it to
>> disk or invoking D-bus methods, all without breaking the API in the future.
>>
>> I've investigated the problems of the current Contractor and wrote a
>> better specification<https://docs.google.com/a/elementaryos.org/document/d/1Ijsc57vYEHBZxVdM0fRgCuBX2NbdRDv1kuOj0OG75v4/edit#>,
>> detailing its expected behavior and the required API changes. I've
>> discussed it with the original Python Contractor authors and got the green
>> light from them. Michael Lazarski (lampe2) has taken a stab at cleaning up
>> Ammonkey's code and implementing the spec, but he's currently preoccupied
>> by contracted work (no pun intended). His Contractor branch can be found at
>> lp:contractor<https://code.launchpad.net/~michael.lazarski/contractor/master>
>> .
>>
>> Additionally, I've looked into the state of Contractor support in Granite
>> and elementary applications. In short, it's not glamorous.
>>
>> None of the apps use the Granite-provided ContractorMenu widget for the
>> "Export" button; every single app reinvents the wheel and populates regular
>> GTK menu with items acquired from Granite's Contractor wrapper. Maya (the
>> least ugly implementation I've seen so far) even has a dedicated widget
>> that's a clone of ContractorMenu!
>>
>> The other Contractor widget, ContractorView, is used only by Eidete where
>> it doesn't seem to work; not sure if that's Contractor's fault or Eidete's.
>>
>> Finally, I don't understand why Granite has a wrapper for Contractor - it
>> doesn't seem to reduce complexity or abstract anything. Using the D-bus API
>> directly requires almost the same amount of code.
>>
>> So IMO the proper course of action is the following:
>>  * Rework Contractor's D-bus API according to my specification<https://docs.google.com/a/elementaryos.org/document/d/1Ijsc57vYEHBZxVdM0fRgCuBX2NbdRDv1kuOj0OG75v4/edit?pli=1>
>>  * Deprecate/abolish the Contractor wrapper in Granite
>>  * Update Granite widgets and Pantheon Files to work with the new D-bus
>> API
>>  * Migrate other applications to using the Granite widgets (currently
>> Maya, Scratch, Midori and elementary-flavored Simple Scan)
>>
>> However, I'm not sure this course of action is feasible for Luna.
>>
>> I'm absolutely not OK with releasing Granite with an API so flawed and
>> which we're going to break in the future, so the alternative is to replace
>> the current Contractor wrapper functions with stubs, mark them deprecated
>> and replace Granite functionality in apps with something else.
>>
>> The options that spring to mind are:
>>  * Replace Contractor actions with "Open With"
>>  * Replace Contractor actions with a roughly similar but severely limited
>> nautilus-sendto. Despite its name it's not actually related to Nautilus.
>> This way we get sending files by bluetooth, email and IM; the catch is that
>> Geary is not supported by nautilus-sendto, so we'll have to implement it
>> (it should be done sooner or later for decent integration with Ubuntu).
>>  * Remove the "Export" button from apps altogether
>>
>> Thoughts?
>>
>> --
>> Sergey "Shnatsel" Davidoff
>> OS architect @ elementary
>>
>
>
>
> --
> Sergey "Shnatsel" Davidoff
> OS architect @ elementary
>
>


-- 
Sergey "Shnatsel" Davidoff
OS architect @ elementary