elementary-dev-community team mailing list archive

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

The reworked Contractor infrastructure has landed to PPA!

We currently have "Set as wallpaper", "Extract here" and "Print" (for plain
text) shipped with the distro.

Other useful contracts you can get are Inkscape contracts (batch export to
svg/pdf and vacuuming defs, "inscape-contracts" package) and Brasero
contracts (burning to disks of various types, "brasero-contracts" package).

Tom Beckmann also made a "webcontracts" package you should check out. It
contains working pastebin, imagebin and imgur upload contracts, among other
things. You have to enable them in Switchboard after installing the package
though.

If you think you've found a bug, I also wrote contracts for debugging
Contractor - install "debug-contracts" package and test away! (Spoiler:
there's a known corner-case spawning
bug<https://bugs.launchpad.net/contractor/+bug/1171982>
).

Getting sending files with Geary to work would be a high-priority contract,
but Geary doesn't expose the CLI interface for doing that at the moment.
Geary fundraiser has 9 hours left as of this writing; please support it to
make it possible!
http://www.indiegogo.com/projects/geary-a-beautiful-modern-open-source-email-client

I'll see if I can get the bluetooth tranfer contract I wrote a while back
to work. "Send by IM" contract will likely require writing an elaborate
wrapper a-la nautilus-sendto, so I guess that has to be left till another
time.


2013/4/24 Sergey "Shnatsel" Davidoff <sergey@xxxxxxxxxxxxxxxx>

> Status update!
>
> Victor has designed and (together with Akhay) implemented a more
> object-oriented API for Granite:
>
> https://code.launchpad.net/~victored/granite/contractor-wrapper/+merge/159948
>
> He has also updated Files to make use of it:
>
> https://code.launchpad.net/~victored/pantheon-files/contractor-plugin/+merge/160377
>
> I've already verified that Granite and Files parts work as expected.
> I've also the Contractor rewrite for landing to PPA, so the moment the
> merge requests are approved we can finally land all this awesome work.
>
> 2013/4/14 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 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!
> 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, 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, 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.
> >>>
> >>> 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
> >>>  * 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
>
>
>
> --
> Sergey "Shnatsel" Davidoff
> OS architect @ elementary
>



-- 
Sergey "Shnatsel" Davidoff
OS architect @ elementary