Re: [Sugar-devel] Current status of GTK+ 3.x migration

[Jonas Smedegaard]

Quoting Tony Anderson (2015-12-26 21:11:09)
> I guess you see how far out from the developer community I am. I 
> associate sucrose with Activity Central. I am not sure what a sucrose 
> developer is.

You need not know the details of how the parts of a code eco-system is 
divided in order to help: Report bugs to the corresponding issue 
tracker, and those who know better will pass on the information to the 
right part of the eco-system.

...but I strongly advice you to try not be judgemental without even 
understanding (just the very broad) anatomy of the thing you judge: Ask 
instead of judging!

What I am referring to is your telling (not asking) that GStreamer works 
fine, which spawned this subthread.


> The involved developers have been doing well. However, for many of the 
> activities in ASLO, the original contributors have moved on, a natural 
> situation in open source.

Sure it is natural for developers to move on, and as a consequence, it 
is natural for some projects (those left without active developers) to 
to stop working when the underlying environment develops.  Such 
situation is called "bit-rot", and calls for either new devoted 
developers to step in, or that code to be dropped.  In such situations 
it is not helpful to point at "the old code worked fine, there was no 
need to change anything" - if you wanna live in the past then simply 
don't upgrade the _whole_ system at all.


> There is no attempt to point fingers, the decision is there. If Sugar 
> is to move to the mobile device, it appears necessary to work in a 
> Javascript not Python environment. So an activity developer/maintainer 
> needs to decide whether his investment in time in GTK is warranted or 
> should be spent it in rewriting the activity as a Sugar-web-activity.

You bring Javascript into this conversation, not me.  For my part, we 
are talking about migration from GTK+ 2.x to GTK+ 3.x and how some 
activities fall behind in that transition.


Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


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

Re: [Sugar-devel] Current status of GTK+ 3.x migration

[Walter Bender]

Tony, if you have a list of activities that need porting to GTK3, please
let me know: it makes for nice GCI projects. That is how, in fact much of
the updating happened over the past few years.

-walter

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

Re: [Sugar-devel] [Bugs] #4926 Physics HIGH: physics-28 fails to start on fedora 18 i386

[Walter Bender]

Quozi,

Could you please test the lastest bits at
https://github.com/walterbender/physics to see if it fixes the problem on
XO1.5?

On Tue, Dec 22, 2015 at 6:10 PM, Sugar Labs Bugs <
bugtracker-nore...@sugarlabs.org> wrote:

> #4926: physics-28 fails to start on fedora 18 i386
> --+---
>   Reporter:  quozl|Owner:
>   Type:  defect   |   Status:  new
>   Priority:  High |Milestone:  Unspecified
>  Component:  Physics  |  Version:  Unspecified
>   Severity:  Major|   Resolution:
>   Keywords:   |  Distribution/OS:  Unspecified
> Bug Status:  New  |
> --+---
>
> Comment (by quozl):
>
>  Does not occur on XO-4.
>
>  Does occur on XO-1.5.
>
>  Perhaps libstdc++.so.6 of build system differs from that of running
>  system.
>
> --
> Ticket URL: 
> Sugar Labs 
> Sugar Labs bug tracking system
> ___
> Bugs mailing list
> b...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/bugs
>



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

Re: [Sugar-devel] Current status of collaboration work

[Tony Anderson]

Hi, Jonas

Yet more examples of this broken software problem. I have scripts which 
provide the 'bad and ugly' codecs for GStreamer 0.10 which work very 
well. I have
had to regress to Jukebox 26 in order for this to work, but it performs 
well. I have been unable to find where these codecs go for GStreamer 1.0 
and so can not use it.


Avoiding GTK + 2.x implies porting all 400 Sugar activities to GTK 3!  
So far as I know only a small number of activities have been ported not 
including TurtleBlocks.


Tony

On 12/26/2015 12:41 PM, Jonas Smedegaard wrote:

Quoting Tony Anderson (2015-12-26 15:31:16)

Thanks. That sounds like enough to get me going. Sadly, this also
means porting to gtk3 but it will need to be done anyway.

Thanks - a hassle indeed, but urgently needed not only for
collaboration:

   * GStreamer 0.10 (tied to GTK+ 2.x) is deprecated since some years
 and is now dropped from Debian (and no doubt will be soon from
 any other distro that haven't done that move already long ago).
   * Systems with small diskspace (e.g. XO-1) can free 200-300MB by
 avoiding GTK+ 2.x altogether.

So if either a) your activity uses GStreamer and you care about having
it running on new operating systems, or b) you care about old hardware,
then you already need to migrate to GTK+ 3.x.


Regards,

  - Jonas



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


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

Re: [Sugar-devel] Current status of GTK+ 3.x migration

[Tony Anderson]

Hi, Jonas

True - either that or ditch the activities evidently too badly
maintained to work well with modern Sugar.

Aye, There's the rub!

Is the problem 'bad maintenance or none at all' or 'modern' Sugar. 
Certainly TuxMath is suffering from 'abandonment'. However, even 
abandoned code continues to run when the underlying support is there. In 
this case, programmers who were not involved in the development or 
maintenance of the code will

have to figure out how to get it running again or rewrite it in Javascript.

The port of activities to GTK+ 3.x seems to have stalled because of the 
higher priority to re-implement activities such as
TurtleBlocks in javascript. Consider the long-term job security in 
rewriting Sim City in javascript as a Sugar-web-activity.


Gstreamer

In the case of gstreamer 0.1, I was able to find how to install the codecs:

#script to enable webm, mp3, mp4, m4a, m4v for gstreamer-0.10
sudo cp libgstmad.so /usr/lib/gstreamer-0.10/
sudo chmod 755 /usr/lib/gstreamer-0.10/libgstmad.so
sudo cp libmad.so.0 /usr/lib
sudo chmod 755 /usr/lib/libmad.so.0
sudo cp libgstfaad.so /usr/lib/gstreamer-0.10
sudo chmod 755 /usr/lib/gstreamer-0.10/libgstfaad.so
sudo cp libfaad.so.2.0.0 /usr/lib
sudo chmod 755 /usr/lib/libfaad.so.2.0.0
sudo yum install gstreamer-ffmpeg-0.10.13-8.fc18.i686.rpm
sudo ldconfig
sudo rm -rf /home/olpc/.gstreamer-0.10/registry.i386.bin

The script is the same for XO-1, XO-1.5, XO-1.75, XO-4 except that the 
specific files must match the architecture. I have no idea where 
/usr/lib/gstreamer-0.10 went in gstreamer-1.0. As I recall, 
gstreamer-1.0 does not provide the registry.i386.bin which is required 
to register the codecs. Given the limited capacity of the XO what I do 
not want to do is install whole repositories, just the necessary files.


I am certainly sure that everyone is bored to tears on this subject 
since I have mentioned it so many times already.


Tony


On 12/26/2015 01:31 PM, Jonas Smedegaard wrote:

Quoting Tony Anderson (2015-12-26 16:29:09)

Yet more examples of this broken software problem.

I would call it examples of _unmaintained_ software.

I.e. in my opinion for these examples the Sugar environment does the
right thing of both a) moving to GTK+ 3.x while b) providing legacy
support for GTK+ 2.x for several years.  Issues then emerge with
activities neglecting to migrate for several years to GTK+ 3.x.



I have scripts which provide the 'bad and ugly' codecs for GStreamer
0.10 which work very well.

Which codecs? GStreamer 1.0 also provides bad and ugly codecs - so an
obvious first step is to ensure they are installed for your system.

In the case of the Debian system, installing the package
sugar-jukebox-activity by default pulls in the bad set but you will need
to explicitly install the ugly set (because the very reason those are
shipped separately is that they may cause your system to become less
stable).

If, on a Debian system, you install the metapackage sucrose then both
the bad and ugly sets gets installed (always, not only by default,
bcause the purpose of that metapackage is to ensure that as much of
Sucrose as is packaged for Debian gets installed).



I have had to regress to Jukebox 26 in order for this to work,

Sounds like you have done some research on this.  I recommend that you
a) file a bugreport about this (if one is not filed already), and then
b) refer to the bugreport each time you bring it up - e.g. in
conversations like this one.




Avoiding GTK + 2.x implies porting all 400 Sugar activities to GTK 3!

True - either that or ditch the activities evidently too badly
maintained to work well with modern Sugar.



  - Jonas



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


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

Re: [Sugar-devel] Current status of collaboration work

[Tony Anderson]

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

Re: [Sugar-devel] Current status of collaboration work

[Sam P.]

Hi Gonzalo,

I agree with your perspective that we do need to make the wrapper the best
it can be before locking ourselves into it.  That is a good plan.

I'm not sure what you mean about adding a parameter to the setup method.
Could you please elaborate?

Thanks,
Sam

On Sat, Dec 26, 2015 at 10: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.lah...@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]
>> 

Re: [Sugar-devel] Current status of GTK+ 3.x migration

[Jonas Smedegaard]

Quoting Tony Anderson (2015-12-26 16:29:09)
> Yet more examples of this broken software problem.

I would call it examples of _unmaintained_ software.

I.e. in my opinion for these examples the Sugar environment does the 
right thing of both a) moving to GTK+ 3.x while b) providing legacy 
support for GTK+ 2.x for several years.  Issues then emerge with 
activities neglecting to migrate for several years to GTK+ 3.x.


> I have scripts which provide the 'bad and ugly' codecs for GStreamer 
> 0.10 which work very well.

Which codecs? GStreamer 1.0 also provides bad and ugly codecs - so an 
obvious first step is to ensure they are installed for your system.

In the case of the Debian system, installing the package 
sugar-jukebox-activity by default pulls in the bad set but you will need 
to explicitly install the ugly set (because the very reason those are 
shipped separately is that they may cause your system to become less 
stable).

If, on a Debian system, you install the metapackage sucrose then both 
the bad and ugly sets gets installed (always, not only by default, 
bcause the purpose of that metapackage is to ensure that as much of 
Sucrose as is packaged for Debian gets installed).


> I have had to regress to Jukebox 26 in order for this to work,

Sounds like you have done some research on this.  I recommend that you 
a) file a bugreport about this (if one is not filed already), and then 
b) refer to the bugreport each time you bring it up - e.g. in 
conversations like this one.



> Avoiding GTK + 2.x implies porting all 400 Sugar activities to GTK 3!

True - either that or ditch the activities evidently too badly 
maintained to work well with modern Sugar.



 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


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

Re: [Sugar-devel] Current status of GTK+ 3.x migration

[Tony Anderson]

Hi, Jonas

I guess you see how far out from the developer community I am. I 
associate sucrose with Activity Central. I am not sure what a sucrose 
developer is.
The involved developers have been doing well. However, for many of the 
activities in ASLO, the original contributors have moved on, a natural 
situation in

open source.

There is no attempt to point fingers, the decision is there. If Sugar is 
to move to the mobile device, it appears necessary to work in a 
Javascript not Python environment. So an activity developer/maintainer 
needs to decide whether his investment in time in GTK is warranted or 
should be spent it in rewriting the activity as a Sugar-web-activity.


Tony



On 12/26/2015 04:58 PM, Jonas Smedegaard wrote:

Quoting Tony Anderson (2015-12-26 19:53:47)
[Jonas wrote:]

True - either that or ditch the activities evidently too badly
maintained to work well with modern Sugar.

Aye, There's the rub!

Is the problem 'bad maintenance or none at all' or 'modern' Sugar.
Certainly TuxMath is suffering from 'abandonment'. However, even
abandoned code continues to run when the underlying support is there.
In this case, programmers who were not involved in the development or
maintenance of the code will have to figure out how to get it running
again or rewrite it in Javascript.

Wrong: In this case all developers were involved at their various levels
of the chains of events but some of them were inactive: GTK+ developers
chose to improve their code beyond what a previous API could contain and
sensibly bumped API and kept alive the previous API for ages.  Sucrose
developers chose to build their code on top of GTK+ and sensibly handled
the API split of GTK+ including maintenance of a legacy interface for
ages.  Activity developers chose to build their code on top of Sucrose
and some of them sensibly migrated to new interfaces, but sadly some
activity developers did not react yet - and *that* is not sensible.



The port of activities to GTK+ 3.x seems to have stalled because of
the higher priority to re-implement activities such as TurtleBlocks in
javascript. Consider the long-term job security in rewriting Sim City
in javascript as a Sugar-web-activity.

Are you pointing fingers at other volunteers choosing to spend their
time in a way you disaprove of, or have you provided patches to migrate
some activities but have been turned down?



In the case of gstreamer 0.1, I was able to find how to install the
codecs:

[...]

I am certainly sure that everyone is bored to tears on this subject
since I have mentioned it so many times already.

Did you "mention" it through the appropriate issue tracker?


  - Jonas



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


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

Re: [Sugar-devel] Current status of collaboration work

[Sam P.]

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 
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.lah...@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 

Re: [Sugar-devel] Current status of collaboration work

[Sam P.]

Hi James,

On Sat, Dec 26, 2015 at 2:28 PM, James Cameron  wrote:

> Thanks all for the thread and replies.
>
> I'm not sure I understand the situation fully yet, but I'll make some
> comments regardless.  Hopefully any disconnect between my comments and
> your understanding will help fix mine.
>
> I've learned long ago, to not change network protocols in a way that
> breaks things.  Interoperability is critical, regardless of difficulty
> of implementation or complexity.
>
> The Tubes API is effectively a network protocol.
>
> If we release a version of Sugar that is incompatible with previous
> versions of Sugar, at a network protocol level, what will happen?
>

The tubes API is kind of a network protocol.  We also can't drop tubes from
sugar per se, activities consume raw tubes.  On telepathy versions that
tubes are not avaliable, we never give any channels to the activity because
we wait (forever) for a tube.  If the activity requires a tube, but sugar
does not give it one, it will also break in unexpected ways.

In effect, if the user is using a "new" (not using tubes) activity things
will work on any system where it gives the text channel to the activity.
This included old sugar 98 systems, OLPC OS 13/14 systems and patched
fedora 24 systems.

If these users are updating their activities, everything will be fine.
Moving away from tubes will mean that the "old" (tubes) version of the
activity can not collaberate with the "new" (non tubes) version of the
activity.  However, if both users update their activities, all is well.


>
> If we release a version of an activity with incompatibility, what
> will happen?
>
> We've seen what happens, even with the trivial problems introduced by
> the activity.info file and the Gtk3 port.  The bias of the first
> failure report is severe and lasting.  Our users don't upgrade.  They
> persist with an old version of Sugar, like 0.96 on OLPC OS 12.1.0.  In
> effect, they ignore the Sugar developer community until the job is
> finished, the problems are fixed, or sufficient reasons are built up
> to upgrade.  During which we have no end-user feedback into the
> development process.  It has taken years to recover from the post-0.96
> breakage.
>
> Tony made a remark about Fedora amok.  Perhaps it was deeper than
> that, perhaps it was a failure of advocacy for the Tubes API, in the
> context of the Telepathy community, by members of the Sugar Labs
> developer community.  Rhetorical; did they know we were using it?
>
> If it was a failure of advocacy, we must expect further instances.
> Some other API will disappear.
>

*Looks at WebKit2*

I should probably comment more on that webkit ticket.


>
> I've seen no detailed analysis of adopting the Tubes API into Sugar.
> Why not?  What is so hard about taking the latest version of Tubes API
> and integrating it into the Sugar code base in a way that we can
> continue to use it?
>

There is no new tubes api.  And porting to a DBusTube channel or StreamTube
channel is probably as hard as porting to CollabWrapper - most of the
activity collab code is spend on tube initiation.  It believe that it is
obviously advantageous to move the collaboration setup code into a shared
wrapper, rather than migrate it from tube initiation to DBusTube
negotiation.


>
> Pull request 282 mentions 0.17.25, but of what package?  When did the
> Tubes API get removed from the Telepathy packages?  Yes, for Fedora it
> was 22, but we care about other downstreams.
>

I reference the telepathy spec version.  However, I do not know and can not
find where these map into telepathy-{gabbel,salut} versions.

You also touch on gabble vs salut later on and mention that salut still
supports tubes.  Maybe salut should be our new default then given it
supports older activities?  (also, jabber.sugarlabs.org is way to busy to
find any buddies!)


>
> On Fedora 18 builds with Sugar 0.107.0, I'm using
>
> telepathy-mission-control 5.14.0
> telepathy-salut 0.8.1
> telepathy-gabble 0.16.7
> python-telepathy 0.15.19
> telepathy-glib 0.20.4
>
> On Fedora 20 builds, I'm using
>
> telepathy-mission-control 5.16.3
> telepathy-salut 0.8.1
> telepathy-gabble 0.18.2
> python-telepathy 0.15.19
> telepathy-glib 0.22.0
>
> On Ubuntu 14.04 builds with Sugar 0.107.0, I'm using
>
> telepathy-mission-control 5.16.1
> telepathy-salut 0.8.1
> telepathy-gabble-legacy 0.16.7
> python-telepathy 0.15.19
> libtelepathy-glib0 0.22.1
>
> On Ubuntu 15.10 builds with Sugar 0.107.0, I'm using
>
> telepathy-mission-control 5.16.3
> telepathy-salut 0.8.1
> telepathy-gabble-legacy 0.16.7
> python-telepathy 0.15.19
> libtelepathy-glib0 0.24.1
>
> On Fedora 24 koji.fedoraproject.org says we'll expect
>
> telepathy-mission-control 5.16.3
> telepathy-salut 0.8.1
> telepathy-gabble 0.18.2
> python-telepathy 0.15.19
> telepathy-glib 0.24.1
>
> I don't have a test case for collaboration failure due to Tubes API
> missing.  The feature page doesn't say.  I can't find a bug report.
>

Re: [Sugar-devel] Current status of collaboration work

[Jonas Smedegaard]

Quoting Tony Anderson (2015-12-26 15:31:16)
> Thanks. That sounds like enough to get me going. Sadly, this also 
> means porting to gtk3 but it will need to be done anyway.

Thanks - a hassle indeed, but urgently needed not only for 
collaboration:

  * GStreamer 0.10 (tied to GTK+ 2.x) is deprecated since some years
and is now dropped from Debian (and no doubt will be soon from
any other distro that haven't done that move already long ago).
  * Systems with small diskspace (e.g. XO-1) can free 200-300MB by
avoiding GTK+ 2.x altogether.

So if either a) your activity uses GStreamer and you care about having 
it running on new operating systems, or b) you care about old hardware, 
then you already need to migrate to GTK+ 3.x.


Regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


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

Re: [Sugar-devel] Current status of GTK+ 3.x migration

[Jonas Smedegaard]

Quoting Tony Anderson (2015-12-26 19:53:47)
[Jonas wrote:]
>> True - either that or ditch the activities evidently too badly 
>> maintained to work well with modern Sugar.
>
> Aye, There's the rub!
> 
> Is the problem 'bad maintenance or none at all' or 'modern' Sugar. 
> Certainly TuxMath is suffering from 'abandonment'. However, even 
> abandoned code continues to run when the underlying support is there. 
> In this case, programmers who were not involved in the development or 
> maintenance of the code will have to figure out how to get it running 
> again or rewrite it in Javascript.

Wrong: In this case all developers were involved at their various levels 
of the chains of events but some of them were inactive: GTK+ developers 
chose to improve their code beyond what a previous API could contain and 
sensibly bumped API and kept alive the previous API for ages.  Sucrose 
developers chose to build their code on top of GTK+ and sensibly handled 
the API split of GTK+ including maintenance of a legacy interface for 
ages.  Activity developers chose to build their code on top of Sucrose 
and some of them sensibly migrated to new interfaces, but sadly some 
activity developers did not react yet - and *that* is not sensible.


> The port of activities to GTK+ 3.x seems to have stalled because of 
> the higher priority to re-implement activities such as TurtleBlocks in 
> javascript. Consider the long-term job security in rewriting Sim City 
> in javascript as a Sugar-web-activity.

Are you pointing fingers at other volunteers choosing to spend their 
time in a way you disaprove of, or have you provided patches to migrate 
some activities but have been turned down?


> In the case of gstreamer 0.1, I was able to find how to install the 
> codecs:
[...]
> I am certainly sure that everyone is bored to tears on this subject 
> since I have mentioned it so many times already.

Did you "mention" it through the appropriate issue tracker?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


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

Re: [Sugar-devel] Current status of collaboration work

[James Simmons]

Tony,

I have been lurking on these mailing lists for the past few years but
haven't made any contribution to Sugar in that time. You may recall that I
wrote a couple of FLOSS manuals for OLPC, and strangely enough that led me
away from the project, because it convinced me I had a future as an author.
I've written and published a few books since then, none of which have found
as big an audience as the two FLOSS manuals did.

After reading your recent emails, I see that one of my FLOSS manuals is on
its way to being out of date, and my Sugar Activities are getting there
too. I'd like to fix that. I don't know how much time I'll have to devote
to this, but I want to do it.

I'd like to know more about this Tubes wrapper to start with. Is there
anything I can read to start learning about it?

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

[Sugar-devel] [DESIGN RFC] Onboarding

[Sam P.]

Hi All,

Sugar has a novel user interface, with lots of beautiful and logical
things.  However, there are some important elements (such as the frame or
journal) that are not familiar or intuitive to new users.  This is an
issue, as sugar currently relys upon exploration as our only user
onboarding strategy.

The un-intuitiveness of our ui comes up every now and again.  I previously
conducted a small and probably skewed survey, however the lack of user
onboarding and the effects of that (how users did not understand the
interface) were apparent.  It's also written about in Jeff Atwood's (old)
article "the Sugar UI", where he says, "I have to admit that I didn't find
the Sugar UI particularly intuitive or discoverable, even after using it
for 10 minutes and learning the basics."

Please have a look at my design proposal to add help for new users [1].  No
implementation has been done (as you would expect due to the time in the
release cycle), and comments would be appreciated to create a great design
before even thinking of implementing.

Thanks,
Sam

[1] http://www.sam.today/blog/sugar-onboard-design.html
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] email problem

[Tony Anderson]

Hi, Walter

I sent you an email with the results of my testing of the gci 
activities. I am having ipv6 troubles with
gmail. When I sent the mail through the olenepal (gmail) account - it 
didn't bounce, but I don't know

if it went through.

This problem started Dec. 9 and apparently only affects gmail accounts.

Yours,

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

Re: [Sugar-devel] [DESIGN RFC] Onboarding

[Tony Anderson]

Hi, Sam

Excellent proposal. We should solicit community input on additional 
items which experience users need to learn to get comfortable with using 
the XO.


I think your implementation involves too much programming. Perhaps a 
youtube style screencast walkthroughs and posters would be an alternative.


We intend for the XO and Sugar to facilitate learning - your are 
addressing one of the strategic issues with the OLPC concept - how to 
use it to introduce
users to the XO and Sugar. Many criticisms of the concept have focused 
on the inadequate level of training of teachers. We need to enable them 
and their students to continue to recall the training material and to  
learn more of the capabilities of the laptop after the support team leaves.


I think everyone understands that there are many capabilities of the 
laptop which will not be learned efficiently solely by exploration. I 
have never heard
Walter Bender introduce TurtleBlocks by saying 'launch the activity with 
the turtle icon and have fun'.


The first step is to get the new users able to use the XO. This is not 
intuitive. This introduction involves 'how to plug in the laptop', 
'observe the light
showing that the battery is charging - possibly even the quick flash 
when plugging in showing battery is there', 'how to open the laptop', 
'how to power on',
'how to launch an activity - record', 'How to take a self-portrait', 
'how to stop the activity', 'how to shut down the XO - emphasize the 
difference between shutdown and suspend', 'how to close the XO'. These 
are the minimum steps that must be learned to use the XO at all - and so 
must be presented without computer assistance.


If time permits, the user can switch to the Journal, change the name of 
the image from 'photo by nick', resume with imageviewer, stop imageviewer.


With record,  users need to learn to position themselves in front of the 
camera and not the screen - they bring the laptop close and are 
disappointed that their face is not visible.'. To use the camera as a 
camera, the simplest solution I've found is to convert it to tablet 
position (with record running), frame the picture through the left hole 
in the handle (under the lens), and shoot with the circle game button 
(also under the lens). This last is a good way to introduce the tablet 
configuration.


Sugar has some logical ui, but there are some that are also some 
illogical quirks. In the above case, the easiest way to switch to the 
Journal is to use the Journal button on the keyboard. However, after 
giving the picture a suitable name, getting back to record requires the 
frame. The Journal should not be 'an activity' so that a switch to the 
Journal should allow a return to the activity with the activity key. The 
Journal key makes the activity key redundant. Try collecting a series of 
screenshots to document an activity and you will know the problem!


Generally at a deployment, the user receives an XO with Sugar installed 
and ready for use. In that case an introduction to 'flashing' is not 
really needed. However, we have made life more difficult in recent 
releases with the 'gender' and 'class' screens. In most deployments, the 
laptops are prepared for use before school starts - at that time the 
school does not know who will be assigned to the laptop. In many 
deployments an XO is used by more than one student which means the nick 
and other information needs to be updated two to three times a day as 
the laptop changes hands.


It is very helpful, if there are posters on the class wall showing a 
good picture of the XO, a closeup of the keyboard with special keys 
marked, and pictures of the procedure for opening, powering up, and 
configuring in tablet mode. Sugarlabs could prepare images for this 
which could be made into posters locally at, in my experience, quite 
reasonable cost. This is needed by teachers who are new to the laptop 
and need to instruct their students on these basic procedures.
It is also needed as a reminder if a new student enters the class and 
the teacher asks one of the students to show the new student how to get 
started.


Tony

On 12/27/2015 08:20 AM, Sam P. wrote:

Hi All,

Sugar has a novel user interface, with lots of beautiful and logical 
things.  However, there are some important elements (such as the frame 
or journal) that are not familiar or intuitive to new users.  This is 
an issue, as sugar currently relys upon exploration as our only user 
onboarding strategy.


The un-intuitiveness of our ui comes up every now and again.  I 
previously conducted a small and probably skewed survey, however the 
lack of user onboarding and the effects of that (how users did not 
understand the interface) were apparent.  It's also written about in 
Jeff Atwood's (old) article "the Sugar UI", where he says, "I have to 
admit that I didn't find the Sugar UI particularly intuitive or 
discoverable, even after using it for 10 minutes and learning the 
basics."


Please