[Sugar-devel] Current status of collaboration work
Tony Anderson
tony_anderson at usa.net
Sat Dec 26 05:01:16 EST 2015
Hi, Sam
Thanks. That sounds like enough to get me going. Sadly, this also means
porting to gtk3 but it will need to be done anyway.
Yours,
Tony
On 12/26/2015 11:57 AM, Sam P. wrote:
> Hi Tony,
>
> Sorry that I was a bit vague in the previous email. The collab
> wrapper is not yet merged into sugar-toolkit-gtk3, however can be used
> by activities by copying a script and including it in their activity.
>
> The collabwrapper script is available here:
> https://github.com/samdroid-apps/collabwrapper
>
> The readme details how to import it using a try/catch statment, so
> that the backwards compatible. It also links to the documentation,
> which included usage examples.
>
> The collabwrapper uses only telepathy features used already in sugar -
> namely the text channels (used by chat and other activities) and the
> file transfer channels (used in journal for file transfers). This
> means that if collabwrapper.py (the standalone script) is included in
> your activity, it should run in any Gtk3 sugar.
>
> Collab wrapper does not yet work in gtk2 sugar, as it uses GObject
> syntactic sugar that is only available in newer versions. It also
> depends on Gio for file transfers, and I will need to investigate how
> sugar gtk2 shell does the file transfers.
>
> Thanks,
> Sam
>
> On Sat, Dec 26, 2015 at 5:44 PM, Tony Anderson <tony_anderson at usa.net
> <mailto:tony_anderson at usa.net>> wrote:
>
> Hi Sam,
>
> I am still not clear on the status. I have a long-dormant activity
> 'bingo' which depends on the caller sending 'bingo cards',
> receiving a 'bingo call', and being able to check the card via
> collaboration. In developing those features, should I use the
> collab wrapper? Is it available for 0.106? Where can I find the
> version of
> chat that uses it as an example to follow? The version installed
> on 0.106 (13.2.5) does not seem to use it.
>
> Tony
>
>
> On 12/26/2015 01:55 AM, Gonzalo Odiard wrote:
>> Hi Martin,
>> I like your proposal of use the wrapper in the activities by at
>> least one cycle, before include it in the toolkit.
>> In our experience, once the code is included in the toolkit, is
>> difficult make changes without breaking activities in
>> unexpected ways.
>> I didn't have time to make tests with the wrapper, and is really
>> difficult do tests for collaboration. We have seen
>> bugs that appear only when you have many computers, or using
>> jabber but not when using the mesh, etc.
>> I think the wrapper is a very, very good start (Thanks Sam and
>> Walter) and even they provided patches for some activities.
>> Sadly, some of the activities are on my hands, but I didn't have
>> time the last months to do the proper testing
>> and integration of the patches.
>> About the wrapper API, just looking at the code, I think would be
>> better add a callback parameter to the setup() method
>> because the initialization is async and then is the only way to
>> execute your activity code when the initialization
>> has finished. Issues like this are difficult to get right at the
>> first time.
>> I know I am not doing almost any work in sugar these months,
>> don't take these comments as a critic,
>> just as a way to try to help, and avoid problems in the future.
>> Regards,
>>
>> Gonzalo
>>
>>
>> On Wed, Dec 23, 2015 at 4:52 PM, Martin Abente
>> <martin.abente.lahaye at gmail.com
>> <mailto:martin.abente.lahaye at gmail.com>> wrote:
>>
>> Hello everyone,
>>
>> I have been reviewing the current state of the collaboration
>> proposals and I am afraid it is still too early for merging
>> it. We need to explore more use cases, and this will only
>> happens when we start porting more Activities that actually
>> use TUBES. Therefore, i want to share some thoughts on this.
>>
>> *Opinions:*
>>
>> 1. There haven't been enough changes in the Activities
>> regarding Tubes deprecation.
>> 2. Dropping the Tubes support from Sugar without changing
>> all the activities that depend on Tubes means that we
>> will break collaboration for those activities anyway, and
>> there wont be much gain by just doing that.
>> 3. Making changes in the Sugar API without proper testing
>> with more activities (and scenarios) is simply not a good
>> idea.
>> 4. But, making changes in the Activities can be easily
>> handled since they are self contained.
>> 5. Most of our users still use Fedora 18 through OLPC
>> deployments, where Tubes is available.
>>
>> *Suggestions:*
>>
>> 1. Lets make Sugar handle the Tubes deprecation better so it
>> doesn't break, but lets not remove the support for TUBES yet.
>> 2. Instead, we can start changing the activities using the
>> Wrapper that Walter and Sam prepared, but using it
>> locally on each Activity for now.
>> 3. Once and if, we have most of our activities ported to the
>> new telepathy API (which will be based on the Wrapper),
>> then we can include the Wrapper into sugar-toolkit-gtk3,
>> in a next release and remove it from Activities.
>>
>> *Pros:*
>>
>> 1. We avoid breaking collaboration for *(a)* Activities that
>> use TUBES and run on older systems where TUBES is
>> available, and *(b)* Activities that does not use TUBES
>> on newer systems where TUBES is no longer available. This
>> _is_ an improvement versus the current situation where is
>> completely broken on newer systems.
>> 2. We do this whole re-work incrementally, without having to
>> change the API (sort of) blindly.
>> 3. There will be more flexibility to explore ideas in
>> Activities land.
>>
>> *Cons:*
>>
>> 1. There will be repeated code in Activities, but that can
>> be changed easily later.
>>
>>
>> *What would be needed:*
>>
>> 1. To detect if there is TUBES support, as Sam mentioned in
>> his first PR [1]. *Can someone look into this?*
>> 2. Do not create TUBES channel when there is not support.
>> This [2] is just a hack and the logic works fine, but it
>> depends on whether or not we can detect support.
>> 3. Cleanup the Wrapper and make sure that it is possible to
>> use it locally in activities.
>>
>> *Other improvements that we could land now:*
>>
>> 1. Give more flexibility to activities to use file transfer
>> channels without having the shell messing with them. [3]
>>
>> *Conclusions:*
>>
>> If we don't do something about this, next Sugar releases will
>> still be broken for collaboration, for more scenarios than
>> necessary.
>>
>>
>> Let me know what you guys think,
>> Martin.
>>
>> *Refs:*
>> [1] https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/270
>> [2]
>> https://github.com/tchx84/sugar-toolkit-gtk3/commit/bed0ac5f4259ff1669323db26acb27f5d9c8ed1f
>> [3] https://github.com/sugarlabs/sugar/pull/621
>>
>>
>>
>>
>> --
>> Gonzalo Odiard
>>
>> SugarLabs - Software [for | by] children learning
>>
>>
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> <mailto:Sugar-devel at lists.sugarlabs.org>
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> <mailto:Sugar-devel at lists.sugarlabs.org>
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
>
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20151226/caaea845/attachment-0001.html>
More information about the Sugar-devel
mailing list