Re: [Elementary-dev-community] On Contractor and Luna

[Sergey "Shnatsel" Davidoff]

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 

> 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_asyncon
>  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 

Re: [Elementary-dev-community] On Contractor and Luna

[Victor]

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 
 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 

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 C

Re: [Elementary-dev-community] On Contractor and Luna

[Sergey "Shnatsel" Davidoff]

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 

> 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 <
> ser...@elementaryos.org> 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 
>
>> 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_asyncon
>>  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

[Elementary-dev-community] Why does Cairo.set_source_rgb paint the whole canvas?

[Craig]

I posted this question on StackOverflow, but I'm hoping you guys can help
answer it as well:

I'm playing around with Clutter/cairo and I'm trying to draw a rectangle;
however, it appears that theset_source_rgb is automatically painting the
whole canvas with its source, regardless of whether or not I tell it to
draw a rectangle (that is, even when I remove the ctx.rectangle() and
ctx.fill()lines, the rectangle is still drawn). Why is this? And what do I
need to do to have the rectangle do the painting rather than the
set_source_rgb?

The source can be found in the original SO question here:
http://stackoverflow.com/questions/16007420/why-does-cairo-set-source-rgb-paint-the-whole-canvas

Please advise, because I'm stumped!

Thanks List!
- Craig
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Why does Cairo.set_source_rgb paint the whole canvas?

[Tom Beckmann]

The effect you observe is caused by the paint call at the bottom. Remove
that and it should work fine. But you also have to insert
ctx.set_operator(Cairo.Operator.CLEAR);
ctx.paint();
ctx.set_operator(Cairo.Operator.OVER);
at the very bottom of the draw method which clears the canvas. Clutter
doesn't do that for you.
On Apr 15, 2013 6:05 AM, "Craig"  wrote:

> I posted this question on StackOverflow, but I'm hoping you guys can help
> answer it as well:
>
> I'm playing around with Clutter/cairo and I'm trying to draw a rectangle;
> however, it appears that theset_source_rgb is automatically painting the
> whole canvas with its source, regardless of whether or not I tell it to
> draw a rectangle (that is, even when I remove the ctx.rectangle() and
> ctx.fill()lines, the rectangle is still drawn). Why is this? And what do
> I need to do to have the rectangle do the painting rather than the
> set_source_rgb?
>
> The source can be found in the original SO question here:
> http://stackoverflow.com/questions/16007420/why-does-cairo-set-source-rgb-paint-the-whole-canvas
>
> Please advise, because I'm stumped!
>
> Thanks List!
> - Craig
>
> --
> Mailing list: https://launchpad.net/~elementary-dev-community
> Post to : elementary-dev-community@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~elementary-dev-community
> More help   : https://help.launchpad.net/ListHelp
>
>
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp