On May 6, 2014 9:47 AM, Daniel Narvaez dwnarv...@gmail.com wrote:
On 1 May 2014 14:42, kunal arora kunalarora@gmail.com wrote:
4)Create a new Sugar-toolkit-gtk3-python3 from the old one and also keep
the Sugar-toolkit-gtk3 for activities that haven't yet ported to Python3
and slowly
Obsoleting the gtk2 was an explicit decision. It's not that we don't care
but we just don't have enough resources to maintain two toolkits.
Completely breaking the API is really bad. It takes years for the
applications to switch and many of them never do it. We have seen it with
activities (and
On Tue, May 6, 2014 at 10:00 AM, Daniel Narvaez dwnarv...@gmail.com wrote:
Obsoleting the gtk2 was an explicit decision. It's not that we don't care
but we just don't have enough resources to maintain two toolkits.
Completely breaking the API is really bad. It takes years for the
applications
On Tue, May 6, 2014 at 5:57 AM, Peter Robinson pbrobin...@gmail.com wrote:
On Tue, May 6, 2014 at 10:00 AM, Daniel Narvaez dwnarv...@gmail.com
wrote:
Obsoleting the gtk2 was an explicit decision. It's not that we don't care
but we just don't have enough resources to maintain two toolkits.
I agree with Daniel.
We can't break compatibility again now.
The port from gtk2 to gtk3 was inevitable (needed to support touch devices,
and because some libraries like evince)
but at the time, required a huge amount of work,
without apparent benefits for the users (an a few regressions)
You need
On Tue, May 6, 2014 at 11:28 AM, Gonzalo Odiard godi...@sugarlabs.org wrote:
I agree with Daniel.
We can't break compatibility again now.
The port from gtk2 to gtk3 was inevitable (needed to support touch devices,
and because some libraries like evince)
but at the time, required a huge amount
The amount of work needed for either strategy will be almost the same but
in my opinion a codebase compatible with both python2 and python3 will
actually be harder to maintain as whenever we change something in the core
or toolkit we'll have to write polyglot code compatible with both python2
AND
These links can be useful:
https://docs.python.org/3/howto/pyporting.html
http://stackoverflow.com/questions/11372190/python-2-and-python-3-dual-development
https://pythonhosted.org/six/
Gonzalo
On Tue, May 6, 2014 at 8:50 AM, kunal arora kunalarora@gmail.comwrote:
The amount of work
On Tue, May 6, 2014 at 5:43 PM, Gonzalo Odiard godi...@sugarlabs.orgwrote:
These links can be useful:
https://docs.python.org/3/howto/pyporting.html
http://stackoverflow.com/questions/11372190/python-2-and-python-3-dual-development
https://pythonhosted.org/six/
Gonzalo
On Tue, May 6,
On 6 May 2014 12:28, Gonzalo Odiard godi...@sugarlabs.org wrote:
* Make core and toolkit compatible with python 2 3
Does core need to be compatible with both? It seems like we could just
always run it on python3.
___
Sugar-devel mailing list
On 6 May 2014 12:53, Peter Robinson pbrobin...@gmail.com wrote:
* Research and if possible port telepathy-python to introspection. Bonus
points if testing is possible.
I thought the whole point of introspection was to get rid of things
like telepathy-python. This was certainly the case
On 6 May 2014 13:50, kunal arora kunalarora@gmail.com wrote:
The amount of work needed for either strategy will be almost the same but
in my opinion a codebase compatible with both python2 and python3 will
actually be harder to maintain as whenever we change something in the core
or
On Tue, May 06, 2014 at 04:24:39PM +0200, Daniel Narvaez wrote:
[...] And with the XO stuck on Fedora 18 we might not have good
enough introspection to make the port compatible with it.
If anybody would like to work on moving olpc-os-builder to something
more recent, feel free. It isn't
On 1 May 2014 14:42, kunal arora kunalarora@gmail.com wrote:
4)Create a new Sugar-toolkit-gtk3-python3 from the old one and also keep
the Sugar-toolkit-gtk3 for activities that haven't yet ported to Python3
and slowly deprecate it with time as more and more activities shift to
Python3.
On 1 May 2014 14:42, kunal arora kunalarora@gmail.com wrote:
So, I did some research and found that it would be best to port sugar in
the following way:
1) Resolve the dependency issue - mainly telepathy . Telepathy-python has
been deprecated , so what would be the best way to deal with
So, I did some research and found that it would be best to port sugar in
the following way:
1) Resolve the dependency issue - mainly telepathy . Telepathy-python has
been deprecated , so what would be the best way to deal with this? Would it
best to just port it to python3 or something else?
16 matches
Mail list logo
