On Wed, May 20, 2009 at 03:16:27PM +0200, Tomeu Vizoso wrote:
On Wed, May 13, 2009 at 15:40, Aleksey Lim alsr...@member.fsf.org wrote:
Hi all,
Do we really need activities in Sucrose release cycle?
I think it helps with localization.
Think about issue with last Browse which doesn't run on sugar 0.82
(but old Browse from 0.82 didn't have needed feature).
Another problem - small but valuable fixes(like updating i18n for example)
deployers have to patch it by themselves.
Or in common, new activity versions in sucrose-0.85 release cycle, are
they so 0.85 centric that 0.84(0.82) users cant use these versions.
Well, I think this is a matter of resources rather than of schedule.
If people can modify browse in such a way that works with past
versions, they should. But if it's too costly in matters of time...
These versions could be 0.85 centric but we could wrap all sucrose
related differences to toplevel API in separate package
(I use sugar-port for this purpose[1]).
For example on 0.84+ ObjectChooser(from sugar-port) will use
preselected mime type but on 0.82 only fake(errorless) code.
In that case activity authors can follow this API
and write sucrose independent activities.
Perhaps we should try to do more of it in the sugar toolkit level?
if we will extract sugar-toolkit from sucrose :)
i.e. with ObjectChooser we have 3 options
* no selectable mime types for 0.82
* selectable mime types only for predefined types for 0.84
* custom selectable mime types for 0.86(at least I hope)
If activity author wants his activity to be runnable on 0.82-0.86
he can:
* add try..except/if code to activity
* add sugar-port/chooser.py to his project and use its API
But how sugar-toolkit can be useful in this situation?
So, we have to use non sucrose package, otherwise upgrading
sugar-toolkit-0.82 to 0.86(when the rest of system is 0.82).
--
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
