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

2015-12-29 Thread Tony Anderson

Hi, Walter

A quick survey of the 450 xos in my snapshot (including the installed 
set) shows 69 using sugar3 and 381 using sugar.


I'll try to prepare a list of the unconverted (infidel) for possible use 
as GCI tasks.



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

2015-12-27 Thread James Cameron
Very interesting discussion.

Perhaps the difficulties that Tony describes can be interpreted as
emergent properties of the development process.

However, others on private mailing lists, who are not so well
informed, perceived these emergent properties as intended outcomes.

These others are generally disengaged from the development process;
as users they are neither reporting tickets nor testing new versions.

They get what they pay for.

(I don't like private mailing lists or the segregation of community;
yet we keep increasing the segregation; e.g. socialhelp).

Overall, I'm encouraged.

-- 
James Cameron
http://quozl.netrek.org/
___
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

2015-12-27 Thread Tony Anderson

Hi, Walter

Because of gmail issue, I am sending this through Sugar-devel.

Most of the activities included in 0.106 (XO-1.5+) release have been 
moved to GTK3. The exceptions are:


Calculate, Clock, Implode, Labyrinth, Measure, Moon, Pippy, Record, 
Speak, and TurtleBlocks.


I suspect that many or even most of the remaining activities in ASLO 
have not been converted. I'll run a check on my snapshot (9/15) today to

identify ones that are not that could also be candidates for a GCI task.

So far only one GCI participant has reported attempting to update ASLO. 
The completed GCI activities will need to be updated on ASLO once we get

the problems with the dependent software resolved.

Meanwhile, kudos to Cristian for the work on ShowNTell. He replaced 
Hulahop with WebKit and also moved the activity to GTK3.


Tony

On 12/28/2015 12:24 AM, James Cameron wrote:

Very interesting discussion.

Perhaps the difficulties that Tony describes can be interpreted as
emergent properties of the development process.

However, others on private mailing lists, who are not so well
informed, perceived these emergent properties as intended outcomes.

These others are generally disengaged from the development process;
as users they are neither reporting tickets nor testing new versions.

They get what they pay for.

(I don't like private mailing lists or the segregation of community;
yet we keep increasing the segregation; e.g. socialhelp).

Overall, I'm encouraged.



___
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

2015-12-26 Thread 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

2015-12-26 Thread 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] Current status of GTK+ 3.x migration

2015-12-26 Thread 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 GTK+ 3.x migration

2015-12-26 Thread 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

2015-12-26 Thread 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 GTK+ 3.x migration

2015-12-26 Thread 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