Re: [sugar] Report on OLPC in Ethiopia
Hi Yamandu, I fed this into my self organising map (SOM) code. Here's the summary map generated for the report content: http://garycmartin.com/som/ethiopiareport_080227a-mh.jpg Oh, I was asked for a legend (on another list): http://garycmartin.com/som/SOM_legend.jpg --Gary On 9 May 2008, at 19:34, Yamandu Ploskonka wrote: > AFAIK this is the first published report in a format somewhat akin to > what people want to see when they ask for documented proof on how OLPC > is actually operating in the field. I contrast that to blogs and PR > efforts around the day of distribution of XOs. > > http://www.eduvision.ch/en/meta/documents/ethiopiareport_080227a- > mh.pdf > > The producer is a for-profit (?) consulting firm in Switzerland. > > Ed Cherlin has mentioned he has access to some other unpublished > reports > that might give a more complete picture > > Yama > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activities Portal: Proposal/suggestion
On Mon, May 19, 2008 at 5:37 PM, Eduardo H Silva <[EMAIL PROTECTED]> wrote: > I hope such a UI be developers friendly, i.e., not just be a list of > activities which seemingly where made by magic elves ;) , providing no > extra information of who made them or how to contact them. It can be anything we want it to be. In fact, that's why I bring it up now for discussion. I hope that we can pull together a loose direction for it that's in sync with (or at least complimentary to) a more centralized web presence, since ultimately any system is only as good as the activities that run on it, and I think making the process of finding/obtaining new activities dead simple is in everyones' best interests! - Eben > 2008/5/19, Eben Eliason <[EMAIL PROTECTED]>: >> I know I've tossed this out several times before, but I do so again to >> be sure its in the backs of everyone's minds, at least once. I think >> the idea of creating an "appcast", or an RSS feed with enclosures for >> bundles/updates, could be a clean way to handle the backend for such a >> service. Obviously, any number of websites could aggregate these, or >> display them with various UIs, but it might not need to be entirely >> centralized. >> >> I /really/ want to push forward the idea of a button within the UI for >> "getting more activities". I encourage everyone to consider this use >> case as well when thinking about such a portal. This button will >> probably, in most cases, connect kids to the school server as a first >> level repository, but could just as easily connect to any such >> appcast, at the school, city, country, or even global level. If we >> actually support one or more of these feeds, then these all serve as >> sources for activity (and content?) bundles which can be displayed >> directly within the UI, in whatever interface suits, rather than >> requiring kids to go to this or that website. >> >> This technique can also be used to notify kids of updates to existing >> activities. Also, for what it's worth, one could foresee the >> capability of an activity such as Develop to set up local appcasts for >> activities that kids create as well; there could be one feed for all >> of Jimmy's activities. From this perspective, no server is even >> needed at all for "get more activities" to have some meaning, because >> the feed could come from others on the mesh as well. >> >> - Eben >> >> >> On Mon, May 19, 2008 at 2:37 PM, Jim Gettys <[EMAIL PROTECTED]> wrote: >>> On Mon, 2008-05-19 at 23:56 +0530, Sayamindu Dasgupta wrote: Has anyone evaluated Remora (http://wiki.mozilla.org/Update:Remora) for this ? This is the software which powers addons.mozilla.org Cheers, Sayamindu >>> >>> It is clearly closest to what we need. Just haven't had the time to >>> make it happen. >>> >>> If someone wants to go for it, please go ahead and try it; when you need >>> access to install something (we have lots of bandwidth available), we'll >>> be happy to help host it. >>> - Jim >>> On Mon, May 19, 2008 at 11:47 PM, Morgan Collett <[EMAIL PROTECTED]> wrote: > On Mon, May 19, 2008 at 5:16 PM, Marco Pesenti Gritti > <[EMAIL PROTECTED]> wrote: >> Please wikify this! :) >> >> There is a note about something like this at the end of the doc page >> which would be good to link: >> http://wiki.sugarlabs.org/go/Documentation > > http://wiki.sugarlabs.org/go/Activity_portal > > >> On Mon, May 19, 2008 at 5:08 PM, Morgan Collett >> <[EMAIL PROTECTED]> wrote: >>> I've been thinking about a better portal for downloading activities. >>> I >>> came up with some ideas, that I unfortunately don't have time to >>> implement, but I would be happy to cheer someone on if they are >>> inspired by this... >>> >>> It should be easy to upload an activity (specifically after the first >>> time it has been done) - easier than uploading to the wiki. >>> >>> Activities should be categorised according to various properties, >>> including: >>> * The usual activity metadata from activity.info >>> * Descriptions, as in http://wiki.laptop.org/go/Activities >>> * Category, as in http://wiki.laptop.org/go/Activities >>> * Age ranges the activity is suitable for? (Possibly a Mature >>> category >>> for Doom?) >>> * Competencies required: Pre-reading, reading, writing, ... >>> * Development maturity >>> - like sourceforge: planning / pre-alpha / alpha / beta / stable >>> * Collaborative? >>> - yes / no / only (for activities like Connect or Chat that don't >>> function as a single user activity) >>> * Requires Internet? (e.g. Gmail) >>> * Compatible with: Sugar / Glucose version or OLPC release or distro >>> release... e.g. Sugar >= 0.81 >>> * Additional Dependencies (e.g. video-chat-activity needs extra RPMs >>> not in a
[sugar] Resp.: Activities Portal: Proposal/suggestion
I hope such a UI be developers friendly, i.e., not just be a list of activities which seemingly where made by magic elves ;) , providing no extra information of who made them or how to contact them. 2008/5/19, Eben Eliason <[EMAIL PROTECTED]>: > I know I've tossed this out several times before, but I do so again to > be sure its in the backs of everyone's minds, at least once. I think > the idea of creating an "appcast", or an RSS feed with enclosures for > bundles/updates, could be a clean way to handle the backend for such a > service. Obviously, any number of websites could aggregate these, or > display them with various UIs, but it might not need to be entirely > centralized. > > I /really/ want to push forward the idea of a button within the UI for > "getting more activities". I encourage everyone to consider this use > case as well when thinking about such a portal. This button will > probably, in most cases, connect kids to the school server as a first > level repository, but could just as easily connect to any such > appcast, at the school, city, country, or even global level. If we > actually support one or more of these feeds, then these all serve as > sources for activity (and content?) bundles which can be displayed > directly within the UI, in whatever interface suits, rather than > requiring kids to go to this or that website. > > This technique can also be used to notify kids of updates to existing > activities. Also, for what it's worth, one could foresee the > capability of an activity such as Develop to set up local appcasts for > activities that kids create as well; there could be one feed for all > of Jimmy's activities. From this perspective, no server is even > needed at all for "get more activities" to have some meaning, because > the feed could come from others on the mesh as well. > > - Eben > > > On Mon, May 19, 2008 at 2:37 PM, Jim Gettys <[EMAIL PROTECTED]> wrote: >> On Mon, 2008-05-19 at 23:56 +0530, Sayamindu Dasgupta wrote: >>> Has anyone evaluated Remora (http://wiki.mozilla.org/Update:Remora) >>> for this ? This is the software which powers addons.mozilla.org >>> Cheers, >>> Sayamindu >> >> It is clearly closest to what we need. Just haven't had the time to >> make it happen. >> >> If someone wants to go for it, please go ahead and try it; when you need >> access to install something (we have lots of bandwidth available), we'll >> be happy to help host it. >> - Jim >> >>> >>> On Mon, May 19, 2008 at 11:47 PM, Morgan Collett >>> <[EMAIL PROTECTED]> wrote: >>> > On Mon, May 19, 2008 at 5:16 PM, Marco Pesenti Gritti >>> > <[EMAIL PROTECTED]> wrote: >>> >> Please wikify this! :) >>> >> >>> >> There is a note about something like this at the end of the doc page >>> >> which would be good to link: >>> >> http://wiki.sugarlabs.org/go/Documentation >>> > >>> > http://wiki.sugarlabs.org/go/Activity_portal >>> > >>> > >>> >> On Mon, May 19, 2008 at 5:08 PM, Morgan Collett >>> >> <[EMAIL PROTECTED]> wrote: >>> >>> I've been thinking about a better portal for downloading activities. >>> >>> I >>> >>> came up with some ideas, that I unfortunately don't have time to >>> >>> implement, but I would be happy to cheer someone on if they are >>> >>> inspired by this... >>> >>> >>> >>> It should be easy to upload an activity (specifically after the first >>> >>> time it has been done) - easier than uploading to the wiki. >>> >>> >>> >>> Activities should be categorised according to various properties, >>> >>> including: >>> >>> * The usual activity metadata from activity.info >>> >>> * Descriptions, as in http://wiki.laptop.org/go/Activities >>> >>> * Category, as in http://wiki.laptop.org/go/Activities >>> >>> * Age ranges the activity is suitable for? (Possibly a Mature >>> >>> category >>> >>> for Doom?) >>> >>> * Competencies required: Pre-reading, reading, writing, ... >>> >>> * Development maturity >>> >>> - like sourceforge: planning / pre-alpha / alpha / beta / stable >>> >>> * Collaborative? >>> >>> - yes / no / only (for activities like Connect or Chat that don't >>> >>> function as a single user activity) >>> >>> * Requires Internet? (e.g. Gmail) >>> >>> * Compatible with: Sugar / Glucose version or OLPC release or distro >>> >>> release... e.g. Sugar >= 0.81 >>> >>> * Additional Dependencies (e.g. video-chat-activity needs extra RPMs >>> >>> not in a build) >>> >>> * Tags >>> >>> * Languages - pulled out of the .xo >>> >>> * Low power friendly? >>> >>> * Related activities (for suites or alternatives) >>> >>> * Screenshot >>> >>> >>> >>> Activities have Releases, which have status similar to the >>> >>> development >>> >>> maturity - Suitable for: development / QA / public release etc - and >>> >>> of course the downloadable bundle for that release... >>> >>> >>> >>> The site should be internationalisable using standard i18n tools. >>> >>> >>> >>> Bonus points for: >>> >>> * Publishing a text page like >>> >>> http://mock.laptop.org/repos/local.
[sugar] [PATCH] Update only when visible (Journal)
Hi,
during activity launching, a new journal entry is created. As the
journal is listening for changes in the DS and updating its UI
accordingly, if that update operation is costly in terms of CPU, the
activity startup process can be affected.
This patch avoids the journal updating itself when it is not the
active activity, and in tests with 3500 entries, I saw a saving of 3s.
during activity startup.
Thanks,
Tomeu
From 04ebec2bc5628adcd9c0c5e62b0b6849724d9436 Mon Sep 17 00:00:00 2001
From: Tomeu Vizoso <[EMAIL PROTECTED]>
Date: Mon, 19 May 2008 19:21:08 +0200
Subject: [PATCH] Update only when visible.
---
journalactivity.py | 51 --
listview.py| 11 +--
misc.py| 11 ++
query.py | 78 +--
4 files changed, 50 insertions(+), 101 deletions(-)
diff --git a/journalactivity.py b/journalactivity.py
index 78d9a53..20ea4e8 100755
--- a/journalactivity.py
+++ b/journalactivity.py
@@ -120,7 +120,10 @@ class JournalActivity(activity.Activity):
self.set_title(_('Journal'))
-self._update_timer = None
+self._fully_obscured = True
+self._dirty = False
+self._refresh_idle_handler = None
+self._update_dates_timer = None
self.iconify()
self._setup_main_view()
@@ -233,7 +236,29 @@ class JournalActivity(activity.Activity):
self._main_toolbox.search_toolbar.set_volume_id(volume_id)
self._main_toolbox.set_current_toolbar(0)
+def _set_dirty(self):
+if self._fully_obscured:
+self._dirty = True
+else:
+self._schedule_refresh()
+
+def _schedule_refresh(self):
+if self._refresh_idle_handler is None:
+logging.debug('Add refresh idle calback')
+self._refresh_idle_handler = gobject.idle_add(
+self.__refresh_list_view_idle_cb)
+
+def __refresh_list_view_idle_cb(self):
+self._list_view.refresh()
+self._dirty = False
+if self._refresh_idle_handler is not None:
+logging.debug('Remove refresh idle calback')
+gobject.source_remove(self._refresh_idle_handler)
+self._refresh_idle_handler = None
+return False
+
def _data_store_created_cb(self, uid):
+self._set_dirty()
jobject = datastore.get(uid)
if jobject is None:
return
@@ -244,6 +269,7 @@ class JournalActivity(activity.Activity):
self._main_toolbox.search_toolbar.refresh_filters()
def _data_store_updated_cb(self, uid):
+self._set_dirty()
jobject = datastore.get(uid)
if jobject is None:
return
@@ -251,10 +277,11 @@ class JournalActivity(activity.Activity):
self._check_for_bundle(jobject)
finally:
jobject.destroy()
-
+
def _data_store_deleted_cb(self, uid):
if uid == self._detail_view.props.jobject.object_id:
self._show_main_view()
+self._set_dirty()
def _focus_in_event_cb(self, window, event):
self.search_grab_focus()
@@ -286,19 +313,25 @@ class JournalActivity(activity.Activity):
search_toolbar = self._main_toolbox.search_toolbar
search_toolbar._search_entry.grab_focus()
-def __update_timer_cb(self):
+def __update_dates_timer_cb(self):
self._list_view.update_dates()
return True
def __visibility_notify_event_cb(self, window, event):
if event.state == gtk.gdk.VISIBILITY_FULLY_OBSCURED:
-if self._update_timer is not None:
-gobject.source_remove(self._update_timer)
-self._update_timer = None
+self._fully_obscured = True
+if self._update_dates_timer is not None:
+logging.debug('Remove date updating timer')
+gobject.source_remove(self._update_dates_timer)
+self._update_dates_timer = None
else:
-if self._update_timer is None:
-self._update_timer = gobject.timeout_add(UPDATE_INTERVAL,
- self.__update_timer_cb)
+self._fully_obscured = False
+if self._dirty:
+self._schedule_refresh()
+if self._update_dates_timer is None:
+logging.debug('Adding date updating timer')
+self._update_dates_timer = gobject.timeout_add(UPDATE_INTERVAL,
+ self.__update_dates_timer_cb)
def take_screenshot(self):
# Don't take any screenshot. Only makes the system slower.
diff --git a/listview.py b/listview.py
index 1e3ff7f..2611bc4 100644
--- a/listview.py
+++ b/listview.py
@@ -147,8 +147,8 @@ class ListView(gtk.HBox):
entry.jobject = jobjects[i]
entry.set_visible(True)
[sugar] [PATCH] Fix logging setup
Hi,
this patch worksaround a weirdness in logging.basicConfig by which it
won't have any effect if there's already a Handler in the root logger.
Any previous call to logging.debug will autocreate a handler,
rendering our logger configuration ineffective.
Thanks,
Tomeu
From 39b98ed5331b31ec1b8adca398e1fbb491dcfc40 Mon Sep 17 00:00:00 2001
From: Tomeu Vizoso <[EMAIL PROTECTED]>
Date: Mon, 19 May 2008 21:57:22 +0200
Subject: [PATCH] Fix logging setup.
---
src/sugar/logger.py |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/sugar/logger.py b/src/sugar/logger.py
index 4703fc3..37d5dc8 100644
--- a/src/sugar/logger.py
+++ b/src/sugar/logger.py
@@ -48,6 +48,11 @@ def _except_hook(exctype, value, traceback):
sys.excepthook(exctype, value, traceback)
def start(log_filename=None):
+# remove existing handlers, or logging.basicConfig() won't have no effect.
+root_logger = logging.getLogger('')
+for handler in root_logger.handlers:
+root_logger.removeHandler(handler)
+
logging.basicConfig(level=logging.WARNING,
format="%(created)f %(levelname)s %(name)s: %(message)s")
--
1.5.2.5
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activities Portal: Proposal/suggestion
I know I've tossed this out several times before, but I do so again to be sure its in the backs of everyone's minds, at least once. I think the idea of creating an "appcast", or an RSS feed with enclosures for bundles/updates, could be a clean way to handle the backend for such a service. Obviously, any number of websites could aggregate these, or display them with various UIs, but it might not need to be entirely centralized. I /really/ want to push forward the idea of a button within the UI for "getting more activities". I encourage everyone to consider this use case as well when thinking about such a portal. This button will probably, in most cases, connect kids to the school server as a first level repository, but could just as easily connect to any such appcast, at the school, city, country, or even global level. If we actually support one or more of these feeds, then these all serve as sources for activity (and content?) bundles which can be displayed directly within the UI, in whatever interface suits, rather than requiring kids to go to this or that website. This technique can also be used to notify kids of updates to existing activities. Also, for what it's worth, one could foresee the capability of an activity such as Develop to set up local appcasts for activities that kids create as well; there could be one feed for all of Jimmy's activities. From this perspective, no server is even needed at all for "get more activities" to have some meaning, because the feed could come from others on the mesh as well. - Eben On Mon, May 19, 2008 at 2:37 PM, Jim Gettys <[EMAIL PROTECTED]> wrote: > On Mon, 2008-05-19 at 23:56 +0530, Sayamindu Dasgupta wrote: >> Has anyone evaluated Remora (http://wiki.mozilla.org/Update:Remora) >> for this ? This is the software which powers addons.mozilla.org >> Cheers, >> Sayamindu > > It is clearly closest to what we need. Just haven't had the time to > make it happen. > > If someone wants to go for it, please go ahead and try it; when you need > access to install something (we have lots of bandwidth available), we'll > be happy to help host it. > - Jim > >> >> On Mon, May 19, 2008 at 11:47 PM, Morgan Collett >> <[EMAIL PROTECTED]> wrote: >> > On Mon, May 19, 2008 at 5:16 PM, Marco Pesenti Gritti >> > <[EMAIL PROTECTED]> wrote: >> >> Please wikify this! :) >> >> >> >> There is a note about something like this at the end of the doc page >> >> which would be good to link: >> >> http://wiki.sugarlabs.org/go/Documentation >> > >> > http://wiki.sugarlabs.org/go/Activity_portal >> > >> > >> >> On Mon, May 19, 2008 at 5:08 PM, Morgan Collett >> >> <[EMAIL PROTECTED]> wrote: >> >>> I've been thinking about a better portal for downloading activities. I >> >>> came up with some ideas, that I unfortunately don't have time to >> >>> implement, but I would be happy to cheer someone on if they are >> >>> inspired by this... >> >>> >> >>> It should be easy to upload an activity (specifically after the first >> >>> time it has been done) - easier than uploading to the wiki. >> >>> >> >>> Activities should be categorised according to various properties, >> >>> including: >> >>> * The usual activity metadata from activity.info >> >>> * Descriptions, as in http://wiki.laptop.org/go/Activities >> >>> * Category, as in http://wiki.laptop.org/go/Activities >> >>> * Age ranges the activity is suitable for? (Possibly a Mature category >> >>> for Doom?) >> >>> * Competencies required: Pre-reading, reading, writing, ... >> >>> * Development maturity >> >>> - like sourceforge: planning / pre-alpha / alpha / beta / stable >> >>> * Collaborative? >> >>> - yes / no / only (for activities like Connect or Chat that don't >> >>> function as a single user activity) >> >>> * Requires Internet? (e.g. Gmail) >> >>> * Compatible with: Sugar / Glucose version or OLPC release or distro >> >>> release... e.g. Sugar >= 0.81 >> >>> * Additional Dependencies (e.g. video-chat-activity needs extra RPMs >> >>> not in a build) >> >>> * Tags >> >>> * Languages - pulled out of the .xo >> >>> * Low power friendly? >> >>> * Related activities (for suites or alternatives) >> >>> * Screenshot >> >>> >> >>> Activities have Releases, which have status similar to the development >> >>> maturity - Suitable for: development / QA / public release etc - and >> >>> of course the downloadable bundle for that release... >> >>> >> >>> The site should be internationalisable using standard i18n tools. >> >>> >> >>> Bonus points for: >> >>> * Publishing a text page like >> >>> http://mock.laptop.org/repos/local.update1/XOS/index.html at >> >>> predictable URLs that lists activities compatible with a given >> >>> release, for easy downloading with scripts etc. >> >>> * Publishing the source in public distributed revision control, to get >> >>> easy contributions to code / templates >> >>> * Deployment on a system that is monitored and actively sysadmined >> >>> * Implementation in a Python web framewo
Re: [sugar] Activities Portal: Proposal/suggestion
On Mon, 2008-05-19 at 23:56 +0530, Sayamindu Dasgupta wrote: > Has anyone evaluated Remora (http://wiki.mozilla.org/Update:Remora) > for this ? This is the software which powers addons.mozilla.org > Cheers, > Sayamindu It is clearly closest to what we need. Just haven't had the time to make it happen. If someone wants to go for it, please go ahead and try it; when you need access to install something (we have lots of bandwidth available), we'll be happy to help host it. - Jim > > On Mon, May 19, 2008 at 11:47 PM, Morgan Collett > <[EMAIL PROTECTED]> wrote: > > On Mon, May 19, 2008 at 5:16 PM, Marco Pesenti Gritti > > <[EMAIL PROTECTED]> wrote: > >> Please wikify this! :) > >> > >> There is a note about something like this at the end of the doc page > >> which would be good to link: > >> http://wiki.sugarlabs.org/go/Documentation > > > > http://wiki.sugarlabs.org/go/Activity_portal > > > > > >> On Mon, May 19, 2008 at 5:08 PM, Morgan Collett > >> <[EMAIL PROTECTED]> wrote: > >>> I've been thinking about a better portal for downloading activities. I > >>> came up with some ideas, that I unfortunately don't have time to > >>> implement, but I would be happy to cheer someone on if they are > >>> inspired by this... > >>> > >>> It should be easy to upload an activity (specifically after the first > >>> time it has been done) - easier than uploading to the wiki. > >>> > >>> Activities should be categorised according to various properties, > >>> including: > >>> * The usual activity metadata from activity.info > >>> * Descriptions, as in http://wiki.laptop.org/go/Activities > >>> * Category, as in http://wiki.laptop.org/go/Activities > >>> * Age ranges the activity is suitable for? (Possibly a Mature category > >>> for Doom?) > >>> * Competencies required: Pre-reading, reading, writing, ... > >>> * Development maturity > >>> - like sourceforge: planning / pre-alpha / alpha / beta / stable > >>> * Collaborative? > >>> - yes / no / only (for activities like Connect or Chat that don't > >>> function as a single user activity) > >>> * Requires Internet? (e.g. Gmail) > >>> * Compatible with: Sugar / Glucose version or OLPC release or distro > >>> release... e.g. Sugar >= 0.81 > >>> * Additional Dependencies (e.g. video-chat-activity needs extra RPMs > >>> not in a build) > >>> * Tags > >>> * Languages - pulled out of the .xo > >>> * Low power friendly? > >>> * Related activities (for suites or alternatives) > >>> * Screenshot > >>> > >>> Activities have Releases, which have status similar to the development > >>> maturity - Suitable for: development / QA / public release etc - and > >>> of course the downloadable bundle for that release... > >>> > >>> The site should be internationalisable using standard i18n tools. > >>> > >>> Bonus points for: > >>> * Publishing a text page like > >>> http://mock.laptop.org/repos/local.update1/XOS/index.html at > >>> predictable URLs that lists activities compatible with a given > >>> release, for easy downloading with scripts etc. > >>> * Publishing the source in public distributed revision control, to get > >>> easy contributions to code / templates > >>> * Deployment on a system that is monitored and actively sysadmined > >>> * Implementation in a Python web framework, to tap into the existing > >>> developer community :) > >>> * A catchy name... > >>> > >>> Future features: > >>> * Download statistics > >>> * Feedback to the author(s) > >>> > >>> Regards > >>> Morgan > >>> ___ > >>> Sugar mailing list > >>> Sugar@lists.laptop.org > >>> http://lists.laptop.org/listinfo/sugar > >>> > >> > > ___ > > Devel mailing list > > [EMAIL PROTECTED] > > http://lists.laptop.org/listinfo/devel > > > > > -- Jim Gettys <[EMAIL PROTECTED]> One Laptop Per Child ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activities Portal: Proposal/suggestion
Has anyone evaluated Remora (http://wiki.mozilla.org/Update:Remora) for this ? This is the software which powers addons.mozilla.org Cheers, Sayamindu On Mon, May 19, 2008 at 11:47 PM, Morgan Collett <[EMAIL PROTECTED]> wrote: > On Mon, May 19, 2008 at 5:16 PM, Marco Pesenti Gritti > <[EMAIL PROTECTED]> wrote: >> Please wikify this! :) >> >> There is a note about something like this at the end of the doc page >> which would be good to link: >> http://wiki.sugarlabs.org/go/Documentation > > http://wiki.sugarlabs.org/go/Activity_portal > > >> On Mon, May 19, 2008 at 5:08 PM, Morgan Collett >> <[EMAIL PROTECTED]> wrote: >>> I've been thinking about a better portal for downloading activities. I >>> came up with some ideas, that I unfortunately don't have time to >>> implement, but I would be happy to cheer someone on if they are >>> inspired by this... >>> >>> It should be easy to upload an activity (specifically after the first >>> time it has been done) - easier than uploading to the wiki. >>> >>> Activities should be categorised according to various properties, including: >>> * The usual activity metadata from activity.info >>> * Descriptions, as in http://wiki.laptop.org/go/Activities >>> * Category, as in http://wiki.laptop.org/go/Activities >>> * Age ranges the activity is suitable for? (Possibly a Mature category >>> for Doom?) >>> * Competencies required: Pre-reading, reading, writing, ... >>> * Development maturity >>> - like sourceforge: planning / pre-alpha / alpha / beta / stable >>> * Collaborative? >>> - yes / no / only (for activities like Connect or Chat that don't >>> function as a single user activity) >>> * Requires Internet? (e.g. Gmail) >>> * Compatible with: Sugar / Glucose version or OLPC release or distro >>> release... e.g. Sugar >= 0.81 >>> * Additional Dependencies (e.g. video-chat-activity needs extra RPMs >>> not in a build) >>> * Tags >>> * Languages - pulled out of the .xo >>> * Low power friendly? >>> * Related activities (for suites or alternatives) >>> * Screenshot >>> >>> Activities have Releases, which have status similar to the development >>> maturity - Suitable for: development / QA / public release etc - and >>> of course the downloadable bundle for that release... >>> >>> The site should be internationalisable using standard i18n tools. >>> >>> Bonus points for: >>> * Publishing a text page like >>> http://mock.laptop.org/repos/local.update1/XOS/index.html at >>> predictable URLs that lists activities compatible with a given >>> release, for easy downloading with scripts etc. >>> * Publishing the source in public distributed revision control, to get >>> easy contributions to code / templates >>> * Deployment on a system that is monitored and actively sysadmined >>> * Implementation in a Python web framework, to tap into the existing >>> developer community :) >>> * A catchy name... >>> >>> Future features: >>> * Download statistics >>> * Feedback to the author(s) >>> >>> Regards >>> Morgan >>> ___ >>> Sugar mailing list >>> Sugar@lists.laptop.org >>> http://lists.laptop.org/listinfo/sugar >>> >> > ___ > Devel mailing list > [EMAIL PROTECTED] > http://lists.laptop.org/listinfo/devel > -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activities Portal: Proposal/suggestion
On Mon, May 19, 2008 at 5:16 PM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > Please wikify this! :) > > There is a note about something like this at the end of the doc page > which would be good to link: > http://wiki.sugarlabs.org/go/Documentation http://wiki.sugarlabs.org/go/Activity_portal > On Mon, May 19, 2008 at 5:08 PM, Morgan Collett > <[EMAIL PROTECTED]> wrote: >> I've been thinking about a better portal for downloading activities. I >> came up with some ideas, that I unfortunately don't have time to >> implement, but I would be happy to cheer someone on if they are >> inspired by this... >> >> It should be easy to upload an activity (specifically after the first >> time it has been done) - easier than uploading to the wiki. >> >> Activities should be categorised according to various properties, including: >> * The usual activity metadata from activity.info >> * Descriptions, as in http://wiki.laptop.org/go/Activities >> * Category, as in http://wiki.laptop.org/go/Activities >> * Age ranges the activity is suitable for? (Possibly a Mature category >> for Doom?) >> * Competencies required: Pre-reading, reading, writing, ... >> * Development maturity >> - like sourceforge: planning / pre-alpha / alpha / beta / stable >> * Collaborative? >> - yes / no / only (for activities like Connect or Chat that don't >> function as a single user activity) >> * Requires Internet? (e.g. Gmail) >> * Compatible with: Sugar / Glucose version or OLPC release or distro >> release... e.g. Sugar >= 0.81 >> * Additional Dependencies (e.g. video-chat-activity needs extra RPMs >> not in a build) >> * Tags >> * Languages - pulled out of the .xo >> * Low power friendly? >> * Related activities (for suites or alternatives) >> * Screenshot >> >> Activities have Releases, which have status similar to the development >> maturity - Suitable for: development / QA / public release etc - and >> of course the downloadable bundle for that release... >> >> The site should be internationalisable using standard i18n tools. >> >> Bonus points for: >> * Publishing a text page like >> http://mock.laptop.org/repos/local.update1/XOS/index.html at >> predictable URLs that lists activities compatible with a given >> release, for easy downloading with scripts etc. >> * Publishing the source in public distributed revision control, to get >> easy contributions to code / templates >> * Deployment on a system that is monitored and actively sysadmined >> * Implementation in a Python web framework, to tap into the existing >> developer community :) >> * A catchy name... >> >> Future features: >> * Download statistics >> * Feedback to the author(s) >> >> Regards >> Morgan >> ___ >> Sugar mailing list >> Sugar@lists.laptop.org >> http://lists.laptop.org/listinfo/sugar >> > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Build only updated modules in jhbuild?
uff jhbuild is so painful marcopg: you have build_policy = 'updated' at least right? walters: nope, didn't know about it... in the jhbuildrc? yep cool, will try it out marcopg: makes jhbuild about 5,000,000 times saner =) Sounds like something we might want to consider for sugar-jhbuild (as default, I mean). Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Activity Proposal] Develop
I think we should aim at including Develop in 0.84. It's an essential activity but it's not tested a lot, it will require complex glucose changes and the maintenance situation is undefined at the moment. (Just in the case it's not clear, this is *my* opinion. Discussion and more opinions are welcome!) Marco On Fri, May 16, 2008 at 7:40 PM, Jameson Chema Quinn <[EMAIL PROTECTED]> wrote: > I would like to propose Develop for inclusion in Sugar releases. This > application is a bit premature, but somebody mentioned that the > decisions for next release are coming up next week, so I'm pushing it > out there. > > * Short description of the features. > Ability to edit and package activities, esp. python-based ones. > > * Screenshots or screencasts. > http://wiki.laptop.org/go/Image:Develop-screenshot.png > > * Are you willing to follow the Schedule? > If I can feed my family while I do so, yes. (I am currently applying > for a position as a contractor for OLPC to work on this. Depends on > the resolution of that.) > > * System components the activity depends on. > Critical dependence on bundlebuilder.py and activitybundle.py; I am > currently updating those to a new bundle format, which will make them > dependent on a Sugar crypto service, which will depend on python's > crypto and ezpythoncrypto modules. > > * Members of the developer team. > Jameson Quinn (me) > Others have contributed but nobody else seems to be on this right now. > > * Status of internationalization. > Barely started. I can do Spanish myself. (Internationalization of the > code is my dream feature, but here I refer to internationalization of > the activity. There are few strings. > > * Code repository. > git://dev.laptop.org/activities/develop > > * Bug tracking system. > trac : dev.laptop.org > > * Planned feature for this release cycle > as mentioned above, bulletproof bundles and some support for > versioning (dev and stable versions). The activity can break, but it > should at least bundle itself up correctly. Beyond that, depends on > voting at http://wiki.laptop.org/go/Develop/roadmap . > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity Proposal: Pippy
I think Pippy should be in. It's well maintained and well tested. And it's the best way for kids to start playing with python. Marco On Sat, May 17, 2008 at 6:44 PM, Chris Ball <[EMAIL PROTECTED]> wrote: > Following the procedure at http://wiki.sugarlabs.org/go/Release, > here's the proposal for Pippy: > > * Short description of the features: > > Pippy is a simple and fun introduction to programming in Python. > > No new features planned for the near future. (Patches welcome, though.) > > * Screenshots or screencasts: > > http://wiki.laptop.org/go/Pippy > > * Are you willing to follow the Schedule? > > Yes > > * System components the activity depends on: > > gtksourceview > > * Members of the developer team: > > Chris Ball, C. Scott Ananian. > > * Status of internationalization: > > In pootle > > * Code repository: > > git://dev.laptop.org/projects/pippy-activity > > * Bug tracking system: > > pippy-activity in dev.laptop.org Trac > > Thanks, > > - Chris. > -- > Chris Ball <[EMAIL PROTECTED]> > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] hot corners
Actually, Mel's youth did some keyboard evaluations for us early on in the program and they do have some XOs. They are a very capable group. -walter On Mon, May 19, 2008 at 9:31 AM, Greg Smith (gregmsmi) <[EMAIL PROTECTED]> wrote: > Hi Guys, > > Sounds like Walter is on it. My 2 cents, ask this question and figure > how to more questions like this in the future. Also, if representatives > from deployments are in Cambridge this week, make sure to raise the > question there. > > After our last exchange a month ago, I thought about ways to gather user > input on future GUI design. The developer key and need to load a special > build was the first show stopper. The second was that you can't stop > class to test new code. E.g. Tim from Waveplace said he can't interfere > with deployments and learning to "beta" test. > > I sent a link to the new sugar GUI to a lead in Peru but I don't think > he really "grokked" the new design. May be because its static or because > its in English. Bottom line is that I don't think those pages alone will > get you the quality input needed. > > I'll try again with a link to new design and questions on current frame > on the [EMAIL PROTECTED] list. > > Long term you need a standing lab. I believe I saw David Cavallo meeting > with Mel King some time ago. Mel started a technology center for kids n > Boston: http://www.tech-center-enlightentcity.tv/ > > With 10 - 20 Xos and their buy in, that could be your usability lab. I > think David Cavallo will have contacts to get that started. > > Sorry, I wont have time to do a lot of work on that in the near future > :-( I can send a couple of e-mails a week but otherwise have to pass he > buck. > > Thanks, > > Greg S > > BTW I'm not on the sugar list (e-mail is maxed out). Please forward > there as needed. I'll also comment one more time on Frame thread on > devel list. > > -Original Message- > From: Walter Bender [mailto:[EMAIL PROTECTED] > Sent: Saturday, May 17, 2008 11:34 PM > To: Marco Pesenti Gritti > Cc: Simon Schampijer; Greg Smith (gregmsmi); Eben Eliason; Sugar List > Subject: Re: [sugar] hot corners > > Let me talk to Carla, Miguel, and Hernan this week. They should be able > to help us out with some kid testing. > > -walter > > On Sat, May 17, 2008 at 7:55 AM, Marco Pesenti Gritti > <[EMAIL PROTECTED]> wrote: >> On Fri, May 16, 2008 at 4:22 AM, Simon Schampijer > <[EMAIL PROTECTED]> wrote: >>> Eben I only added a slider for the delay of the activation of the hot > corners. >>> By default the delay is zero. >>> >>> And since I wanted to test out how the warm edge works in general I >>> added a top warm edge since I tapped myself moving the mouse there >>> when I wanted to switch activities. >>> >>> I can make another rpm with warm edges all around and a separate >>> delay option so we can test it out how it feels. >>> >>> Did you actually tested the rpm I provided? >> >> I think we can't figure out which options to provide exactly before >> understanding the problem better and having done some usability >> testing. >> >> We have a general problem to solve here... How do we do simple >> usability testing with kids? Do we have contacts in the deployments >> that we can use do so? Are they comfortable to install a joyride build > >> (and maybe an rpm)? >> >> Marco >> ___ >> Sugar mailing list >> Sugar@lists.laptop.org >> http://lists.laptop.org/listinfo/sugar >> > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Patch to make Browse annoy me less.
pray pardon my ignorance. talking of Browser annoyances :-) Is ad filtering to happen at the server level, or is there a way to implement it on the XO? I vote for server (one fix for all), especially if there is a simple mechanism that can update such filter info directly from the teacher XO without needing to mess with the XS itself. Then it wouldn't be a "sugar" problem but XS's :-) Yet it would be nice Browser didn't have to load the standard nonsense that comes along with too many pages these days Yama Eben Eliason wrote: > Just a high level take on these patches... > > On Thu, May 15, 2008 at 10:46 PM, Cortland Setlow > <[EMAIL PROTECTED]> wrote: > >> Hi, >> >> This patch does three things, and I'll be happy if even one makes it in to >> Browse. >> >> It causes ctrl-l (lowercase L) to put focus on the address bar like in all >> other browsers that do not make me angry. >> > > Sounds good to me. Adherence to well known shortcuts is usually a > win, and this is a basic feature we didn't have before, as far as I > know. I suppose the mnemonic is "location". > > >> It causes ctrl-d to do what ctrl-l used to do, namely do a >> screenshot-bookmark. This is the standard bookmark key. Pressing ctrl-d >> more times will show/hide the bookmark toolbar, so if you accidentally show >> it you can get rid of the large and obnoxious thing. Ctrl-b will also >> show/hide it, cause why not? >> > > Anyone care to explain the mnemonic for Ctrl-d? Again, keeping to the > standards can't really be a bad thing. I'm unsure about overloading > the shortcut with the bar toggle, though. I might instead offer that > alt-ctrl-d could make be added for making a bookmark "silently" > (without revealing the tray, if it's hidden). I think it's better to > keep the notion of creating a bookmark and toggling the bookmark tray > independent. In my browser, command-shift-B toggles the bookmark bar, > but I can't see a reason to require the extra shift modifier (is that > a standard elsewhere?). The shortcut for this is currently > ctrl-space, I think...if we make ctrl-b serve this purpose we should > remove the other shortcut. > > >> It causes ctrl-i to show the URI of the page instead of the title, >> temporarily. Good for checking that one isn't being fished. >> > > This is a pretty interesting idea, and a very nice addition to the > concept of the combined URL/address bar. If you're up to it, I would > appreciate it if you could try out another related idea which I've > been thinking about. I think it would also make sense to reveal the > URI whenever the cursor is within the entry, so that it's possible to > select all or part of it, or position the cursor in a meaningful way > when clicking into it. > > I think that we could certainly make use of most of this with the > changes/additions described above! Thanks for your efforts! > > - Eben > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar > > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Patch to make Browse annoy me less.
Just a high level take on these patches... On Thu, May 15, 2008 at 10:46 PM, Cortland Setlow <[EMAIL PROTECTED]> wrote: > Hi, > > This patch does three things, and I'll be happy if even one makes it in to > Browse. > > It causes ctrl-l (lowercase L) to put focus on the address bar like in all > other browsers that do not make me angry. Sounds good to me. Adherence to well known shortcuts is usually a win, and this is a basic feature we didn't have before, as far as I know. I suppose the mnemonic is "location". > It causes ctrl-d to do what ctrl-l used to do, namely do a > screenshot-bookmark. This is the standard bookmark key. Pressing ctrl-d > more times will show/hide the bookmark toolbar, so if you accidentally show > it you can get rid of the large and obnoxious thing. Ctrl-b will also > show/hide it, cause why not? Anyone care to explain the mnemonic for Ctrl-d? Again, keeping to the standards can't really be a bad thing. I'm unsure about overloading the shortcut with the bar toggle, though. I might instead offer that alt-ctrl-d could make be added for making a bookmark "silently" (without revealing the tray, if it's hidden). I think it's better to keep the notion of creating a bookmark and toggling the bookmark tray independent. In my browser, command-shift-B toggles the bookmark bar, but I can't see a reason to require the extra shift modifier (is that a standard elsewhere?). The shortcut for this is currently ctrl-space, I think...if we make ctrl-b serve this purpose we should remove the other shortcut. > It causes ctrl-i to show the URI of the page instead of the title, > temporarily. Good for checking that one isn't being fished. This is a pretty interesting idea, and a very nice addition to the concept of the combined URL/address bar. If you're up to it, I would appreciate it if you could try out another related idea which I've been thinking about. I think it would also make sense to reveal the URI whenever the cursor is within the entry, so that it's possible to select all or part of it, or position the cursor in a meaningful way when clicking into it. I think that we could certainly make use of most of this with the changes/additions described above! Thanks for your efforts! - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar in LinuxTag 2008
On Sun, May 18, 2008 at 6:22 PM, Holger Levsen <[EMAIL PROTECTED]> wrote: > > On Tuesday 13 May 2008 11:57, Tomeu Vizoso wrote: > > Do you have a sugar workshop / meeting planned at a specific date as well? Or > do you plan to just meet for the whole 4 days? ;) > > We'll also get 2m^2 space at the Debian Edu / Skolelinux.de booth. I think we just plan to hang around together and have a good face-to-face time interchanging experiences about this last year and the way forward. Perhaps we should set a couple of hours specifically for meeting with the broadest community? When would work better for the most time-constrained people? Perhaps would be most interesting after the talks, so new people can jump to say hi. Cheers, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] OLPC priorities for Sugar in the August release
On Wed, May 14, 2008 at 1:46 PM, Mikus Grinbergs <[EMAIL PROTECTED]> wrote: >> * More responsive UI - faster launch of activities >> >> Is the solution currently in joyride satisfactory for the August release? > > I use a recent Joyride on my G1G1. My average time to launch Browse > (from the time I click in the F3 Activity Ring on the Browse icon, > to the time when I can click on the entry field in Browse itself (so > that I can start typing in an URL) is 25 seconds. > > Is that satisfactory ? Certainly not. Could you do an experiment for me? Can you kill the journal activity and then try launching? If my suspicion is correct, the journal+DS is competing for the cpu, so without the journal it should start much faster. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] Implement installation dates in the activity list
From d9cf67dd382b492e93549344273658860e2410ae Mon Sep 17 00:00:00 2001
From: Tomeu Vizoso <[EMAIL PROTECTED]>
Date: Mon, 19 May 2008 18:04:24 +0200
Subject: [PATCH] Add ActivityBundle.installation_time and format the date in the activity list
---
service/activityregistryservice.py |3 ++-
src/view/home/activitieslist.py|4 +++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/service/activityregistryservice.py b/service/activityregistryservice.py
index 7746877..bf98ef9 100644
--- a/service/activityregistryservice.py
+++ b/service/activityregistryservice.py
@@ -132,7 +132,8 @@ class ActivityRegistry(dbus.service.Object):
'path': bundle.get_path(),
'command': bundle.get_command(),
'show_launcher': bundle.get_show_launcher(),
-'favorite': favorite}
+'favorite': favorite,
+'installation_time': bundle.get_installation_time()}
def _bundle_added_cb(self, bundle_registry, bundle):
self.ActivityAdded(self._bundle_to_dict(bundle))
diff --git a/src/view/home/activitieslist.py b/src/view/home/activitieslist.py
index ebdf1ec..48f16ee 100644
--- a/src/view/home/activitieslist.py
+++ b/src/view/home/activitieslist.py
@@ -20,6 +20,7 @@ import hippo
from sugar import profile
from sugar import activity
+from sugar import util
from sugar.graphics import style
from sugar.graphics.icon import CanvasIcon
@@ -134,7 +135,8 @@ class ActivityEntry(hippo.CanvasBox, hippo.CanvasItem):
expander = hippo.CanvasBox()
self.append(expander, hippo.PACK_EXPAND)
-date = hippo.CanvasText(text='3 weeks ago',
+timestamp = activity_info.installation_time
+date = hippo.CanvasText(text=util.timestamp_to_elapsed_string(timestamp),
xalign=hippo.ALIGNMENT_START,
font_desc=style.FONT_NORMAL.get_pango_desc(),
box_width=ActivityEntry._DATE_COL_WIDTH)
--
1.5.2.5
From 2c06e6be16492990601f51d25fbbedd4f0ab1a02 Mon Sep 17 00:00:00 2001
From: Tomeu Vizoso <[EMAIL PROTECTED]>
Date: Mon, 19 May 2008 18:03:04 +0200
Subject: [PATCH] Move timestamp_to_elapsed_string to sugar.util and add ActivityBundle.installation_time
---
src/sugar/activity/registry.py |8 +++--
src/sugar/bundle/activitybundle.py |5 +++
src/sugar/util.py | 69
3 files changed, 79 insertions(+), 3 deletions(-)
diff --git a/src/sugar/activity/registry.py b/src/sugar/activity/registry.py
index 5f5aefc..d5d0529 100644
--- a/src/sugar/activity/registry.py
+++ b/src/sugar/activity/registry.py
@@ -31,11 +31,12 @@ def _activity_info_from_dict(info_dict):
return ActivityInfo(info_dict['name'], info_dict['icon'],
info_dict['bundle_id'], info_dict['version'],
info_dict['path'], info_dict['show_launcher'],
-info_dict['command'], info_dict['favorite'])
+info_dict['command'], info_dict['favorite'],
+info_dict['installation_time'])
class ActivityInfo(object):
-def __init__(self, name, icon, bundle_id, version,
- path, show_launcher, command, favorite):
+def __init__(self, name, icon, bundle_id, version, path, show_launcher,
+ command, favorite, installation_time):
self.name = name
self.icon = icon
self.bundle_id = bundle_id
@@ -44,6 +45,7 @@ class ActivityInfo(object):
self.command = command
self.show_launcher = show_launcher
self.favorite = favorite
+self.installation_time = installation_time
class ActivityRegistry(gobject.GObject):
__gsignals__ = {
diff --git a/src/sugar/bundle/activitybundle.py b/src/sugar/bundle/activitybundle.py
index 5f1fb7b..db30555 100644
--- a/src/sugar/bundle/activitybundle.py
+++ b/src/sugar/bundle/activitybundle.py
@@ -163,6 +163,11 @@ class ActivityBundle(Bundle):
"""Get the activity user visible name."""
return self._name
+def get_installation_time(self):
+"""Get a timestamp representing the time at which this activity was
+installed."""
+return os.stat(self._path).st_mtime
+
def get_bundle_id(self):
"""Get the activity bundle id"""
return self._bundle_id
diff --git a/src/sugar/util.py b/src/sugar/util.py
index 12f6824..f885523 100644
--- a/src/sugar/util.py
+++ b/src/sugar/util.py
@@ -21,6 +21,8 @@ import sha
import random
import binascii
import string
+from gettext import gettext as _
+import gettext
def printable_hash(in_hash):
"""Convert binary hash data into printable characters."""
@@ -168,3 +170,70 @@ class LRU:
yield j
def keys(self):
return self.d.keys()
+
+units = [['%d year', '%d years', 356 * 24 * 60 * 60],
+ ['%d month', '%d months', 30 * 24 * 60 * 6
Re: [sugar] Activities Portal: Proposal/suggestion
Please wikify this! :) There is a note about something like this at the end of the doc page which would be good to link: http://wiki.sugarlabs.org/go/Documentation Marco On Mon, May 19, 2008 at 5:08 PM, Morgan Collett <[EMAIL PROTECTED]> wrote: > I've been thinking about a better portal for downloading activities. I > came up with some ideas, that I unfortunately don't have time to > implement, but I would be happy to cheer someone on if they are > inspired by this... > > It should be easy to upload an activity (specifically after the first > time it has been done) - easier than uploading to the wiki. > > Activities should be categorised according to various properties, including: > * The usual activity metadata from activity.info > * Descriptions, as in http://wiki.laptop.org/go/Activities > * Category, as in http://wiki.laptop.org/go/Activities > * Age ranges the activity is suitable for? (Possibly a Mature category > for Doom?) > * Competencies required: Pre-reading, reading, writing, ... > * Development maturity > - like sourceforge: planning / pre-alpha / alpha / beta / stable > * Collaborative? > - yes / no / only (for activities like Connect or Chat that don't > function as a single user activity) > * Requires Internet? (e.g. Gmail) > * Compatible with: Sugar / Glucose version or OLPC release or distro > release... e.g. Sugar >= 0.81 > * Additional Dependencies (e.g. video-chat-activity needs extra RPMs > not in a build) > * Tags > * Languages - pulled out of the .xo > * Low power friendly? > * Related activities (for suites or alternatives) > * Screenshot > > Activities have Releases, which have status similar to the development > maturity - Suitable for: development / QA / public release etc - and > of course the downloadable bundle for that release... > > The site should be internationalisable using standard i18n tools. > > Bonus points for: > * Publishing a text page like > http://mock.laptop.org/repos/local.update1/XOS/index.html at > predictable URLs that lists activities compatible with a given > release, for easy downloading with scripts etc. > * Publishing the source in public distributed revision control, to get > easy contributions to code / templates > * Deployment on a system that is monitored and actively sysadmined > * Implementation in a Python web framework, to tap into the existing > developer community :) > * A catchy name... > > Future features: > * Download statistics > * Feedback to the author(s) > > Regards > Morgan > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versions
Yes, I've never understood the reason for the integer versioning system for activities. One argument I'm aware of is that it could make things simpler for kids, who might not understand more complex schemes. However, as you point out, if the relation between two versions of a given activity doesn't actually have any meaning, then the point is moot, and we're doing a greater disservice by hiding the real information needed to understand the system in any meaningful way. Chances are that any kid who has the chops to hack into an activity with Develop can probably grasp a more complex versioning scheme. If we still wanted to impose some arbitrary restrictions to keep things sane, we could limit to "major" and "minor" releases, and even have a checkbox (or something) in Develop which indicates if the resulting build should be a major or minor release, thus automatically updating bundle 2.5 to 3.0 or 2.6 respectively. This could be a nice middle ground. (To be clear, anytime the "identity" of an activity changes (eg. it is signed by a new author) the version thread would start over, so the major/minor release management only needs to be maintained by the individual or group of individuals collaborating to create an activity.) - Eben On Mon, May 19, 2008 at 10:33 AM, Morgan Collett <[EMAIL PROTECTED]> wrote: > On Mon, May 19, 2008 at 2:12 PM, Jameson Chema Quinn > <[EMAIL PROTECTED]> wrote: >> >> * Cannot have two versions of an activity bundle installed at once (dev and >> stable) while debugging - esp. necessary for working on Develop itself. >> Also, you are forced to churn the activity.info version number (upwards or >> downwards, it doesn't matter) every debug cycle, because "same version" >> silently fails to install. > > This reminds me of my pet issue about activity version numbers: There > is no way to branch development. This is especially relevant with > activities decoupled from the builds. > > For instance: Chat-35.xo is included in the Update.1 activity repo > (http://mock.laptop.org/repos/local.update1/XOS/index.html). Chat-38 > will be the next development release, and will probably depend on new > features in Sugar introduced since Update.1. What if we need a bugfix > release for Update.1? What version will that be? If it is Chat-39, > then Chat-38 and Chat-40 (perhaps another development release) would > not be related to Chat-39 in any way. > > I think this is also an issue once Develop is available, since if I > were to edit an activity in Develop and produce a bundle with the next > version number as Jameson described, it would conflict with the next > "real" release done by that activity's author. > > Since we struggle to get consensus on issues like a release > name/number, can we get a discussion on the following bite sized > pieces of an issue? > > * Is the current activity version numbering inadequate, as I am proposing? > * Is changing it to (or allowing) a dotted numeric scheme (Chat-38.2) > a good way to go? > (For example, I might use odd numbers for development series and even > numbers for stable releases - Chat-37.2 next, Chat-38 for Sucrose 0.82 > / OLPC 8.02) and Chat-35.1 for a bugfix for Update.1) > * Would that be an intrusive change? > > Regards > Morgan > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Activities Portal: Proposal/suggestion
I've been thinking about a better portal for downloading activities. I came up with some ideas, that I unfortunately don't have time to implement, but I would be happy to cheer someone on if they are inspired by this... It should be easy to upload an activity (specifically after the first time it has been done) - easier than uploading to the wiki. Activities should be categorised according to various properties, including: * The usual activity metadata from activity.info * Descriptions, as in http://wiki.laptop.org/go/Activities * Category, as in http://wiki.laptop.org/go/Activities * Age ranges the activity is suitable for? (Possibly a Mature category for Doom?) * Competencies required: Pre-reading, reading, writing, ... * Development maturity - like sourceforge: planning / pre-alpha / alpha / beta / stable * Collaborative? - yes / no / only (for activities like Connect or Chat that don't function as a single user activity) * Requires Internet? (e.g. Gmail) * Compatible with: Sugar / Glucose version or OLPC release or distro release... e.g. Sugar >= 0.81 * Additional Dependencies (e.g. video-chat-activity needs extra RPMs not in a build) * Tags * Languages - pulled out of the .xo * Low power friendly? * Related activities (for suites or alternatives) * Screenshot Activities have Releases, which have status similar to the development maturity - Suitable for: development / QA / public release etc - and of course the downloadable bundle for that release... The site should be internationalisable using standard i18n tools. Bonus points for: * Publishing a text page like http://mock.laptop.org/repos/local.update1/XOS/index.html at predictable URLs that lists activities compatible with a given release, for easy downloading with scripts etc. * Publishing the source in public distributed revision control, to get easy contributions to code / templates * Deployment on a system that is monitored and actively sysadmined * Implementation in a Python web framework, to tap into the existing developer community :) * A catchy name... Future features: * Download statistics * Feedback to the author(s) Regards Morgan ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Pippy VS Develop
On Mon, May 19, 2008 at 9:35 AM, Chris Ball <[EMAIL PROTECTED]> wrote: > to solve. I don't view the two activities as competitive: > > * Pippy:Introductory Python tutor > * Develop: Activity creation IDE Agreed. I think they serve different audiences/purposes. The only reason this could become confused is because Pippy grew the ability to export activity bundles, albeit somewhat limited ones. Regarding view source, I don't think anyone has nailed down the proper implementation yet. However, I certainly feel that the "lowest level" of the view source key ultimately should be to open the appropriate activity bundle within Develop. I'm hoping for something like a modal alert which the activity can use some API to cater to its needs, and which provides a way for the user to view/edit relevant code in other activities (via some URI handling system which Rainbow could provide for opening content). Opening the bundle in develop would /always/ be an option, but it might be possible to open the HTML/CSS/JS for a webpage in a mini-dreamweaver, or even in Write for that matter. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Experiments with Metacity
On Mon, May 19, 2008 at 5:14 PM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > On Mon, May 19, 2008 at 11:41 AM, Marco Pesenti Gritti > <[EMAIL PROTECTED]> wrote: >> Maximize + undecorated might work. It has to be done by each activity. > > We could add an option to make metacity show *no* decoration for > maximized windows. As long as we have a Close menu on the frame that > should be desired also for desktop applications. > > Ideally we could figure out a way to make metacity maximize activity > windows by default, but I can't think of a clean way to do it. One > problem with doing the maximize in the activity is that it would still > do so when running on a normal desktop. > It looks like a set_resizable(False) seems to work around the issue. Currently I'm doing self.set_decorated(False) self.set_resizable(False) self.maximize() from the __init__() method of the Activity class of sugar-toolkit/src/sugar/activity/activity.py. Cheers, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Activity versions
On Mon, May 19, 2008 at 2:12 PM, Jameson Chema Quinn <[EMAIL PROTECTED]> wrote: > > * Cannot have two versions of an activity bundle installed at once (dev and > stable) while debugging - esp. necessary for working on Develop itself. > Also, you are forced to churn the activity.info version number (upwards or > downwards, it doesn't matter) every debug cycle, because "same version" > silently fails to install. This reminds me of my pet issue about activity version numbers: There is no way to branch development. This is especially relevant with activities decoupled from the builds. For instance: Chat-35.xo is included in the Update.1 activity repo (http://mock.laptop.org/repos/local.update1/XOS/index.html). Chat-38 will be the next development release, and will probably depend on new features in Sugar introduced since Update.1. What if we need a bugfix release for Update.1? What version will that be? If it is Chat-39, then Chat-38 and Chat-40 (perhaps another development release) would not be related to Chat-39 in any way. I think this is also an issue once Develop is available, since if I were to edit an activity in Develop and produce a bundle with the next version number as Jameson described, it would conflict with the next "real" release done by that activity's author. Since we struggle to get consensus on issues like a release name/number, can we get a discussion on the following bite sized pieces of an issue? * Is the current activity version numbering inadequate, as I am proposing? * Is changing it to (or allowing) a dotted numeric scheme (Chat-38.2) a good way to go? (For example, I might use odd numbers for development series and even numbers for stable releases - Chat-37.2 next, Chat-38 for Sucrose 0.82 / OLPC 8.02) and Chat-35.1 for a bugfix for Update.1) * Would that be an intrusive change? Regards Morgan ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] scroll activity list with the arrow keys
Hi, the issue I see is that you have to hit the up/down keys twice or three times (focus entry widget, non-focus, focus scrollbar). So it might be hard to discover what is actually happening. @eben: how do we handle focus. We grab focus on the entry in the mesh view. We do not in the home-view. What is the way you want to handle these things. Should we grab on the list or the search entry? Thanks, Simon Tomeu Vizoso wrote: > Hi, > > this new patch uses key-press-event. > > Thanks, > > Tomeu > > On Thu, May 15, 2008 at 5:08 PM, Eben Eliason <[EMAIL PROTECTED]> wrote: >> On Thu, May 15, 2008 at 7:04 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: >>> On Thu, May 15, 2008 at 12:56 PM, Marco Pesenti Gritti >>> <[EMAIL PROTECTED]> wrote: >>> > Any reason to not use key_press events or similar? I don't think we >>> > should "patch" gtk.ScrolledWindow behavior. >>> >>> Well, I guess that Eben will want this behavior in all the list views >>> (mesh, group, activity, more?). >> Confirmation on that. All list views should behave the same. >> >> - Eben >> >> >> >> >> ___ >> Sugar mailing list >> Sugar@lists.laptop.org >> http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Pippy VS Develop
Hi, > * Pippy is well maintained and tested but it's supposed to be just > a stop gap solution. For the future we will be focusing on Develop. Pippy's activity creation ability and handling of the view source key is a stop-gap solution, but I don't think its goal of providing an introduction to programming in Python is one that Develop is aiming to solve. I don't view the two activities as competitive: * Pippy:Introductory Python tutor * Develop: Activity creation IDE - Chris. -- Chris Ball <[EMAIL PROTECTED]> ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] hot corners
Hi Guys, Sounds like Walter is on it. My 2 cents, ask this question and figure how to more questions like this in the future. Also, if representatives from deployments are in Cambridge this week, make sure to raise the question there. After our last exchange a month ago, I thought about ways to gather user input on future GUI design. The developer key and need to load a special build was the first show stopper. The second was that you can't stop class to test new code. E.g. Tim from Waveplace said he can't interfere with deployments and learning to "beta" test. I sent a link to the new sugar GUI to a lead in Peru but I don't think he really "grokked" the new design. May be because its static or because its in English. Bottom line is that I don't think those pages alone will get you the quality input needed. I'll try again with a link to new design and questions on current frame on the [EMAIL PROTECTED] list. Long term you need a standing lab. I believe I saw David Cavallo meeting with Mel King some time ago. Mel started a technology center for kids n Boston: http://www.tech-center-enlightentcity.tv/ With 10 - 20 Xos and their buy in, that could be your usability lab. I think David Cavallo will have contacts to get that started. Sorry, I wont have time to do a lot of work on that in the near future :-( I can send a couple of e-mails a week but otherwise have to pass he buck. Thanks, Greg S BTW I'm not on the sugar list (e-mail is maxed out). Please forward there as needed. I'll also comment one more time on Frame thread on devel list. -Original Message- From: Walter Bender [mailto:[EMAIL PROTECTED] Sent: Saturday, May 17, 2008 11:34 PM To: Marco Pesenti Gritti Cc: Simon Schampijer; Greg Smith (gregmsmi); Eben Eliason; Sugar List Subject: Re: [sugar] hot corners Let me talk to Carla, Miguel, and Hernan this week. They should be able to help us out with some kid testing. -walter On Sat, May 17, 2008 at 7:55 AM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > On Fri, May 16, 2008 at 4:22 AM, Simon Schampijer <[EMAIL PROTECTED]> wrote: >> Eben I only added a slider for the delay of the activation of the hot corners. >> By default the delay is zero. >> >> And since I wanted to test out how the warm edge works in general I >> added a top warm edge since I tapped myself moving the mouse there >> when I wanted to switch activities. >> >> I can make another rpm with warm edges all around and a separate >> delay option so we can test it out how it feels. >> >> Did you actually tested the rpm I provided? > > I think we can't figure out which options to provide exactly before > understanding the problem better and having done some usability > testing. > > We have a general problem to solve here... How do we do simple > usability testing with kids? Do we have contacts in the deployments > that we can use do so? Are they comfortable to install a joyride build > (and maybe an rpm)? > > Marco > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Merge activities.default into favorites.
On Mon, May 19, 2008 at 2:54 PM, Simon Schampijer <[EMAIL PROTECTED]> wrote:
> Hi,
>
> following small note to the patch:
>
> what about using an else clause in the _load_favorites() method? So we know
> which ValueError the except block is trying to catch.
>
> try:
>favorites_data = simplejson.load(open(favorites_path))
> except ValueError, e:
>logging.error('Error while loading favorite_activities: %r.' %
> e)
> else:
># Old structure was a list instead of a dictionary.
>if isinstance(favorites_data, list):
>favorite_bundles = favorites_data
>else:
>favorite_bundles = favorites_data['favorites']
>self._last_defaults_mtime = favorites_data['defaults-mtime']
>
>
> But r+ in general.
I like that, thanks!
Tomeu
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Code review (was: Pippy VS Develop)
On Mon, May 19, 2008 at 2:48 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > No, I told Jameson that I'd review his patches because they affect > code that has been maintained primarily by me. What happened is that I > never found time to review those as higher priority items appeared in > my TODO list, but Jameson has been patiently reminding me to do that. > So more than a flaw in the process there has been shortage of > resources or bad judgement of priorities by me. Dealing with review priorities it's sort of complicated. I tend to think they should be at the top of list (for the whole team) regardless of the priority of the specific fix or feature. Otherwise we block the community or we constrain it to work in the areas that *we* consider important. Obviously for this to be realistic the community needs to cooperate and pay attention to trac milestones and roadmap. > About slow reviews, I'd appreciate if someone reviewed the patches _I_ > have in the review queue :P I've been lazy about reviews in the last weeks. I can do better but Mon-Wed is off for me. We need to add at least another peer to reduce the load on each of us. Maybe mtd can help out? Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Pippy VS Develop
On 19.05.2008, at 12:51, Marco Pesenti Gritti wrote: > I'm trying to form my opinion about inclusion of Pippy and Develop in > Sucrose 0.82. > > Here is my understanding: > > * Pippy is well maintained and tested but it's supposed to be just a > stop gap solution. For the future we will be focusing on Develop. > * Develop is not very mature and tested yet. Jameson is the only > developer and he is not sure if he is going to be able to keep doing > it. > > I'm sure I didn't get this quite right, so please step in and > correct me :) What about the view-source feature? Do both activities support that? - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Merge activities.default into favorites.
Hi,
following small note to the patch:
what about using an else clause in the _load_favorites() method? So we know
which
ValueError the except block is trying to catch.
try:
favorites_data = simplejson.load(open(favorites_path))
except ValueError, e:
logging.error('Error while loading favorite_activities: %r.' %
e)
else:
# Old structure was a list instead of a dictionary.
if isinstance(favorites_data, list):
favorite_bundles = favorites_data
else:
favorite_bundles = favorites_data['favorites']
self._last_defaults_mtime = favorites_data['defaults-mtime']
But r+ in general.
Best,
Simon
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Code review (was: Pippy VS Develop)
On Mon, May 19, 2008 at 2:40 PM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > > I also would like to understand if this is happening generally or just > for the patches you are mentioning. I had not heard people complaining > about slow reviews so far. No, I told Jameson that I'd review his patches because they affect code that has been maintained primarily by me. What happened is that I never found time to review those as higher priority items appeared in my TODO list, but Jameson has been patiently reminding me to do that. So more than a flaw in the process there has been shortage of resources or bad judgement of priorities by me. About slow reviews, I'd appreciate if someone reviewed the patches _I_ have in the review queue :P Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Pippy VS Develop
On Mon, May 19, 2008 at 2:12 PM, Jameson Chema Quinn <[EMAIL PROTECTED]> wrote: > * Datastore is unreliable. This led to a major dataloss bug in the past > which "magically fixed itself", and to a separate minor one in the present > (sometimes, save fails non-silently; activity complains, gives choice of > halting exit, and later saves properly) which has not been resolved. Without > a reimplemented datastore, a la tomeu's quickie, this does not lend > confidence. Until we have a real plan for the next datastore we should keeping reporting and fixing bugs in the current implementation. I haven't seen any datastore proposal for Sucrose 0.82, so we will ship with the current one. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] activity.py: dirty flag and fix create_jobject == False case.
Hi,
+class WarningDictionary(dict):
+def __getitem__(self,key):
+warnings.warn("Trying to get key %s in unallocated activity
metadata dictionary %s"%(key,self),
+RuntimeWarning, stacklevel=2)
+return None
+def __setetitem__(self,key,value):
+warnings.warn("Trying to set key %s in unallocated activity
metadata dictionary %s"%(key,self),
+RuntimeWarning, stacklevel=2)
+return dict.__setitem__(self,key,value)
Why do you think this is needed?
+self.dirty = bool(handle or create_jobject) #do not save if not dirty.
Why bool() and why not just initialize it to True? What do you think
about using is_dirty instead so it's clearer that it's a flag?
+#Individual activities responsible for setting and clearing
+#this flag, but activity.py respects it.
Perhaps this should be a pydocs comment?
+logging.debug('Activity.save: %r' % self._jobject.object_id
if self._jobject else 'NOTHING')
...
+if self._jobject:
Wouldn't be better to make sure that this method doesn't get executed
if there's no jobject?
+logging.info('Activity.save: no need, nothing has
happened since last save.')
Should be logging.debug instead?
One concern I have about the general approach is that the activity
author needs to set dirty to False after a successful save, but that
info (when a save has finished successfully) is not available to the
activity.
Thanks,
Tomeu
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Code review (was: Pippy VS Develop)
On Mon, May 19, 2008 at 2:12 PM, Jameson Chema Quinn <[EMAIL PROTECTED]> wrote: > These are really the only high-priority outstanding issues with develop as > it stands (aside from translation and broader testing). And the process of > code review does not appear to be working for me, I have a patch for the > first of these issues which has languished for months. Sorry about that. Using the mailing list for code review is great because everyone can be involved in the process. But we also need to figure out a way to keep trac of patches that needs review. I think we should figure out a way to use trac in combination with mailing lists to achieve that effect. I started a wiki page for this reason a few days ago but I have not had time to come up with a proposal yet: http://wiki.sugarlabs.org/go/CodeReview Anyone feels like thinking this through and come up with a proposal for discussion? > From where I'm > sitting, it would be nice if checkin capability on joyride were more > liberally granted (with some specific community norms about self-review), > and the strict third-party review requirement were a filter when > cherrypicking changes FROM joyride, not into it. I think commit rules are and should keep to be dictated at the upstream project level. The solution to slow reviews is not to abolish them or to delay them in the distribution process. I think we can resolve the issue by making to-review patches easier to track and by getting more peers for the glucose modules. I also would like to understand if this is happening generally or just for the patches you are mentioning. I had not heard people complaining about slow reviews so far. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Pippy VS Develop
On Mon, May 19, 2008 at 4:51 AM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > I'm trying to form my opinion about inclusion of Pippy and Develop in > Sucrose 0.82. > > Here is my understanding: > > * Pippy is well maintained and tested but it's supposed to be just a > stop gap solution. For the future we will be focusing on Develop. > * Develop is not very mature and tested yet. Jameson is the only > developer and he is not sure if he is going to be able to keep doing > it. > > I'm sure I didn't get this quite right, so please step in and correct me :) > > Marco > You are pretty much right. I would add one point: that currently, the main flaws in develop are all, really, flaws in glucose (and/or fructose, see below): * Cannot open an activity bundle from standard journal, only run it. (patch exists) * Cannot have two versions of an activity bundle installed at once (dev and stable) while debugging - esp. necessary for working on Develop itself. Also, you are forced to churn the activity.info version number (upwards or downwards, it doesn't matter) every debug cycle, because "same version" silently fails to install. * Activity bundle format is not well-enforced (no warnings), so many activities have noncompliant bundles; this can lead to data loss in Develop. (this is what I meant by including fructose above) * Datastore is unreliable. This led to a major dataloss bug in the past which "magically fixed itself", and to a separate minor one in the present (sometimes, save fails non-silently; activity complains, gives choice of halting exit, and later saves properly) which has not been resolved. Without a reimplemented datastore, a la tomeu's quickie, this does not lend confidence. These are really the only high-priority outstanding issues with develop as it stands (aside from translation and broader testing). And the process of code review does not appear to be working for me, I have a patch for the first of these issues which has languished for months. From where I'm sitting, it would be nice if checkin capability on joyride were more liberally granted (with some specific community norms about self-review), and the strict third-party review requirement were a filter when cherrypicking changes FROM joyride, not into it. As to whether I will be able to continue: hopefully, this will be resolved within a couple of weeks. Jameson ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Experiments with Metacity
On Mon, May 19, 2008 at 11:41 AM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > Maximize + undecorated might work. It has to be done by each activity. We could add an option to make metacity show *no* decoration for maximized windows. As long as we have a Close menu on the frame that should be desired also for desktop applications. Ideally we could figure out a way to make metacity maximize activity windows by default, but I can't think of a clean way to do it. One problem with doing the maximize in the activity is that it would still do so when running on a normal desktop. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Pippy VS Develop
I'm trying to form my opinion about inclusion of Pippy and Develop in Sucrose 0.82. Here is my understanding: * Pippy is well maintained and tested but it's supposed to be just a stop gap solution. For the future we will be focusing on Develop. * Develop is not very mature and tested yet. Jameson is the only developer and he is not sure if he is going to be able to keep doing it. I'm sure I didn't get this quite right, so please step in and correct me :) Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] etoys activity proposal
I think etoys should be totally in. It's best education activity we have, it's well maintained and there is value in having a non python activity in Sucrose. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Experiments with Metacity
On Mon, May 19, 2008 at 12:24 PM, Sayamindu Dasgupta <[EMAIL PROTECTED]> wrote: > I'm not familiar with metacity code, but I think my maximizing and > decoration disabling request is making the size of the activity window > as equal to the size of the screen, which Metacity is interpreting as > a fullscreen request. > I'll do a custom build of Metacity with this disabled and see how it works > out. Yup that's correct. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Experiments with Metacity
On Mon, May 19, 2008 at 3:42 PM, Sayamindu Dasgupta <[EMAIL PROTECTED]> wrote:
> On Mon, May 19, 2008 at 3:35 PM, Marco Pesenti Gritti
> <[EMAIL PROTECTED]> wrote:
>> On Mon, May 19, 2008 at 12:00 PM, Sayamindu Dasgupta
>> <[EMAIL PROTECTED]> wrote:
>>> I tried to do that (maximize() and then set_decorated(False)). As soon
>>> as I set the window to undecorated, it seems to assume fullscreen
>>> properties (with the full screen icon popping up on the top right). Is
>>> there any convention which signifies maximized + undecorated =
>>> fullscreen ?
>>
>> That's really weird... I wonder if metacity is doing some hacks there...
>>
>> Marco
>>
>
> I get the following message in the background:
>
> Window manager warning: Treating resize request of legacy application
> 0x83 (Journal) as a fullscreen request
>
In metacity/src/core/constraints.c,
/* Workaround braindead legacy apps that don't know how to
* fullscreen themselves properly.
*/
if (meta_rectangle_equal (new, &xinerama_info->rect) &&
window->has_fullscreen_func &&
!window->fullscreen)
{
/*
meta_topic (META_DEBUG_GEOMETRY,
*/
meta_warning (
"Treating resize request of legacy application %s as a "
"fullscreen request\n",
window->desc);
meta_window_make_fullscreen_internal (window);
}
I'm not familiar with metacity code, but I think my maximizing and
decoration disabling request is making the size of the activity window
as equal to the size of the screen, which Metacity is interpreting as
a fullscreen request.
I'll do a custom build of Metacity with this disabled and see how it works out.
Cheers,
Sayamindu
--
Sayamindu Dasgupta
[http://sayamindu.randomink.org/ramblings]
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Experiments with Metacity
/* Workaround braindead legacy apps that don't know how to
* fullscreen themselves properly.
*/
if (meta_rectangle_equal (new, &xinerama_info->rect) &&
window->has_fullscreen_func &&
!window->fullscreen)
{
/*
meta_topic (META_DEBUG_GEOMETRY,
*/
meta_warning (
"Treating resize request of legacy application %s as a "
"fullscreen request\n",
window->desc);
meta_window_make_fullscreen_internal (window);
}
I'm not sure what's the proper way to address this. While prototyping
this you could just apply a patch to get rid of it, then we figure out
the best way to upstream it..
Marco
On Mon, May 19, 2008 at 12:12 PM, Sayamindu Dasgupta
<[EMAIL PROTECTED]> wrote:
> On Mon, May 19, 2008 at 3:35 PM, Marco Pesenti Gritti
> <[EMAIL PROTECTED]> wrote:
>> On Mon, May 19, 2008 at 12:00 PM, Sayamindu Dasgupta
>> <[EMAIL PROTECTED]> wrote:
>>> I tried to do that (maximize() and then set_decorated(False)). As soon
>>> as I set the window to undecorated, it seems to assume fullscreen
>>> properties (with the full screen icon popping up on the top right). Is
>>> there any convention which signifies maximized + undecorated =
>>> fullscreen ?
>>
>> That's really weird... I wonder if metacity is doing some hacks there...
>>
>> Marco
>>
>
> I get the following message in the background:
>
> Window manager warning: Treating resize request of legacy application
> 0x83 (Journal) as a fullscreen request
>
> Any ideas ?
> Cheers,
> Sayamindu
>
>
>
> --
> Sayamindu Dasgupta
> [http://sayamindu.randomink.org/ramblings]
>
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Experiments with Metacity
On Mon, May 19, 2008 at 3:35 PM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > On Mon, May 19, 2008 at 12:00 PM, Sayamindu Dasgupta > <[EMAIL PROTECTED]> wrote: >> I tried to do that (maximize() and then set_decorated(False)). As soon >> as I set the window to undecorated, it seems to assume fullscreen >> properties (with the full screen icon popping up on the top right). Is >> there any convention which signifies maximized + undecorated = >> fullscreen ? > > That's really weird... I wonder if metacity is doing some hacks there... > > Marco > I get the following message in the background: Window manager warning: Treating resize request of legacy application 0x83 (Journal) as a fullscreen request Any ideas ? Cheers, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Experiments with Metacity
On Mon, May 19, 2008 at 12:00 PM, Sayamindu Dasgupta <[EMAIL PROTECTED]> wrote: > I tried to do that (maximize() and then set_decorated(False)). As soon > as I set the window to undecorated, it seems to assume fullscreen > properties (with the full screen icon popping up on the top right). Is > there any convention which signifies maximized + undecorated = > fullscreen ? That's really weird... I wonder if metacity is doing some hacks there... Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] (Incomplete) Activity Launch Feedback
On Mon, May 19, 2008 at 11:57 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > On Mon, May 19, 2008 at 11:55 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: >> >> On joyride, the shell just takes a few percents of cpu during launch, >> so perhaps it's good enough for now. > > Correction, takes 7%, enough to give it a look. Perhaps this is due to the bigger icon? afaik drawing the blank background should not take any cpu... Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Experiments with Metacity
On Mon, May 19, 2008 at 3:11 PM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > On Mon, May 19, 2008 at 11:15 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: >> On Mon, May 19, 2008 at 11:09 AM, Sayamindu Dasgupta >> <[EMAIL PROTECTED]> wrote: >>> Hi all, >>> >>> I was playing around with the possibility of replacing the current >>> Sugar WM - Matchbox with Metacity (this will, as I understand, enable >>> stock desktop applications run better within Sugar). >>> Certain things do break if we just drop in Metacity in place of >>> Matchbox, but it looks like with some changes in the code (Sugar code, >>> I would try to avoid changing Metacity code), we might actually get >>> something useful. >>> Marco had started a page on this topic sometime back - >>> http://wiki.sugarlabs.org/go/WindowManagement, and I have updated this >>> page with my findings. >> >> Yay! >> >>> Setting the window to be fullscreen (via set_fullscreen())does not seem to >>> work, since it stops the frame from popping up, and also an icon to exit >>> fullscreen appears at the top right corner. One possible solution to this >>> is to make the activity window undecorated (we do not need >>> maximise/minimize/resize buttons), and making their height/width equal to >>> the dimensions of the screen. >> >> This would need to be done by each activity or the window manager, or >> can be done by the shell? > > Maximize + undecorated might work. It has to be done by each activity. > The only alternative I can think about is to add an option to metacity > to make all toplevel windows undecorated and fullscreen. That would > not play nicely with stuff like the GIMP or even simple/small > applications like GNOME calculator. > I tried to do that (maximize() and then set_decorated(False)). As soon as I set the window to undecorated, it seems to assume fullscreen properties (with the full screen icon popping up on the top right). Is there any convention which signifies maximized + undecorated = fullscreen ? Cheers, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] (Incomplete) Activity Launch Feedback
On Mon, May 19, 2008 at 11:55 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > > On joyride, the shell just takes a few percents of cpu during launch, > so perhaps it's good enough for now. Correction, takes 7%, enough to give it a look. Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] (Incomplete) Activity Launch Feedback
On Mon, May 19, 2008 at 11:43 AM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > On Mon, May 19, 2008 at 11:33 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: >> On Sun, May 18, 2008 at 6:10 PM, Eben Eliason <[EMAIL PROTECTED]> wrote: >>> Sorry for the spam. This includes the necessary change to the >>> makefile, and also fixes a few small bugs in the former versions. >> >> I'm still testing the rpm, but at a first glance, the pulsing is >> taking too much CPU. Looks like the whole full screen window is being >> redrawn and X takes 20% cpu. > > What are we redrawing exactly? I thought the launching screen was mostly > blank? Only a pulsing icon in the middle of the screen is drawn, but if time is in X, I guess it is just pushing white pixels around with some conversion in the middle. But this only happens in the faster builds that have composition enabled. Wonder what can be going on in there... On joyride, the shell just takes a few percents of cpu during launch, so perhaps it's good enough for now. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] (Incomplete) Activity Launch Feedback
On Mon, May 19, 2008 at 11:33 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > I remember something about a bug in hippo causing the whole canvas to > be redrawn every time. Any news on this? That should be fixed in svn, it required API changes though, so we will have to adapt stuff. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] (Incomplete) Activity Launch Feedback
On Mon, May 19, 2008 at 11:33 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > On Sun, May 18, 2008 at 6:10 PM, Eben Eliason <[EMAIL PROTECTED]> wrote: >> Sorry for the spam. This includes the necessary change to the >> makefile, and also fixes a few small bugs in the former versions. > > I'm still testing the rpm, but at a first glance, the pulsing is > taking too much CPU. Looks like the whole full screen window is being > redrawn and X takes 20% cpu. What are we redrawing exactly? I thought the launching screen was mostly blank? Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Experiments with Metacity
On Mon, May 19, 2008 at 11:15 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > On Mon, May 19, 2008 at 11:09 AM, Sayamindu Dasgupta > <[EMAIL PROTECTED]> wrote: >> Hi all, >> >> I was playing around with the possibility of replacing the current >> Sugar WM - Matchbox with Metacity (this will, as I understand, enable >> stock desktop applications run better within Sugar). >> Certain things do break if we just drop in Metacity in place of >> Matchbox, but it looks like with some changes in the code (Sugar code, >> I would try to avoid changing Metacity code), we might actually get >> something useful. >> Marco had started a page on this topic sometime back - >> http://wiki.sugarlabs.org/go/WindowManagement, and I have updated this >> page with my findings. > > Yay! > >> Setting the window to be fullscreen (via set_fullscreen())does not seem to >> work, since it stops the frame from popping up, and also an icon to exit >> fullscreen appears at the top right corner. One possible solution to this is >> to make the activity window undecorated (we do not need >> maximise/minimize/resize buttons), and making their height/width equal to >> the dimensions of the screen. > > This would need to be done by each activity or the window manager, or > can be done by the shell? Maximize + undecorated might work. It has to be done by each activity. The only alternative I can think about is to add an option to metacity to make all toplevel windows undecorated and fullscreen. That would not play nicely with stuff like the GIMP or even simple/small applications like GNOME calculator. > What about a composition manager? Has metacity some capabilities in this > regard? Yep, latest metacity has a CM I think. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] (Incomplete) Activity Launch Feedback
On Sun, May 18, 2008 at 6:10 PM, Eben Eliason <[EMAIL PROTECTED]> wrote: > Sorry for the spam. This includes the necessary change to the > makefile, and also fixes a few small bugs in the former versions. I'm still testing the rpm, but at a first glance, the pulsing is taking too much CPU. Looks like the whole full screen window is being redrawn and X takes 20% cpu. I remember something about a bug in hippo causing the whole canvas to be redrawn every time. Any news on this? As a quick workaround, the canvas could be just big enough to contain the icon, this should improve things considerably. I like it in general, though. Good work! Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] (Incomplete) Activity Launch Feedback
On Sun, May 18, 2008 at 5:50 PM, Gary C Martin <[EMAIL PROTECTED]> wrote: > Hi Eben/Tomeu, > > On 18 May 2008, at 15:37, Eben Eliason wrote: > >> Attached,with launchbox.py included. >> >> - Eben > > > I'm trying to apply you patch directly to an Xo with joyride 1946 (I don't > have access to any other build environment so my tests are limited to > patching an Xo B4). The patch seems to be mainly happy, except a few of > failed hunks in model/homemodel.py and view/frame/activitiestray.py. > > Now I'm pretty sure you don't work on like this on an Xo, but any > suggestions? I didn't notice any relevant changes between joyride 1946 and > the most recent 1950, or have I misunderstood the source stream you guys > work from? No, but there seems to have been some change not yet release on master that creates that conflict. > Is the git source and a custom Fedora build server the only way to be > involved? I'm hoping it's just that joyride has got a little behind the git > source due to the current missing builds due to disk space. For small changes, just updating the affected files may work, but this patch is now a bit big for that. Also, not having been a release since a while ago doesn't help things. I've done some new rpms, but the joyride builds are not being built, looks like :/ You can get them from koji.fedoraproject.org and install them manually, though. After I finish testing the rpm with Eben's launcher stuff I'll post here the url. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Experiments with Metacity
On Mon, May 19, 2008 at 11:09 AM, Sayamindu Dasgupta <[EMAIL PROTECTED]> wrote: > Hi all, > > I was playing around with the possibility of replacing the current > Sugar WM - Matchbox with Metacity (this will, as I understand, enable > stock desktop applications run better within Sugar). > Certain things do break if we just drop in Metacity in place of > Matchbox, but it looks like with some changes in the code (Sugar code, > I would try to avoid changing Metacity code), we might actually get > something useful. > Marco had started a page on this topic sometime back - > http://wiki.sugarlabs.org/go/WindowManagement, and I have updated this > page with my findings. Yay! > Setting the window to be fullscreen (via set_fullscreen())does not seem to > work, since it stops the frame from popping up, and also an icon to exit > fullscreen appears at the top right corner. One possible solution to this is > to make the activity window undecorated (we do not need > maximise/minimize/resize buttons), and making their height/width equal to the > dimensions of the screen. This would need to be done by each activity or the window manager, or can be done by the shell? What about a composition manager? Has metacity some capabilities in this regard? In the faster builds we have a matchbox with some simple composition management, but it has some issues. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Experiments with Metacity
Hi all, I was playing around with the possibility of replacing the current Sugar WM - Matchbox with Metacity (this will, as I understand, enable stock desktop applications run better within Sugar). Certain things do break if we just drop in Metacity in place of Matchbox, but it looks like with some changes in the code (Sugar code, I would try to avoid changing Metacity code), we might actually get something useful. Marco had started a page on this topic sometime back - http://wiki.sugarlabs.org/go/WindowManagement, and I have updated this page with my findings. Cheers, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
