[Sugar-devel] [ASLO] Release I know Madagascar-2

[Sugar Labs Activities]

Activity Homepage:
http://activities.sugarlabs.org/addon/4719

Sugar Platform:
0.82 - 0.100

Download Now:
http://activities.sugarlabs.org/downloads/file/28831/i_know_madagascar-2.xo

Release notes:
-Add stats
-Add flag



Sugar Labs Activities
http://activities.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Frequent buildbot check failures in sugar-web

[Rogelio Mita]

I will take note of this


2013/11/28 Daniel Narvaez 

>
> http://buildbot.sugarlabs.org/builders/quick-sucrose-0.100/builds/6/steps/shell_2/logs/modules
>
> We are getting a lot of these, like 50% of the times. Unfortunately my
> laptop broke so I won't be able to debug them until it comes back repaired.
> Help sorting this out would be appreciated, especially if you are able to
> reproduce the issue locally.
>
>
> --
> Daniel Narvaez
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>


-- 
Roger

Activity Central 
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Adding compatibility in webactivity to webkit1

[Daniel Narvaez]

I'm unconvinced that it will be a short term workaround. It will be hard to
get rid of.

We are implicitly adding support for webkit 1.8 (API 1) to sugar-web. We
might have to write sugar-web code which is webkit1 specific. People will
write activities which runs on 1.8. They will use non
forward-compatible APIs. They will cut and paste python wrappers to run on
webkit1. For a long time webkit <= 1.8 will be the main platform really,
given the deployments situation.

I think this is an important decision. Even if it's not our intention we
will either send the message that we would like people to start using the
web toolkit on deployed software or that it's still a cutting edge
technology, targeted to developers and very recent software. The are
advantages and disadvantages of both approaches, the point is more that we
should be aware of the choice we are making.

On Wednesday, 27 November 2013, Gonzalo Odiard wrote:

> I am not opposed to alternative implementations,
> if we can "keep it simple".
>
> This is a workaround for a problem, in the end, we want remove it,
> when is not needed anymore.
>
> Gonzalo
>
>
> On Wed, Nov 27, 2013 at 2:22 PM, Rogelio Mita <
> rogeliom...@activitycentral.com  'rogeliom...@activitycentral.com');>> wrote:
>
>> Nice!, I quickly looked at the patch and I urged try to encapsulate the
>> all logic of webkit2 and the webkit1 in separate modules, using a luck of
>> strategy pattern or do something polymorphic, but I notice that it is a
>> decision not yet taken (as Daniel says), I doubt whether to spend time on
>> this for that reason, you will say, however when this decision is finally
>> decided, I would like to make note of this style refactor to have clean
>> webactivity module, which is relatively new and keep small, you think?
>>
>> Regards!
>>
>>
>> 2013/11/27 Gonzalo Odiard > 'gonz...@laptop.org');>>
>>
>>>
>>> On Wed, Nov 27, 2013 at 1:04 PM, Daniel Narvaez 
>>> 
>>> > wrote:
>>>
 I think it's good to have this upstream because otherwise changes to
 sugar-web will easily break webkit1 support.

 I'm not completely convinced we should support webkit1 yet. I'm worried
 it will be pretty painful to maintain. It should be possible to port
 webkitgtk 2.2 to Fedora 18...


>>> Maybe, but have many other dependencies to update.
>>>
>>> Another alternative is find what is crashing in webkit2 and solve it,
>>> but is out of my knowledge.
>>>
>>> Gonzalo
>>>
>>>
>>> ___
>>> Sugar-devel mailing list
>>> Sugar-devel@lists.sugarlabs.org >> 'Sugar-devel@lists.sugarlabs.org');>
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>>
>>
>>
>> --
>> Roger
>>
>> Activity Central 
>>
>
>

-- 
Daniel Narvaez
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Adding compatibility in webactivity to webkit1

[Daniel Narvaez]

On Wednesday, 27 November 2013, Gonzalo Odiard wrote:

>
> On Wed, Nov 27, 2013 at 1:04 PM, Daniel Narvaez 
> 
> > wrote:
>
>> I think it's good to have this upstream because otherwise changes to
>> sugar-web will easily break webkit1 support.
>>
>> I'm not completely convinced we should support webkit1 yet. I'm worried
>> it will be pretty painful to maintain. It should be possible to port
>> webkitgtk 2.2 to Fedora 18...
>>
>>
> Maybe, but have many other dependencies to update.
>

Yes but I'd hope it to be less work than maintaing support for both webkit1
and webkit2. Especially for upstream :)


> Another alternative is find what is crashing in webkit2 and solve it, but
> is out of my knowledge.
>

Even if fixed the crash, I think the API is pretty different compared to
2.x, so it would be probably be a pain to maintain too.


-- 
Daniel Narvaez
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Frequent buildbot check failures in sugar-web

[Daniel Narvaez]

http://buildbot.sugarlabs.org/builders/quick-sucrose-0.100/builds/6/steps/shell_2/logs/modules

We are getting a lot of these, like 50% of the times. Unfortunately my
laptop broke so I won't be able to debug them until it comes back repaired.
Help sorting this out would be appreciated, especially if you are able to
reproduce the issue locally.


-- 
Daniel Narvaez
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] web-activity: env.getEnvironment dependency with Python code

[Daniel Narvaez]

Those are hard questions :) I was also thinking about compatibility with
old sugar-toolkit-gtk3 versions when we change stuff like getEnvironment.

What about having two configurations, one for Sugar running only inside
sugar-build (what we have now), the other running into a normal web
browser running outside sugar-build. Seems like this would ensure
functionality of the contracts we currently care about? The sugar-web
inside sugar-build would break if sugar-toolkit-gtk3 doesn't fulfil the the
contract.

There is a difference between testing that getEnvironment works or that the
bits getEnvironment depend on (window.sugar) works as expected. Perhaps
where we think that difference might matter we could also have tests which
tests only the contract with toolkit, without other code layers in the
middle. But getEnvironment is so thin that it probably doesn't matter at
the moment..

We would need to figure out how to automate tests in a normal web browser,
but shouldn't be much of a problem.

On Wednesday, 27 November 2013, Rogelio Mita wrote:

> Ok, working on that we have these situations:
>
> *Context:*
>
>- Hard dependecy between repos: sugar-toolkit-gtk3 --> sugar-web
>- Exists only one "functional test" (Test interaction/contracts
>between classes) that is not working, ref:
>https://github.com/sugarlabs/sugar-web/blob/master/test/envSpec.js#L5
>- We need have 4 "unit test", one per each logic condition in lines 
> 10,
> 12 , 
> 17,
>21 
>
> *Plan:*
>
>- *sugar-web:*
>   - Doing missing unit tests to begin refactoring for no lead to
>   breakage in existing code
>   - Repair "functional test" that not running now, if is necessary
>   - Make refactor
>- *sugar-toolkit-gtk3:*
>   - same above
>- *sugar-web and sugar-toolkit-gtk3:*
>   - Doing functional test to cover the communication between both
>   - Make refactor
>
> *Questions:*
>
>- *Where is the right flow to avoid inconcistence between repos?*
>   - I mean, if we assume right behaviour on sugar-toolkit-gtk3 and
>   will write code on sugar-web, the sugar-web functionallity only works if
>   sugar-toolkit-gtk3 is also working right and fulfilling the contract
>- *Where is the right place to put the test of this contract above?*
>   - One idea is make a karma configuration that only works on osbuild.
>   - Other idea is doing manually =, and no place
>   - Other... tying sugar-web to their tests are always executed in
>   osbuild =(((
>
> Regards!
>
>
>
> 2013/11/27 Gonzalo Odiard  'gonz...@laptop.org');>>
>
>> Ok
>>
>>
>> On Wed, Nov 27, 2013 at 10:48 AM, Daniel Narvaez 
>> 
>> > wrote:
>>
>>> The env variable should be fine. Though can you open a thread about
>>> supporting webkit1? I think it's a major decision and we should ensure
>>> everyone is in the loop, especially since we had decided to support webkit2
>>> only in the kick of meeting.
>>>
>>>
>>> On Wednesday, 27 November 2013, Gonzalo Odiard wrote:
>>>



 On Wed, Nov 27, 2013 at 10:33 AM, Daniel Narvaez 
 wrote:

> It *might* not be possible to use the same approach on both. Though,
> interestingly, this is much easier on webkit1 so one way or another it
> should be possible to make it work.
>
> We need to merge support for webkitgtk1 upstream if we want upstream
> patches to be required to not break it.
>
>
 True.

 If you agree, I can go with the option of the env variable as discussed
 previously.

 Gonzalo



>
> On Wednesday, 27 November 2013, Gonzalo Odiard wrote:
>
>> Please remember we will be using web activities with Webkit1 for a
>> while.
>> Just a note, to be sure we don't go for something Webkit2 only.
>>
>> Gonzalo
>>
>>
>> On Wed, Nov 27, 2013 at 10:16 AM, Rogelio Mita <
>> rogeliom...@activitycentral.com> wrote:
>>
>>>
>>> 2013/11/27 Daniel Narvaez 
>>>
 My summary email is still valid but for completeness... I'm not
 sure it's possible even from inside webkit to implement a non-racy
 window-object-cleared signal.
>>>
>>>
>>> sounds good, I'm sure that python WebKit2 has to provide some
>>> solution to this without having to go down a level, if our plan does not
>>> work, surely on the list of webkit are going to tell us the right way, 
>>> when
>>> I can, I will try to do the plan
>>>
>>> Regards!
>>>
>>>
>>> --
>>> Roger
>>>
>>> Activity Central 
>>>
>>> ___
>>> Sugar-devel mailing list
>>>

Re: [Sugar-devel] Possible incompatibility between gtk2 activities and sugar-build

[Daniel Narvaez]

I want to support gtk2. Though I think the only solution is to add
SUGAR_HOME support to sugar-toolkit. It won't hopefully require a lot of
changes and we don't even need to release because it's sugar-build only.

On Wednesday, 27 November 2013, Gonzalo Odiard wrote:

> Asking here to know what to do.
> One of our GCI students reported a error trying to run Record activity
> in sugar-build. The log show Record is trying to get profile.get_pubkey()
> and get a error. get_pubkey() looks for the file owner.key.pub
> int the directory env.get_profile_path()
>
> Now, Record is a gtk2 activity, then env.get_profile_path() point to
> .sugar/default/
> not to the dotsugar directory.
>
> I don't know what is the right solution here,
> sugar-build should be compatible with the gtk2 activities
> or that is not supposed to work?
>
> Maybe we can document this issue?
>
> We copied this particular issue copying the file to .sugar/default,
> but is a workaround, and probably we will find other similar issues.
>
> Regards
>
> Gonzalo
>


-- 
Daniel Narvaez
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel