Re: [Sugar-devel] [DESIGN] icons for import/export document proposal
Hi Manuel, On 16 Jun 2011, at 05:29, manuel quiñones wrote: El día 16 de junio de 2011 01:23, Gonzalo Odiard gonz...@laptop.org escribió: NIce! Thanks! :) Two options more: http://dev.laptop.org/~manuq/import-export/document_import-export_2.png I think they are more clear, but the objects (arrow and doc) may be too small on screen. Sorry for this rushed email, I'm late to this thread! - I agree the 2nd two designs don't provide enough space for the object being imported/exported (the blank document is the simplest visual case). - The 1st design is better in size but is too similar to the existing 14 transfer-from- and transfer-to- icons already used in sugar-artwork for the object transfer over the network feature (Journal Send to - friend). - I think introducing a 3d metaphor with the use of perspective is not ideal – I'm sure there was a past thread about avoiding 3D metaphors in the flat silhouette design style, but I can't find it, no mention of perspective in the HIG either. There are only a few cases of 3D styling in Sugar designs at the moment (the open Journal cover in the Keep icon, the my computer XO icon, the long/lat lines on the Browse related icons) and none try to show perspective. Taking a step back, here's a quick list of the goals I have written down: 1) ability to show different object types (pdf, png, generic image, python, etc) 2) visually distinguish importing vs. exporting from/to the Journal 3) distinguish between the existing Send to -- friend and importing/exporting from your Journal 4) visually distinguish saving/loading from the file system tree Personally I have a strong dislike for case 4. It seems a short term compromise/hack to raise a traditional gnome file chooser. Ideally if this is seen an essential Sugar feature, the Object Chooser should allow switching to view of the filesystem which – to be honest – seems like an almost solved problem already as the Object Chooser will display any extra mounted volumes in its toolbar (like a USB stick). Walter has a proposed patch already that shows your ~/Documents folder in just such a way in the Journal, so the same could be done for the Object Chooser (not sure the if ~/Documents patch works at the volume mount level so might need some extra work). The need for case 4 could then be dropped and all activity authors would automatically benefit from the new ability. If case 4 goes away, we could go back to the original design used for the Keep icon. Where we have a large user fill/stroke coloured image of the object in question (pdf, png, generic image, python, etc) and a small white arrow in the top right corner. Pointing to the document visual to indicate creation of it (export to ...), and pointing away from it to indicate loading of it (import from ...). Regards, --Gary Gonzalo 2011/6/16 manuel quiñones ma...@laptop.org Hi, I'm sending my first try at this icons, based on a discussion in the design meeting past sunday (sorry Gary you missed the last part). It becomes apparent that we need icons for export and import of documents. For example, Write reuses the document-save icon for export. http://dev.laptop.org/~manuq/import-export/document-import.svg http://dev.laptop.org/~manuq/import-export/document-export.svg http://dev.laptop.org/~manuq/import-export/document_import-export.png This is how they can be used in Write: http://dev.laptop.org/~manuq/import-export/import-export_mockup.png Regards, ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] icons for import/export document proposal
2011/6/17 Gary Martin garycmar...@googlemail.com: Hi Manuel, On 16 Jun 2011, at 05:29, manuel quiñones wrote: El día 16 de junio de 2011 01:23, Gonzalo Odiard gonz...@laptop.org escribió: NIce! Thanks! :) Two options more: http://dev.laptop.org/~manuq/import-export/document_import-export_2.png I think they are more clear, but the objects (arrow and doc) may be too small on screen. Sorry for this rushed email, I'm late to this thread! - I agree the 2nd two designs don't provide enough space for the object being imported/exported (the blank document is the simplest visual case). - The 1st design is better in size but is too similar to the existing 14 transfer-from- and transfer-to- icons already used in sugar-artwork for the object transfer over the network feature (Journal Send to - friend). - I think introducing a 3d metaphor with the use of perspective is not ideal – I'm sure there was a past thread about avoiding 3D metaphors in the flat silhouette design style, but I can't find it, no mention of perspective in the HIG either. There are only a few cases of 3D styling in Sugar designs at the moment (the open Journal cover in the Keep icon, the my computer XO icon, the long/lat lines on the Browse related icons) and none try to show perspective. Taking a step back, here's a quick list of the goals I have written down: 1) ability to show different object types (pdf, png, generic image, python, etc) 2) visually distinguish importing vs. exporting from/to the Journal 3) distinguish between the existing Send to -- friend and importing/exporting from your Journal 4) visually distinguish saving/loading from the file system tree Personally I have a strong dislike for case 4. It seems a short term compromise/hack to raise a traditional gnome file chooser. Ideally if this is seen an essential Sugar feature, the Object Chooser should allow switching to view of the filesystem which – to be honest – seems like an almost solved problem already as the Object Chooser will display any extra mounted volumes in its toolbar (like a USB stick). Walter has a proposed patch already that shows your ~/Documents folder in just such a way in the Journal, so the same could be done for the Object Chooser (not sure the if ~/Documents patch works at the volume mount level so might need some extra work). The need for case 4 could then be dropped and all activity authors would automatically benefit from the new ability. If case 4 goes away, we could go back to the original design used for the Keep icon. Where we have a large user fill/stroke coloured image of the object in question (pdf, png, generic image, python, etc) and a small white arrow in the top right corner. Pointing to the document visual to indicate creation of it (export to ...), and pointing away from it to indicate loading of it (import from ...). +1. But we need to take care about what parts of the file system will be made available this way: maybe something set through gconf? Indexing everything would incur a lot of overhead and result in a very long flat (but searchable) list -- not very useful). I could see indexing $HOME/Documents, $HOME/Activities (if you set some developer switch or some other trigger), and perhaps some $HOME/Media directory that encompasses the usual Pictures, Video, Music...). -walter Regards, --Gary Gonzalo 2011/6/16 manuel quiñones ma...@laptop.org Hi, I'm sending my first try at this icons, based on a discussion in the design meeting past sunday (sorry Gary you missed the last part). It becomes apparent that we need icons for export and import of documents. For example, Write reuses the document-save icon for export. http://dev.laptop.org/~manuq/import-export/document-import.svg http://dev.laptop.org/~manuq/import-export/document-export.svg http://dev.laptop.org/~manuq/import-export/document_import-export.png This is how they can be used in Write: http://dev.laptop.org/~manuq/import-export/import-export_mockup.png Regards, ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] icons for import/export document proposal
On Fri, Jun 17, 2011 at 9:06 AM, Walter Bender walter.ben...@gmail.com wrote: 2011/6/17 Gary Martin garycmar...@googlemail.com: Hi Manuel, On 16 Jun 2011, at 05:29, manuel quiñones wrote: El día 16 de junio de 2011 01:23, Gonzalo Odiard gonz...@laptop.org escribió: NIce! Thanks! :) Two options more: http://dev.laptop.org/~manuq/import-export/document_import-export_2.png I think they are more clear, but the objects (arrow and doc) may be too small on screen. Sorry for this rushed email, I'm late to this thread! - I agree the 2nd two designs don't provide enough space for the object being imported/exported (the blank document is the simplest visual case). - The 1st design is better in size but is too similar to the existing 14 transfer-from- and transfer-to- icons already used in sugar-artwork for the object transfer over the network feature (Journal Send to - friend). - I think introducing a 3d metaphor with the use of perspective is not ideal – I'm sure there was a past thread about avoiding 3D metaphors in the flat silhouette design style, but I can't find it, no mention of perspective in the HIG either. There are only a few cases of 3D styling in Sugar designs at the moment (the open Journal cover in the Keep icon, the my computer XO icon, the long/lat lines on the Browse related icons) and none try to show perspective. Taking a step back, here's a quick list of the goals I have written down: 1) ability to show different object types (pdf, png, generic image, python, etc) 2) visually distinguish importing vs. exporting from/to the Journal 3) distinguish between the existing Send to -- friend and importing/exporting from your Journal 4) visually distinguish saving/loading from the file system tree Personally I have a strong dislike for case 4. It seems a short term compromise/hack to raise a traditional gnome file chooser. Ideally if this is seen an essential Sugar feature, the Object Chooser should allow switching to view of the filesystem which – to be honest – seems like an almost solved problem already as the Object Chooser will display any extra mounted volumes in its toolbar (like a USB stick). Walter has a proposed patch already that shows your ~/Documents folder in just such a way in the Journal, so the same could be done for the Object Chooser (not sure the if ~/Documents patch works at the volume mount level so might need some extra work). The need for case 4 could then be dropped and all activity authors would automatically benefit from the new ability. If case 4 goes away, we could go back to the original design used for the Keep icon. Where we have a large user fill/stroke coloured image of the object in question (pdf, png, generic image, python, etc) and a small white arrow in the top right corner. Pointing to the document visual to indicate creation of it (export to ...), and pointing away from it to indicate loading of it (import from ...). +1. But we need to take care about what parts of the file system will be made available this way: maybe something set through gconf? Indexing everything would incur a lot of overhead and result in a very long flat (but searchable) list -- not very useful). I could see indexing $HOME/Documents, $HOME/Activities (if you set some developer switch or some other trigger), and perhaps some $HOME/Media directory that encompasses the usual Pictures, Video, Music...). One footnote: We probably still need some explicit mechanism for saving to the filesystem. If, for exampke, you open a document from $HOME/Documents in Write, the file you save is in the Journal. You could drag that file back into $HOME/Documents, but it would probably be nice to be able to explicitly write to it as well. (See my fork of Edit in git as an example.) -walter -walter Regards, --Gary Gonzalo 2011/6/16 manuel quiñones ma...@laptop.org Hi, I'm sending my first try at this icons, based on a discussion in the design meeting past sunday (sorry Gary you missed the last part). It becomes apparent that we need icons for export and import of documents. For example, Write reuses the document-save icon for export. http://dev.laptop.org/~manuq/import-export/document-import.svg http://dev.laptop.org/~manuq/import-export/document-export.svg http://dev.laptop.org/~manuq/import-export/document_import-export.png This is how they can be used in Write: http://dev.laptop.org/~manuq/import-export/import-export_mockup.png Regards, ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Walter Bender Sugar Labs
Re: [Sugar-devel] [IAEP] Olidata computers in Uruguay
On Fri, Jun 17, 2011 at 9:28 AM, Esteban Bordón ebor...@plan.ceibal.edu.uy wrote: In fact, Sugar working quite well, the main problem is that in many activities does not using the function zoom defined in sugar/graphics/style.py and doesn't scale well. In your screenshots, it becomes clear that there is a problem with the Journal detail view. We'll need to work on that. As far as individual activities, perhaps we need a Code Sprint some weekend to identify and fix the misbehaving ones, starting with the ones that are of most interest to the teachers and kids. regards. -walter I attach some screenshots. regards, Esteban Bordón Investigación y Desarrollo - Plan Ceibal Centro Ceibal - Av. Italia 6201 - Montevideo, Uruguay 2011/6/16 Walter Bender walter.ben...@gmail.com On Thu, Jun 16, 2011 at 2:58 PM, Esteban Bordón ebor...@plan.ceibal.edu.uy wrote: One of the most noticeable source for incompatibilities seems to be screen definition, 800x600 in the Olidata, and thus several Activities are cropped, Screen definition is 800x480 ... Ouch, quite a few Activity toolbars will likely overflow at 800x600 (overflow widgets land in a drop down menu in the far right of the toolbar that shows the text from the tool button hint only). The XO is a 1200x900 screen, about a year or two back there was general consensus that we should try and make sure Activities worked well down too 1024x768 as that was common in emulated environments and regular laptops/desktops. These 800x600 display machines will want to make sure they are running Sugar using an environmental variable of SUGAR_SCALING=72, this will shrink the UI scale down to fit the lower screen resolution. SUGAR_SCALING currently only has an effect at either 72 (works well for 800x600 and 1024x768) or 100 (for 1200x900 or larger). Hmm. I routinely run Sugar in a VM at 800x600 and it is -- with very few exceptions -- working quite well. I've not tried 800x480 in a while... not ideal, but it should generally work. Can you describe some of the specific problems you are encountering? -walter With SUGAR_SCALING=72 Sugar have some problems showing properties of a journal entry for example. I trying to set lower values of SUGAR_SCALING but I have not getting good results. Regards, Esteban. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Olidata computers in Uruguay
In most cases the problem is specific of the activities, then people must modify the activities one by one. 2011/6/16 Caryl Bigenho cbige...@hotmail.com Hello Esteban (and all), It would be wonderful if you or someone else could write up some very easy to follow instructions for doing the screen scaling, in Spanish, for the teachers in Uruguay. Don't assume anything. Pretend the teacher is a total beginner (on the Olidata many will be). Make it a Grannie's Guide type document and they will love you forever for doing it! Caryl (aka GrannieB) -- From: ebor...@plan.ceibal.edu.uy Date: Thu, 16 Jun 2011 15:58:43 -0300 To: garycmar...@googlemail.com CC: i...@lists.sugarlabs.org; yamap...@gmail.com; sugar-devel@lists.sugarlabs.org Subject: Re: [IAEP] [Sugar-devel] Olidata computers in Uruguay One of the most noticeable source for incompatibilities seems to be screen definition, 800x600 in the Olidata, and thus several Activities are cropped, Screen definition is 800x480 ... Ouch, quite a few Activity toolbars will likely overflow at 800x600 (overflow widgets land in a drop down menu in the far right of the toolbar that shows the text from the tool button hint only). The XO is a 1200x900 screen, about a year or two back there was general consensus that we should try and make sure Activities worked well down too 1024x768 as that was common in emulated environments and regular laptops/desktops. These 800x600 display machines will want to make sure they are running Sugar using an environmental variable of SUGAR_SCALING=72, this will shrink the UI scale down to fit the lower screen resolution. SUGAR_SCALING currently only has an effect at either 72 (works well for 800x600 and 1024x768) or 100 (for 1200x900 or larger). With SUGAR_SCALING=72 Sugar have some problems showing properties of a journal entry for example. I trying to set lower values of SUGAR_SCALING but I have not getting good results. Regards, Esteban. ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Olidata computers in Uruguay
On Fri, Jun 17, 2011 at 9:33 AM, Esteban Bordón ebor...@plan.ceibal.edu.uy wrote: In most cases the problem is specific of the activities, then people must modify the activities one by one. 2011/6/16 Caryl Bigenho cbige...@hotmail.com Hello Esteban (and all), It would be wonderful if you or someone else could write up some very easy to follow instructions for doing the screen scaling, in Spanish, for the teachers in Uruguay. Don't assume anything. Pretend the teacher is a total beginner (on the Olidata many will be). Make it a Grannie's Guide type document and they will love you forever for doing it! Caryl (aka GrannieB) From: ebor...@plan.ceibal.edu.uy Date: Thu, 16 Jun 2011 15:58:43 -0300 To: garycmar...@googlemail.com CC: i...@lists.sugarlabs.org; yamap...@gmail.com; sugar-devel@lists.sugarlabs.org Subject: Re: [IAEP] [Sugar-devel] Olidata computers in Uruguay One of the most noticeable source for incompatibilities seems to be screen definition, 800x600 in the Olidata, and thus several Activities are cropped, Screen definition is 800x480 ... Ouch, quite a few Activity toolbars will likely overflow at 800x600 (overflow widgets land in a drop down menu in the far right of the toolbar that shows the text from the tool button hint only). The XO is a 1200x900 screen, about a year or two back there was general consensus that we should try and make sure Activities worked well down too 1024x768 as that was common in emulated environments and regular laptops/desktops. These 800x600 display machines will want to make sure they are running Sugar using an environmental variable of SUGAR_SCALING=72, this will shrink the UI scale down to fit the lower screen resolution. SUGAR_SCALING currently only has an effect at either 72 (works well for 800x600 and 1024x768) or 100 (for 1200x900 or larger). With SUGAR_SCALING=72 Sugar have some problems showing properties of a journal entry for example. I trying to set lower values of SUGAR_SCALING but I have not getting good results. Regards, Esteban. ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel I've created a ticket to track the Journal Detail View problem: http://bugs.sugarlabs.org/ticket/2899 regards. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Olidata computers in Uruguay
Thanks. We'll try to start to fix the most interest activities. regards, Esteban. 2011/6/17 Walter Bender walter.ben...@gmail.com On Fri, Jun 17, 2011 at 9:33 AM, Esteban Bordón ebor...@plan.ceibal.edu.uy wrote: In most cases the problem is specific of the activities, then people must modify the activities one by one. 2011/6/16 Caryl Bigenho cbige...@hotmail.com Hello Esteban (and all), It would be wonderful if you or someone else could write up some very easy to follow instructions for doing the screen scaling, in Spanish, for the teachers in Uruguay. Don't assume anything. Pretend the teacher is a total beginner (on the Olidata many will be). Make it a Grannie's Guide type document and they will love you forever for doing it! Caryl (aka GrannieB) From: ebor...@plan.ceibal.edu.uy Date: Thu, 16 Jun 2011 15:58:43 -0300 To: garycmar...@googlemail.com CC: i...@lists.sugarlabs.org; yamap...@gmail.com; sugar-devel@lists.sugarlabs.org Subject: Re: [IAEP] [Sugar-devel] Olidata computers in Uruguay One of the most noticeable source for incompatibilities seems to be screen definition, 800x600 in the Olidata, and thus several Activities are cropped, Screen definition is 800x480 ... Ouch, quite a few Activity toolbars will likely overflow at 800x600 (overflow widgets land in a drop down menu in the far right of the toolbar that shows the text from the tool button hint only). The XO is a 1200x900 screen, about a year or two back there was general consensus that we should try and make sure Activities worked well down too 1024x768 as that was common in emulated environments and regular laptops/desktops. These 800x600 display machines will want to make sure they are running Sugar using an environmental variable of SUGAR_SCALING=72, this will shrink the UI scale down to fit the lower screen resolution. SUGAR_SCALING currently only has an effect at either 72 (works well for 800x600 and 1024x768) or 100 (for 1200x900 or larger). With SUGAR_SCALING=72 Sugar have some problems showing properties of a journal entry for example. I trying to set lower values of SUGAR_SCALING but I have not getting good results. Regards, Esteban. ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel I've created a ticket to track the Journal Detail View problem: http://bugs.sugarlabs.org/ticket/2899 regards. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Journal: Do not rescan external device if is not needed - OLPC #10841
From: Gonzalo Odiard godi...@gmail.com
Signed-off-by: Gonzalo Odiard gonz...@laptop.org
Do not rescan if the created item is not part of the currently selected view
---
src/jarabe/journal/listview.py | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/src/jarabe/journal/listview.py b/src/jarabe/journal/listview.py
index 0aee1b7..1bc8f8a 100644
--- a/src/jarabe/journal/listview.py
+++ b/src/jarabe/journal/listview.py
@@ -118,7 +118,8 @@ class BaseListView(gtk.Bin):
model.deleted.connect(self.__model_deleted_cb)
def __model_created_cb(self, sender, **kwargs):
-self._set_dirty()
+if self._is_new_item_visible(kwargs):
+self._set_dirty()
def __model_updated_cb(self, sender, **kwargs):
self._set_dirty()
@@ -126,6 +127,13 @@ class BaseListView(gtk.Bin):
def __model_deleted_cb(self, sender, **kwargs):
self._set_dirty()
+def _is_new_item_visible(self, kwargs):
+Check if the created item is part of the currently selected view
+if self._query['mountpoints'] == ['/']:
+return not kwargs['object_id'].startswith('/')
+else:
+return
kwargs['object_id'].startswith(self._query['mountpoints'][0])
+
def _add_columns(self):
cell_favorite = CellRendererFavorite(self.tree_view)
cell_favorite.connect('clicked', self.__favorite_clicked_cb)
--
1.7.4.4
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Journal: Do not rescan external device if is not needed - OLPC #10841
It would be useful to do this with the deleted and updated callbacks
too. :) Makes no sense to refresh the ListModel when the object_id
doesn't belong to it.
On Fri, Jun 17, 2011 at 10:20 AM, godi...@sugarlabs.org wrote:
From: Gonzalo Odiard godi...@gmail.com
Signed-off-by: Gonzalo Odiard gonz...@laptop.org
Do not rescan if the created item is not part of the currently selected view
---
src/jarabe/journal/listview.py | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/src/jarabe/journal/listview.py b/src/jarabe/journal/listview.py
index 0aee1b7..1bc8f8a 100644
--- a/src/jarabe/journal/listview.py
+++ b/src/jarabe/journal/listview.py
@@ -118,7 +118,8 @@ class BaseListView(gtk.Bin):
model.deleted.connect(self.__model_deleted_cb)
def __model_created_cb(self, sender, **kwargs):
- self._set_dirty()
+ if self._is_new_item_visible(kwargs):
+ self._set_dirty()
def __model_updated_cb(self, sender, **kwargs):
self._set_dirty()
@@ -126,6 +127,13 @@ class BaseListView(gtk.Bin):
def __model_deleted_cb(self, sender, **kwargs):
self._set_dirty()
+ def _is_new_item_visible(self, kwargs):
+ Check if the created item is part of the currently selected
view
+ if self._query['mountpoints'] == ['/']:
+ return not kwargs['object_id'].startswith('/')
+ else:
+ return
kwargs['object_id'].startswith(self._query['mountpoints'][0])
+
def _add_columns(self):
cell_favorite = CellRendererFavorite(self.tree_view)
cell_favorite.connect('clicked', self.__favorite_clicked_cb)
--
1.7.4.4
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Journal: Do not rescan external device if is not needed - OLPC #10841
On Fri, Jun 17, 2011 at 11:34 AM, Martin Abente
martin.abente.lah...@gmail.com wrote:
It would be useful to do this with the deleted and updated callbacks
too. :)
Was my first idea, but you can't trigger delete or update when you are
looking another view
(like uodate the journal when you are looking a external device)
Makes no sense to refresh the ListModel when the object_id
doesn't belong to it.
This is tricky too. Because in external devices, the object_id is the path
of the file,
and when you change the title in the list view, the file_name is changed,
and the object_id is not synchronized. I was doing tests, but we need change
a lot of code.
I think is better do it in a separate patch.
Gonzalo
On Fri, Jun 17, 2011 at 10:20 AM, godi...@sugarlabs.org wrote:
From: Gonzalo Odiard godi...@gmail.com
Signed-off-by: Gonzalo Odiard gonz...@laptop.org
Do not rescan if the created item is not part of the currently selected
view
---
src/jarabe/journal/listview.py | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/src/jarabe/journal/listview.py
b/src/jarabe/journal/listview.py
index 0aee1b7..1bc8f8a 100644
--- a/src/jarabe/journal/listview.py
+++ b/src/jarabe/journal/listview.py
@@ -118,7 +118,8 @@ class BaseListView(gtk.Bin):
model.deleted.connect(self.__model_deleted_cb)
def __model_created_cb(self, sender, **kwargs):
-self._set_dirty()
+if self._is_new_item_visible(kwargs):
+self._set_dirty()
def __model_updated_cb(self, sender, **kwargs):
self._set_dirty()
@@ -126,6 +127,13 @@ class BaseListView(gtk.Bin):
def __model_deleted_cb(self, sender, **kwargs):
self._set_dirty()
+def _is_new_item_visible(self, kwargs):
+Check if the created item is part of the currently selected
view
+if self._query['mountpoints'] == ['/']:
+return not kwargs['object_id'].startswith('/')
+else:
+return
kwargs['object_id'].startswith(self._query['mountpoints'][0])
+
def _add_columns(self):
cell_favorite = CellRendererFavorite(self.tree_view)
cell_favorite.connect('clicked', self.__favorite_clicked_cb)
--
1.7.4.4
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
--
Gonzalo Odiard
SugarLabs Argentina
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Olidata computers in Uruguay
On 17 Jun 2011, at 14:42, Esteban Bordón wrote: Thanks. We'll try to start to fix the most interest activities. Thanks for your screenshots. I've created a ticket for Cartoon Builder, TamTamMini, and Distance, if you could report and take more screenshots of other activities you discover that would be very helpful: http://bugs.sugarlabs.org/ticket/2900 http://bugs.sugarlabs.org/ticket/2901 http://bugs.sugarlabs.org/ticket/2902 Some background FWIW: Much of Sugar and its activities were designed with the 1200x900 screen in mind, luckily with the XO screen rotation feature most developers were also often reminded and aware of needing to make sure their design layouts were flexible enough to work at 900x1200. When Sugar Labs was spun off from OLPC to work on Sugar, there was much effort from SL to make Sugar more hardware agnostic and work on more traditional laptops, part of this meant that 1024x768 was much more commonly being used and tested by developers; and the default when running Sugar in a window under Gnome was 800x600, which has been generally treated as the worst case scenario. So it's that 480 vertical pixels count, a reduction of 120 from our assumed worst case, that's catching some of us out ;-) Regards, --Gary regards, Esteban. 2011/6/17 Walter Bender walter.ben...@gmail.com On Fri, Jun 17, 2011 at 9:33 AM, Esteban Bordón ebor...@plan.ceibal.edu.uy wrote: In most cases the problem is specific of the activities, then people must modify the activities one by one. 2011/6/16 Caryl Bigenho cbige...@hotmail.com Hello Esteban (and all), It would be wonderful if you or someone else could write up some very easy to follow instructions for doing the screen scaling, in Spanish, for the teachers in Uruguay. Don't assume anything. Pretend the teacher is a total beginner (on the Olidata many will be). Make it a Grannie's Guide type document and they will love you forever for doing it! Caryl (aka GrannieB) From: ebor...@plan.ceibal.edu.uy Date: Thu, 16 Jun 2011 15:58:43 -0300 To: garycmar...@googlemail.com CC: i...@lists.sugarlabs.org; yamap...@gmail.com; sugar-devel@lists.sugarlabs.org Subject: Re: [IAEP] [Sugar-devel] Olidata computers in Uruguay One of the most noticeable source for incompatibilities seems to be screen definition, 800x600 in the Olidata, and thus several Activities are cropped, Screen definition is 800x480 ... Ouch, quite a few Activity toolbars will likely overflow at 800x600 (overflow widgets land in a drop down menu in the far right of the toolbar that shows the text from the tool button hint only). The XO is a 1200x900 screen, about a year or two back there was general consensus that we should try and make sure Activities worked well down too 1024x768 as that was common in emulated environments and regular laptops/desktops. These 800x600 display machines will want to make sure they are running Sugar using an environmental variable of SUGAR_SCALING=72, this will shrink the UI scale down to fit the lower screen resolution. SUGAR_SCALING currently only has an effect at either 72 (works well for 800x600 and 1024x768) or 100 (for 1200x900 or larger). With SUGAR_SCALING=72 Sugar have some problems showing properties of a journal entry for example. I trying to set lower values of SUGAR_SCALING but I have not getting good results. Regards, Esteban. ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel I've created a ticket to track the Journal Detail View problem: http://bugs.sugarlabs.org/ticket/2899 regards. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Olidata computers in Uruguay
FYI, I acquired a Gen1 Classmate with 7 screen (an Olidata JumPc) for testing purposes two years ago and with Martin Langhoff's help filed a ticket on this issue: http://bugs.sugarlabs.org/ticket/868 this photo of mine may be helpful to see what we're talking about: http://www.flickr.com/photos/39656470@N02/3648785920/in/photostream I remember being told that there were no plans to scale Sugar screens to work with 480, that 600 was the minimum Sean On Fri, Jun 17, 2011 at 5:16 PM, Gary Martin garycmar...@googlemail.com wrote: On 17 Jun 2011, at 14:42, Esteban Bordón wrote: Thanks. We'll try to start to fix the most interest activities. Thanks for your screenshots. I've created a ticket for Cartoon Builder, TamTamMini, and Distance, if you could report and take more screenshots of other activities you discover that would be very helpful: http://bugs.sugarlabs.org/ticket/2900 http://bugs.sugarlabs.org/ticket/2901 http://bugs.sugarlabs.org/ticket/2902 Some background FWIW: Much of Sugar and its activities were designed with the 1200x900 screen in mind, luckily with the XO screen rotation feature most developers were also often reminded and aware of needing to make sure their design layouts were flexible enough to work at 900x1200. When Sugar Labs was spun off from OLPC to work on Sugar, there was much effort from SL to make Sugar more hardware agnostic and work on more traditional laptops, part of this meant that 1024x768 was much more commonly being used and tested by developers; and the default when running Sugar in a window under Gnome was 800x600, which has been generally treated as the worst case scenario. So it's that 480 vertical pixels count, a reduction of 120 from our assumed worst case, that's catching some of us out ;-) Regards, --Gary regards, Esteban. 2011/6/17 Walter Bender walter.ben...@gmail.com On Fri, Jun 17, 2011 at 9:33 AM, Esteban Bordón ebor...@plan.ceibal.edu.uy wrote: In most cases the problem is specific of the activities, then people must modify the activities one by one. 2011/6/16 Caryl Bigenho cbige...@hotmail.com Hello Esteban (and all), It would be wonderful if you or someone else could write up some very easy to follow instructions for doing the screen scaling, in Spanish, for the teachers in Uruguay. Don't assume anything. Pretend the teacher is a total beginner (on the Olidata many will be). Make it a Grannie's Guide type document and they will love you forever for doing it! Caryl (aka GrannieB) From: ebor...@plan.ceibal.edu.uy Date: Thu, 16 Jun 2011 15:58:43 -0300 To: garycmar...@googlemail.com CC: i...@lists.sugarlabs.org; yamap...@gmail.com; sugar-devel@lists.sugarlabs.org Subject: Re: [IAEP] [Sugar-devel] Olidata computers in Uruguay One of the most noticeable source for incompatibilities seems to be screen definition, 800x600 in the Olidata, and thus several Activities are cropped, Screen definition is 800x480 ... Ouch, quite a few Activity toolbars will likely overflow at 800x600 (overflow widgets land in a drop down menu in the far right of the toolbar that shows the text from the tool button hint only). The XO is a 1200x900 screen, about a year or two back there was general consensus that we should try and make sure Activities worked well down too 1024x768 as that was common in emulated environments and regular laptops/desktops. These 800x600 display machines will want to make sure they are running Sugar using an environmental variable of SUGAR_SCALING=72, this will shrink the UI scale down to fit the lower screen resolution. SUGAR_SCALING currently only has an effect at either 72 (works well for 800x600 and 1024x768) or 100 (for 1200x900 or larger). With SUGAR_SCALING=72 Sugar have some problems showing properties of a journal entry for example. I trying to set lower values of SUGAR_SCALING but I have not getting good results. Regards, Esteban. ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel I've created a ticket to track the Journal Detail View problem: http://bugs.sugarlabs.org/ticket/2899 regards. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [Sugar-devel] [SoaS] new SoaSv5 test image - Last change to test and fix issues
Thomas C Gilliard wrote: Testing 06/14/2011 -Trying to create a 2 GB .img file for dd writing to 2 GB USB's- SoaSv5-20110612-i686.iso - fresh download http://fedora.roving-it.com/SoaSv5-20110612-i686.iso *boot CD ACER ASPIRE ONE N450-(external usb DVD/CD writer) :insert new USB (Lexar firefly 4GB) *sugar terminal su password (not needed) :liveinst custom / ext4 fill all of usb no swap copyright on f15 anacona install screen is 2003-2010 sucessful *start f15 gnome3-shell from 500GB external HD install insert new USB *gparted: : check device name terminal: # dd if=/dev/sdb of=SoaSv5-20110612 bs=4k *gparted: resize partition to 2GiB *Boot resized USB nm-connection-editor wireless add (wep ascii password) connects to AP as finish adding ssid surf and IRC connect on wireless NO Jabber connection Insert wired network My Settings/About Me/color change; restart f1 Neighborhood fills with 200 Avitars unplug eth0 My Settings/About Me/color change; restart f1 Neighborhood is empty *note jabber only seems to work on a wired eth0 connection :wireless does not see jabber : did not start message not present as often on starting applications :restart works w/o Plymouth: (nomodeset progress bars) This is the same for a booted CD:SoaSv5-20110612 *It takes much longer to get journal to display on f3 when the Ethernet cable is plugged in. *This seems to be related to the huge sets of data being downloaded from the jabber. (over 200 avitars fill the screen.) This only occurs on sugar 0.92.1. Sugar 0.88.1 displays 10-20 avitars at same time. There must be a different method of broadcast from the jabber, being used for 0.92.1 *wireless AP (connected with nm-connection-editor) works for surf and IRC but Jabber remains empty when only wireless connection is used. Tom Gilliard satellit Peter Robinson wrote: Hi All, I was hoping to have this out over a week ago but I had a slight diversion via hospital which delayed proceedings. So below are links to a new pair (32 and 64 bit) of images for your testing pleasure. http://fedora.roving-it.com/SoaSv5-20110612-x86_64.iso http://fedora.roving-it.com/SoaSv5-20110612-i686.iso The network issue is still there, its partially working from the work that I did with some assistance from John Dulaney. I've included another utility to enable initial configuration of a wireless access point and from there it will auto connect and should mostly work. There's issues with the main network view and in the control panel but it seems no one else cares enough to assist me in getting it fixed. To configure an AP run the command nm-connection-editor from a terminal as the standard user (not root). I don't believe there are any other major blockers for this release. If you believe there to be any issues speak up now and provide fixes for it. NOTE: This is the last chance to test and get things fixed. Please provide concise details to any issues in reply to this mail. Cheers, Peter ___ SoaS mailing list s...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/soas ___ SoaS mailing list s...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/soas ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] new SoaSv5 test image - Last change to test and fix issues
Thomas C Gilliard wrote: Thomas C Gilliard wrote: Testing 06/14/2011 -Trying to create a 2 GB .img file for dd writing to 2 GB USB's- SoaSv5-20110612-i686.iso - fresh download http://fedora.roving-it.com/SoaSv5-20110612-i686.iso *boot CD ACER ASPIRE ONE N450-(external usb DVD/CD writer) :insert new USB (Lexar firefly 4GB) *sugar terminal su password (not needed) :liveinst custom / ext4 fill all of usb no swap copyright on f15 anacona install screen is 2003-2010 sucessful *start f15 gnome3-shell from 500GB external HD install insert new USB *gparted: : check device name terminal: # dd if=/dev/sdb of=SoaSv5-20110612 bs=4k *gparted: resize partition to 2GiB *Boot resized USB nm-connection-editor wireless add (wep ascii password) connects to AP as finish adding ssid surf and IRC connect on wireless NO Jabber connection Insert wired network My Settings/About Me/color change; restart f1 Neighborhood fills with 200 Avitars unplug eth0 My Settings/About Me/color change; restart f1 Neighborhood is empty *note jabber only seems to work on a wired eth0 connection :wireless does not see jabber : did not start message not present as often on starting applications :restart works w/o Plymouth: (nomodeset progress bars) This is the same for a booted CD:SoaSv5-20110612 *It takes much longer to get journal to display on f3 when the Ethernet cable is plugged in. *This seems to be related to the huge sets of data being downloaded from the jabber. (over 200 avitars fill the screen.) This only occurs on sugar 0.92.1. Sugar 0.88.1 displays 10-20 avitars at same time. There must be a different method of broadcast from the jabber, being used for 0.92.1 *wireless AP (connected with nm-connection-editor) works for surf and IRC but Jabber remains empty when only wireless connection is used. Correction: after 5 minutes using surf on wireless AP the jabber did show the 200 avitars f1 field goes grey and after about 10 sec they appear Tom Gilliard satellit Peter Robinson wrote: Hi All, I was hoping to have this out over a week ago but I had a slight diversion via hospital which delayed proceedings. So below are links to a new pair (32 and 64 bit) of images for your testing pleasure. http://fedora.roving-it.com/SoaSv5-20110612-x86_64.iso http://fedora.roving-it.com/SoaSv5-20110612-i686.iso The network issue is still there, its partially working from the work that I did with some assistance from John Dulaney. I've included another utility to enable initial configuration of a wireless access point and from there it will auto connect and should mostly work. There's issues with the main network view and in the control panel but it seems no one else cares enough to assist me in getting it fixed. To configure an AP run the command nm-connection-editor from a terminal as the standard user (not root). I don't believe there are any other major blockers for this release. If you believe there to be any issues speak up now and provide fixes for it. NOTE: This is the last chance to test and get things fixed. Please provide concise details to any issues in reply to this mail. Cheers, Peter ___ SoaS mailing list s...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/soas ___ SoaS mailing list s...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/soas ___ SoaS mailing list s...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/soas ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On Tue, Jun 14, 2011 at 6:52 PM, Marco Pesenti Gritti ma...@marcopg.org wrote: With WebKit2, this all you need to load a web page into a GtkBox So that's my understanding of WebKit -- it's easily embeddable. I am not sure whether the API is as complete or as good as we want it. IOWs, it's likely not a trivial job to get a good polished result. Just from using the various webkit-based browsers in existence in recent Fedoras and Ubuntus -- while both Safari and Webkit are outstanding (and backed by large dev teams), Surf limited but workable (a few versions back, need to test latest!...) everything else has been very unstable and disappointing. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On 17 June 2011 17:51, Martin Langhoff martin.langh...@gmail.com wrote: On Tue, Jun 14, 2011 at 6:52 PM, Marco Pesenti Gritti ma...@marcopg.org wrote: With WebKit2, this all you need to load a web page into a GtkBox So that's my understanding of WebKit -- it's easily embeddable. I am not sure whether the API is as complete or as good as we want it. I think the WebKit2 API must be complete or Apple wouldn't have been able to build Safari on the top of it. What I'm not sure is if the gtk backend implementation is complete/polished enough. IOWs, it's likely not a trivial job to get a good polished result. Absolutely not trivial. It would be probably quicker to get a working browser by forking firefox or chrome, but then maintenance would be quite a burden. Just from using the various webkit-based browsers in existence in recent Fedoras and Ubuntus -- while both Safari and Webkit are outstanding (and backed by large dev teams), Surf limited but workable (a few versions back, need to test latest!...) everything else has been very unstable and disappointing. Did you test epiphany? I think that would give you a pretty decent idea of what is achievable without putting work into WebKit itself. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On Fri, Jun 17, 2011 at 1:00 PM, Marco Pesenti Gritti ma...@marcopg.org wrote: Did you test epiphany? I think that would give you a pretty decent idea of what is achievable without putting work into WebKit itself. Not in a while. Earlier builds on Ubuntu were very unstable and buggy. Just installed on F15 - will try out. m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] FUSE for Journal?
I've been messing with FUSE (http://en.wikipedia.org/wiki/Filesystem_in_Userspace) in another context (http://en.wikipedia.org/wiki/Tahoe_Least-Authority_Filesystem) and was wondering if the Sugar Journal would talk to FUSE in any way. That might allow us to bridge Nautilus field manager and the Journal. Although I can't imagine this never came up before... cheers, Sameer ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] FUSE for Journal?
Actually, I have been playing with it in the last 2 days. What I am basically doing (as a proof on concept) is a xmlrpc-FUSE filesystem. Since FUSE provides a native FS interaction there is nothing special to be done, _it works_ (I mean it literally) just as a external storage device. What is very interesting about this approach is that is available also from gnome and that it doesn't require anything new/extra in sugar. If someone is interested I can upload the code somewhere this weekend. On Fri, Jun 17, 2011 at 2:27 PM, Sameer Verma sve...@sfsu.edu wrote: I've been messing with FUSE (http://en.wikipedia.org/wiki/Filesystem_in_Userspace) in another context (http://en.wikipedia.org/wiki/Tahoe_Least-Authority_Filesystem) and was wondering if the Sugar Journal would talk to FUSE in any way. That might allow us to bridge Nautilus field manager and the Journal. Although I can't imagine this never came up before... cheers, Sameer ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] FUSE for Journal?
There are other older intents: http://lists.sugarlabs.org/archive/sugar-devel/2009-June/014815.html http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg14612.html Gonzalo On Fri, Jun 17, 2011 at 3:36 PM, Martin Abente martin.abente.lah...@gmail.com wrote: Actually, I have been playing with it in the last 2 days. What I am basically doing (as a proof on concept) is a xmlrpc-FUSE filesystem. Since FUSE provides a native FS interaction there is nothing special to be done, _it works_ (I mean it literally) just as a external storage device. What is very interesting about this approach is that is available also from gnome and that it doesn't require anything new/extra in sugar. If someone is interested I can upload the code somewhere this weekend. On Fri, Jun 17, 2011 at 2:27 PM, Sameer Verma sve...@sfsu.edu wrote: I've been messing with FUSE (http://en.wikipedia.org/wiki/Filesystem_in_Userspace) in another context (http://en.wikipedia.org/wiki/Tahoe_Least-Authority_Filesystem) and was wondering if the Sugar Journal would talk to FUSE in any way. That might allow us to bridge Nautilus field manager and the Journal. Although I can't imagine this never came up before... cheers, Sameer ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] FUSE for Journal?
Not 100% sure, but the conditions changed a little bit since then: * The journal integrates a better with external storage devices. * There are good bindings for fuse (even in python). I think that a fuse-based-network-file-system could be a pretty flexible and valid option for entry-level backup in XS over LAN (for that particular scope). I am not talking about running an OS on top of it, or using it to replace the local storage over the internet. Is just my opinion though based on what I have tested so far. On Fri, Jun 17, 2011 at 2:41 PM, Gonzalo Odiard gonz...@laptop.org wrote: There are other older intents: http://lists.sugarlabs.org/archive/sugar-devel/2009-June/014815.html http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg14612.html Gonzalo On Fri, Jun 17, 2011 at 3:36 PM, Martin Abente martin.abente.lah...@gmail.com wrote: Actually, I have been playing with it in the last 2 days. What I am basically doing (as a proof on concept) is a xmlrpc-FUSE filesystem. Since FUSE provides a native FS interaction there is nothing special to be done, _it works_ (I mean it literally) just as a external storage device. What is very interesting about this approach is that is available also from gnome and that it doesn't require anything new/extra in sugar. If someone is interested I can upload the code somewhere this weekend. On Fri, Jun 17, 2011 at 2:27 PM, Sameer Verma sve...@sfsu.edu wrote: I've been messing with FUSE (http://en.wikipedia.org/wiki/Filesystem_in_Userspace) in another context (http://en.wikipedia.org/wiki/Tahoe_Least-Authority_Filesystem) and was wondering if the Sugar Journal would talk to FUSE in any way. That might allow us to bridge Nautilus field manager and the Journal. Although I can't imagine this never came up before... cheers, Sameer ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] FUSE for Journal?
Excerpts from Sameer Verma's message of Fri Jun 17 20:27:46 +0200 2011: I've been messing with FUSE (http://en.wikipedia.org/wiki/Filesystem_in_Userspace) in another context (http://en.wikipedia.org/wiki/Tahoe_Least-Authority_Filesystem) and was wondering if the Sugar Journal would talk to FUSE in any way. Please give datastore-fuse [1] a try. Besides Sugar it needs just python-fuse = 0.2. I've mentioned this project both on sugar-devel and on IRC several times, but got no feedback from anyone who tried it. Sascha [1] http://git.sugarlabs.org/datastore-fuse/ -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Olidata computers in Uruguay
Hi Sean, On 17 Jun 2011, at 16:39, Sean DALY wrote: FYI, I acquired a Gen1 Classmate with 7 screen (an Olidata JumPc) for testing purposes two years ago and with Martin Langhoff's help filed a ticket on this issue: http://bugs.sugarlabs.org/ticket/868 Thanks, yes that ended up as closed as a duplicate of: http://bugs.sugarlabs.org/ticket/308 Which is reported as fixed (though not something I have tested myself). If reports filtering through that Uyaguay have indeed already purchased 30,000 (!!) of these for use by teachers then we need to try and get tickets open for all the major cases. Hopefully we will also see some support from the Uy deployment as when saving money thru buying cheaper but different spec hardware, putting some efforts in bringing the needed software up to the deployments requirements must be expected. this photo of mine may be helpful to see what we're talking about: http://www.flickr.com/photos/39656470@N02/3648785920/in/photostream Thanks, I think I also caught a photo of it from the recent EduJam flickr stream, nice to see you were well ahead of the storm front ;-) I remember being told that there were no plans to scale Sugar screens to work with 480, that 600 was the minimum I'm happy to tweak activities I directly maintain if needed, and provide some design suggestions for others if needed (as long as we don't degrade the experience for the majority). But if the 30k Uy purchase of these machines is an accurate report, we should try to help where we can (understanding that the majority of us are volunteers putting what free time we have into the effort). Regards, --Gary Sean On Fri, Jun 17, 2011 at 5:16 PM, Gary Martin garycmar...@googlemail.com wrote: On 17 Jun 2011, at 14:42, Esteban Bordón wrote: Thanks. We'll try to start to fix the most interest activities. Thanks for your screenshots. I've created a ticket for Cartoon Builder, TamTamMini, and Distance, if you could report and take more screenshots of other activities you discover that would be very helpful: http://bugs.sugarlabs.org/ticket/2900 http://bugs.sugarlabs.org/ticket/2901 http://bugs.sugarlabs.org/ticket/2902 Some background FWIW: Much of Sugar and its activities were designed with the 1200x900 screen in mind, luckily with the XO screen rotation feature most developers were also often reminded and aware of needing to make sure their design layouts were flexible enough to work at 900x1200. When Sugar Labs was spun off from OLPC to work on Sugar, there was much effort from SL to make Sugar more hardware agnostic and work on more traditional laptops, part of this meant that 1024x768 was much more commonly being used and tested by developers; and the default when running Sugar in a window under Gnome was 800x600, which has been generally treated as the worst case scenario. So it's that 480 vertical pixels count, a reduction of 120 from our assumed worst case, that's catching some of us out ;-) Regards, --Gary regards, Esteban. 2011/6/17 Walter Bender walter.ben...@gmail.com On Fri, Jun 17, 2011 at 9:33 AM, Esteban Bordón ebor...@plan.ceibal.edu.uy wrote: In most cases the problem is specific of the activities, then people must modify the activities one by one. 2011/6/16 Caryl Bigenho cbige...@hotmail.com Hello Esteban (and all), It would be wonderful if you or someone else could write up some very easy to follow instructions for doing the screen scaling, in Spanish, for the teachers in Uruguay. Don't assume anything. Pretend the teacher is a total beginner (on the Olidata many will be). Make it a Grannie's Guide type document and they will love you forever for doing it! Caryl (aka GrannieB) From: ebor...@plan.ceibal.edu.uy Date: Thu, 16 Jun 2011 15:58:43 -0300 To: garycmar...@googlemail.com CC: i...@lists.sugarlabs.org; yamap...@gmail.com; sugar-devel@lists.sugarlabs.org Subject: Re: [IAEP] [Sugar-devel] Olidata computers in Uruguay One of the most noticeable source for incompatibilities seems to be screen definition, 800x600 in the Olidata, and thus several Activities are cropped, Screen definition is 800x480 ... Ouch, quite a few Activity toolbars will likely overflow at 800x600 (overflow widgets land in a drop down menu in the far right of the toolbar that shows the text from the tool button hint only). The XO is a 1200x900 screen, about a year or two back there was general consensus that we should try and make sure Activities worked well down too 1024x768 as that was common in emulated environments and regular laptops/desktops. These 800x600 display machines will want to make sure they are running Sugar using an environmental variable of SUGAR_SCALING=72, this will shrink the UI scale down to fit the lower screen resolution. SUGAR_SCALING currently only has an effect at either 72 (works well for
Re: [Sugar-devel] [IAEP] Olidata computers in Uruguay
On Fri, Jun 17, 2011 at 4:23 PM, Gary Martin garycmar...@googlemail.com wrote: Hi Sean, On 17 Jun 2011, at 16:39, Sean DALY wrote: FYI, I acquired a Gen1 Classmate with 7 screen (an Olidata JumPc) for testing purposes two years ago and with Martin Langhoff's help filed a ticket on this issue: http://bugs.sugarlabs.org/ticket/868 Thanks, yes that ended up as closed as a duplicate of: http://bugs.sugarlabs.org/ticket/308 Which is reported as fixed (though not something I have tested myself). If reports filtering through that Uyaguay have indeed already purchased 30,000 (!!) of these for use by teachers then we need to try and get tickets open for all the major cases. Hopefully we will also see some support from the Uy deployment as when saving money thru buying cheaper but different spec hardware, putting some efforts in bringing the needed software up to the deployments requirements must be expected. this photo of mine may be helpful to see what we're talking about: http://www.flickr.com/photos/39656470@N02/3648785920/in/photostream Thanks, I think I also caught a photo of it from the recent EduJam flickr stream, nice to see you were well ahead of the storm front ;-) I remember being told that there were no plans to scale Sugar screens to work with 480, that 600 was the minimum I'm happy to tweak activities I directly maintain if needed, and provide some design suggestions for others if needed (as long as we don't degrade the experience for the majority). But if the 30k Uy purchase of these machines is an accurate report, we should try to help where we can (understanding that the majority of us are volunteers putting what free time we have into the effort). I think the easiest thing would be to add a scrolling window...only if the resolution is below some threshold; not ideal in some cases, but at least most activities should work. -walter Regards, --Gary Sean On Fri, Jun 17, 2011 at 5:16 PM, Gary Martin garycmar...@googlemail.com wrote: On 17 Jun 2011, at 14:42, Esteban Bordón wrote: Thanks. We'll try to start to fix the most interest activities. Thanks for your screenshots. I've created a ticket for Cartoon Builder, TamTamMini, and Distance, if you could report and take more screenshots of other activities you discover that would be very helpful: http://bugs.sugarlabs.org/ticket/2900 http://bugs.sugarlabs.org/ticket/2901 http://bugs.sugarlabs.org/ticket/2902 Some background FWIW: Much of Sugar and its activities were designed with the 1200x900 screen in mind, luckily with the XO screen rotation feature most developers were also often reminded and aware of needing to make sure their design layouts were flexible enough to work at 900x1200. When Sugar Labs was spun off from OLPC to work on Sugar, there was much effort from SL to make Sugar more hardware agnostic and work on more traditional laptops, part of this meant that 1024x768 was much more commonly being used and tested by developers; and the default when running Sugar in a window under Gnome was 800x600, which has been generally treated as the worst case scenario. So it's that 480 vertical pixels count, a reduction of 120 from our assumed worst case, that's catching some of us out ;-) Regards, --Gary regards, Esteban. 2011/6/17 Walter Bender walter.ben...@gmail.com On Fri, Jun 17, 2011 at 9:33 AM, Esteban Bordón ebor...@plan.ceibal.edu.uy wrote: In most cases the problem is specific of the activities, then people must modify the activities one by one. 2011/6/16 Caryl Bigenho cbige...@hotmail.com Hello Esteban (and all), It would be wonderful if you or someone else could write up some very easy to follow instructions for doing the screen scaling, in Spanish, for the teachers in Uruguay. Don't assume anything. Pretend the teacher is a total beginner (on the Olidata many will be). Make it a Grannie's Guide type document and they will love you forever for doing it! Caryl (aka GrannieB) From: ebor...@plan.ceibal.edu.uy Date: Thu, 16 Jun 2011 15:58:43 -0300 To: garycmar...@googlemail.com CC: i...@lists.sugarlabs.org; yamap...@gmail.com; sugar-devel@lists.sugarlabs.org Subject: Re: [IAEP] [Sugar-devel] Olidata computers in Uruguay One of the most noticeable source for incompatibilities seems to be screen definition, 800x600 in the Olidata, and thus several Activities are cropped, Screen definition is 800x480 ... Ouch, quite a few Activity toolbars will likely overflow at 800x600 (overflow widgets land in a drop down menu in the far right of the toolbar that shows the text from the tool button hint only). The XO is a 1200x900 screen, about a year or two back there was general consensus that we should try and make sure Activities worked well down too 1024x768 as that was common in emulated environments and regular laptops/desktops. These
Re: [Sugar-devel] [!! SPAM] Re: [IAEP] Olidata computers in Uruguay
/Gary Martin wrote: Uruguay have indeed already purchased 30,000 (!!) of these ---/ It is Correct your information, GAry. On july 2010 Uruguay bought 30,040 Olidata JumPC http://www.olidata.cl/index.php/netbook_web/show/id/10., with 8 Gb of Flash-disk. Here it is the official web page of Ceibal http://www.ceibal.org.uy/index.php?option=com_contentview=articleid=215:licitacion-publica-no-10652010-catid=52:convocatorias-cerradasItemid=83, with the price of that sell. Paolo Benini Montevideo ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Ominoes-22
Activity Homepage: http://activities.sugarlabs.org/addon/4422 Sugar Platform: 0.82 - 0.92 Download Now: http://activities.sugarlabs.org/downloads/file/27424/ominoes-22.xo Release notes: Tablet mode has been added. This is the scheme: * x = left click * o = right click = try * tick or enter = change level * arrow keys will move the pointer Ominoes will now work properly without alteration in a non-Sugar environment. I'm gradually revisiting all my activities. To make it easy to recognise these revisited versions, they will all start at Version number 21. You can easily tell which version you have by pressing the v key - if this gives no response, then you have an older version. Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] FUSE for Journal?
On Fri, Jun 17, 2011 at 09:58:33PM +0200, Sascha Silbe wrote: Please give datastore-fuse [1] a try. Besides Sugar it needs just python-fuse = 0.2. I've mentioned this project both on sugar-devel and on IRC several times, but got no feedback from anyone who tried it. datastore-fuse is great. I tried it and liked it. Sascha Martin [1] http://git.sugarlabs.org/datastore-fuse/ pgpjnvMKd0mTD.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Speak-27
Activity Homepage: http://activities.sugarlabs.org/addon/4038 Sugar Platform: 0.82 - 0.92 Download Now: http://activities.sugarlabs.org/downloads/file/27427/speak-27.xo Release notes: *Minus speak rate for robot SL#2893 *pep8 fixes for chatbox.py *More translations Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Words-9
Activity Homepage: http://activities.sugarlabs.org/addon/4315 Sugar Platform: 0.82 - 0.92 Download Now: http://activities.sugarlabs.org/downloads/file/27428/words-9.xo Release notes: *Adding logger for activity.py *Imports in one line, more pep8 fixes *Espanish code comments Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Is Apple's New OS X Copying Sugar???
Hi folks, Maybe what seem to be problems with Sugar aren't so bad after all. In fact, it looks like Apple is using some of our stuff! The most striking is the new Air Drop feature which is, essentially, our mesh network! It uses wi-fi and even has a view that I swear is is a copy of our Neighborhood View! Also, while you are all worrying about reducing the number of saves to the Journal, Apple's has made it's new Lion version of OS X have an autosave feature that constantly saves multiple versions of your projects. Of course, a lot of software already has this feature, but now it seems to apply to everything you might be running on the Apple. I found all this by watching Apple's video of their presentation at the WWDC last week. It's a long video (about 2 hours). Unless you are an Apple aficionado, I wouldn't recommend it. Caryl ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Unity desktop in Ubuntu (was Re: Is Apple's New OS X Copying Sugar???)
On Fri, June 17, 2011 6:51 pm, Caryl Bigenho wrote: Hi folks, Maybe what seem to be problems with Sugar aren't so bad after all. In fact, it looks like Apple is using some of our stuff! So is Ubuntu's new default desktop, Unity. Instead of a menu of applications, it has a display of icons for frequently-used apps, installed apps, and installable apps, with an option to select a subset such as Office, Accessories, System and so on, and a search box for typing any part of the app name or description. But these ideas are in the air. The search field in our journal or in Unity is very much like the Firefox Awesome Bar for searching by URL or title among Web pages that you have visited. Unity also has a bar on the left for active apps and some other icons, which relates to the Apple dock and also to the Sugar frame. Like the frame, it slides out when you put the mouse pointer into the corner or along the edge, according to a preference setting. One of the icons allows you to search for a document by icon or with the search box, rather like the Journal except that it also searches for folders. The most striking is the new Air Drop feature which is, essentially, our mesh network! It uses wi-fi and even has a view that I swear is is a copy of our Neighborhood View! Also, while you are all worrying about reducing the number of saves to the Journal, Apple's has made it's new Lion version of OS X have an autosave feature that constantly saves multiple versions of your projects. Of course, a lot of software already has this feature, but now it seems to apply to everything you might be running on the Apple. I found all this by watching Apple's video of their presentation at the WWDC last week. It's a long video (about 2 hours). Unless you are an Apple aficionado, I wouldn't recommend it. Caryl ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Edward Mokurai (#40664;#38647;/#2343;#2352;#2381;#2350;#2350;#2375;#2328;#2358;#2348;#2381;#2342;#2327;#2352;#2381;#2332;/#1583;#1726;#1585;#1605;#1605;#1740;#1711;#1726;#1588;#1576;#1583;#1711;#1585; #1580;) Cherlin Silent Thunder is my name, and Children are my nation. The Cosmos is my dwelling place, the Truth my destination. http://wiki.sugarlabs.org/go/Replacing_Textbooks ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] FUSE for Journal?
On Fri, Jun 17, 2011 at 11:36 AM, Martin Abente martin.abente.lah...@gmail.com wrote: Actually, I have been playing with it in the last 2 days. What I am basically doing (as a proof on concept) is a xmlrpc-FUSE filesystem. Since FUSE provides a native FS interaction there is nothing special to be done, _it works_ (I mean it literally) just as a external storage device. What is very interesting about this approach is that is available also from gnome and that it doesn't require anything new/extra in sugar. If someone is interested I can upload the code somewhere this weekend. Oh, good! So someone else *is* thinking about this as well :-) I was thinking of FUSE in the context of the ongoing discussion on IAEP and elsewhere of the Journal being difficult to interoperate with the expectation of a file manager. cheers, Sameer On Fri, Jun 17, 2011 at 2:27 PM, Sameer Verma sve...@sfsu.edu wrote: I've been messing with FUSE (http://en.wikipedia.org/wiki/Filesystem_in_Userspace) in another context (http://en.wikipedia.org/wiki/Tahoe_Least-Authority_Filesystem) and was wondering if the Sugar Journal would talk to FUSE in any way. That might allow us to bridge Nautilus field manager and the Journal. Although I can't imagine this never came up before... cheers, Sameer ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Familiar Journal ideas
I've been reading the emails about the Journal. I have my own opinions on the subject that I've expressed many times in the past, but as one of Heinlein's characters points out, anything worth doing is worth overdoing. So here they are again. 1). The Journal Activity needs to stop showing the contents of thumb drives and SD cards as if they were Journal entries. They are not Journal entries, and having the user interface pretend that they are causes confusion on just what the Journal *is*. 2). The various metadata for Journal entries needs to be more visible. A casual user of Sugar has no idea that each Journal entry has a screen grab, a Descriptive text field, etc. because they are not visible unless you go looking for them and know how to look. If you want the child to fill in a description for his work, make it obvious that the field exists. My concept for what the Journal Activity should be like is Sugar Commander: http://activities.sugarlabs.org/en-US/sugar/addon/4291 I don't claim that this is a perfect design, but it does demonstrate just what a Journal entry is, shows how much disk space each one takes up, lets you sort the entries different ways, and gives you a familiar interface for the files on a thumb drive or SD card that accurately shows the files and directories on them as they are. James Simmons ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
