Re: [Sugar-devel] [DESIGN] icons for import/export document proposal
2011/6/16 manuel quiñones manuel.por@gmail.com 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. One might adjust the perspective to flatten the arrows and keep the document symbols their original size. This perhaps suggests the before and after relationship; but the overlaid symbols may be visually simpler to grasp, especially when the images are small (such as when they are displayed in a file listing). (See these pages for making Sugarized icons: http://wiki.sugarlabs.org/go/Development_Team/Almanac/Making_Icons#Sugarizing_Icons http://wiki.laptop.org/go/Sugar-iconify ) --Fred attachment: document-export2.sugar.svgattachment: document-import2.sugar.svg___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Display build number at Name Page
On 06/15/2011 05:01 PM, Esteban Bordón wrote: This patch show the build number in the name page for first boot (see attached file). It's very useful to test the correct massive flashing for technical team. Hi Esteban, thanks for your patch. I would like to add the build information to the startup screen [1]. This gives you the information earlier when booting and does not only give you the information the first time. I know that dextrose has done the same thing. It was a bit late for OLPCs to add it during the 11.2.0 window but I think we can do it for 11.3.0. Regards, Simon [1] http://dev.laptop.org/ticket/10860 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Display build number at Name Page
On Thu, Jun 16, 2011 at 09:12:26AM +0200, Simon Schampijer wrote: thanks for your patch. I would like to add the build information to the startup screen [1]. This gives you the information earlier when booting and does not only give you the information the first time. Good, but Esteban's idea is better, since the laptops stop at the name page, not at the startup screen. When a large quantity of laptops are being installed, the startup screen would be difficult to intercept. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Fix for first undo, undo/redo mechanism refactored
---
Area.py | 114 ++
1 files changed, 41 insertions(+), 73 deletions(-)
diff --git a/Area.py b/Area.py
index 5011fd3..71ef6aa 100644
--- a/Area.py
+++ b/Area.py
@@ -177,16 +177,9 @@ class Area(gtk.DrawingArea):
self._set_selection_bounds(0, 0, 0, 0)
-#start of UNDO and REDO
-## This flag is used when is the first time you click on Undo
-self.first_undo = True
-## When you are just clicking on undo or redo and not
-# drawing undo_surf is True
-self.undo_surf = False
-self.undo_times = 0
-self.redo_times = 0
-##pixmaps list to Undo func
+# List of pixmaps for the Undo function:
self.undo_list = []
+self.undo_index = None
# variables to show the tool shape
self.drawing = False
@@ -197,6 +190,7 @@ class Area(gtk.DrawingArea):
Configure the Area object.
if self.pixmap:
+# Already set up
return
logging.debug('Area.setup: w=%s h=%s' % (width, height))
@@ -244,7 +238,7 @@ class Area(gtk.DrawingArea):
gtk.gdk.CAP_ROUND, gtk.gdk.JOIN_ROUND)
self.gc_selection1.set_foreground(self.white)
-self.enableUndo(self)
+self.enableUndo(self, size=(width, height))
# Setting a initial tool
self.set_tool(self.tool)
@@ -711,27 +705,15 @@ class Area(gtk.DrawingArea):
logging.debug('Area.undo(self)')
width, height = self.window.get_size()
-# if is the first time you click on UNDO
-# (because undo_list always wait for the NEXT image)
-if self.first_undo:
-self.undo_times -= 1
-
-#print Undo no.%d %(self.undo_times)
-if self.undo_times 0:
-self.undo_times -= 1
-self.redo_times += 1
-try: # to not try paint someting wrong
-self.pixmap.draw_drawable(self.gc,
-self.undo_list[self.undo_times], 0, 0, 0, 0, width, height)
-except:
-logging.debug('Cant draw')
-pass
-self.queue_draw()
-else:
-self.undo_times = 0
+if self.undo_index == 0:
+# first undo:
+pass
+elif self.undo_index 0:
+self.undo_index -= 1
-self.first_undo = False
-self.undo_surf = True
+undo_pix = self.undo_list[self.undo_index]
+self.pixmap.draw_drawable(self.gc, undo_pix, 0, 0, 0, 0, width, height)
+self.queue_draw()
#special case for func polygon
if self.tool['name'] == 'freeform':
@@ -747,50 +729,47 @@ class Area(gtk.DrawingArea):
logging.debug('Area.redo(self)')
width, height = self.window.get_size()
-#print REDO no.%d %(self.redo_times)
-if self.redo_times 0:
-self.redo_times -= 1
-self.undo_times += 1
+if self.undo_index len(self.undo_list)-1:
+self.undo_index += 1
-try: # to not try paint someting wrong
-self.pixmap.draw_drawable(self.gc,
-self.undo_list[self.undo_times], 0, 0, 0, 0,
-width, height)
-except:
-logging.debug('Cant draw')
-self.undo_times -= 1
+undo_pix = self.undo_list[self.undo_index]
+self.pixmap.draw_drawable(self.gc, undo_pix, 0, 0, 0, 0, width, height)
self.queue_draw()
self.emit('redo')
-def enableUndo(self, widget):
+def enableUndo(self, widget, size=None):
Keep the last change in a list for Undo/Redo commands.
@param self -- the Area object (GtkDrawingArea)
@param widget -- the Area object (GtkDrawingArea)
-#logging.debug('Area.enableUndo(self,widget)')
+logging.debug('Area.enableUndo(self,widget)')
width, height = self.window.get_size()
-
-if self.undo_surf:
-self.undo_times += 1
-
-self.undo_list.append(None) # alloc memory
-self.undo_list[self.undo_times] = gtk.gdk.Pixmap(widget.window,
-width, height, -1) # define type
-self.undo_list[self.undo_times].draw_drawable(self.gc, self.pixmap,
-0, 0, 0, 0, width, height) # copy workarea
-self.undo_times += 1
-self.redo_times = 0
-self.first_undo = True
-self.undo_surf = False
-
-#This is the part where we can limit the steps of undo/redo
-if self.undo_times == 12:
+# We need to pass explicitly the size on set up, because the
+# window size is not allocated yet.
+if size is not None:
+width, height = size
+
+if len(self.undo_list) == 0:
+# first_undo:
+self.undo_index = 0
+elif len(self.undo_list) == 12:
+#This is the part where we can limit the
Re: [Sugar-devel] [PATCH] Fix for first undo, undo/redo mechanism refactored
This is for Paint activity, ticket #10771
http://dev.laptop.org/ticket/10771
I still have to learn git send-email :/
Regards,
El día 16 de junio de 2011 09:03, Manuel Quiñones ma...@laptop.org escribió:
---
Area.py | 114 ++
1 files changed, 41 insertions(+), 73 deletions(-)
diff --git a/Area.py b/Area.py
index 5011fd3..71ef6aa 100644
--- a/Area.py
+++ b/Area.py
@@ -177,16 +177,9 @@ class Area(gtk.DrawingArea):
self._set_selection_bounds(0, 0, 0, 0)
- #start of UNDO and REDO
- ## This flag is used when is the first time you click on Undo
- self.first_undo = True
- ## When you are just clicking on undo or redo and not
- # drawing undo_surf is True
- self.undo_surf = False
- self.undo_times = 0
- self.redo_times = 0
- ##pixmaps list to Undo func
+ # List of pixmaps for the Undo function:
self.undo_list = []
+ self.undo_index = None
# variables to show the tool shape
self.drawing = False
@@ -197,6 +190,7 @@ class Area(gtk.DrawingArea):
Configure the Area object.
if self.pixmap:
+ # Already set up
return
logging.debug('Area.setup: w=%s h=%s' % (width, height))
@@ -244,7 +238,7 @@ class Area(gtk.DrawingArea):
gtk.gdk.CAP_ROUND, gtk.gdk.JOIN_ROUND)
self.gc_selection1.set_foreground(self.white)
- self.enableUndo(self)
+ self.enableUndo(self, size=(width, height))
# Setting a initial tool
self.set_tool(self.tool)
@@ -711,27 +705,15 @@ class Area(gtk.DrawingArea):
logging.debug('Area.undo(self)')
width, height = self.window.get_size()
- # if is the first time you click on UNDO
- # (because undo_list always wait for the NEXT image)
- if self.first_undo:
- self.undo_times -= 1
-
- #print Undo no.%d %(self.undo_times)
- if self.undo_times 0:
- self.undo_times -= 1
- self.redo_times += 1
- try: # to not try paint someting wrong
- self.pixmap.draw_drawable(self.gc,
- self.undo_list[self.undo_times], 0, 0, 0, 0, width,
height)
- except:
- logging.debug('Cant draw')
- pass
- self.queue_draw()
- else:
- self.undo_times = 0
+ if self.undo_index == 0:
+ # first undo:
+ pass
+ elif self.undo_index 0:
+ self.undo_index -= 1
- self.first_undo = False
- self.undo_surf = True
+ undo_pix = self.undo_list[self.undo_index]
+ self.pixmap.draw_drawable(self.gc, undo_pix, 0, 0, 0, 0, width,
height)
+ self.queue_draw()
#special case for func polygon
if self.tool['name'] == 'freeform':
@@ -747,50 +729,47 @@ class Area(gtk.DrawingArea):
logging.debug('Area.redo(self)')
width, height = self.window.get_size()
- #print REDO no.%d %(self.redo_times)
- if self.redo_times 0:
- self.redo_times -= 1
- self.undo_times += 1
+ if self.undo_index len(self.undo_list)-1:
+ self.undo_index += 1
- try: # to not try paint someting wrong
- self.pixmap.draw_drawable(self.gc,
- self.undo_list[self.undo_times], 0, 0, 0, 0,
- width, height)
- except:
- logging.debug('Cant draw')
- self.undo_times -= 1
+ undo_pix = self.undo_list[self.undo_index]
+ self.pixmap.draw_drawable(self.gc, undo_pix, 0, 0, 0, 0, width,
height)
self.queue_draw()
self.emit('redo')
- def enableUndo(self, widget):
+ def enableUndo(self, widget, size=None):
Keep the last change in a list for Undo/Redo commands.
@param self -- the Area object (GtkDrawingArea)
@param widget -- the Area object (GtkDrawingArea)
- #logging.debug('Area.enableUndo(self,widget)')
+ logging.debug('Area.enableUndo(self,widget)')
width, height = self.window.get_size()
-
- if self.undo_surf:
- self.undo_times += 1
-
- self.undo_list.append(None) # alloc memory
- self.undo_list[self.undo_times] = gtk.gdk.Pixmap(widget.window,
- width, height, -1) # define type
- self.undo_list[self.undo_times].draw_drawable(self.gc, self.pixmap,
- 0, 0, 0, 0, width, height) # copy workarea
- self.undo_times += 1
- self.redo_times = 0
- self.first_undo = True
- self.undo_surf = False
-
- #This is the part where we can limit the steps of undo/redo
- if self.undo_times == 12:
+ # We need to pass explicitly the size on set up, because the
+ # window
[Sugar-devel] [PATCH] Use 'focus-out' event instead of 'changed' event for title entry
Hi, the patch does fix the bug where the cursor moves to the beginning of the entry field while trying to edit the activity instance name [1][2]. Daniel and myself have been going through the old discussions and the 0.84 code and came up with two possible solutions [3][4]. Both do work and fullfill the test cases mentioned in the d.l.o ticket [5]. Both have down and upsides, either adding API [4], or having to find the title entry in a complex loop in order to scope for the different available toolbar solutions (old style/new style/sub-toolbar) [3]. Sascha, would be great if you have a quick look which approach you like better and then we can send it for full review. Regards, Simon [1] http://dev.laptop.org/ticket/10956 [2] http://bugs.sugarlabs.org/ticket/2608 [3] http://dev.laptop.org/attachment/ticket/10956/focus_out.patch [4] http://dev.laptop.org/attachment/ticket/10956/focus_out_closing_signal.patch [5] http://dev.laptop.org/ticket/10956#comment:4 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Browse: Set and restore index in the history - Fix OLPC #10779 / SL #2499
Thanks Rafael Gonzalo On Wed, Jun 15, 2011 at 1:31 PM, Rafael Ortiz raf...@activitycentral.comwrote: On Wed, Jun 15, 2011 at 7:01 AM, Gonzalo Odiard godi...@gmail.com wrote: Any of the Browse developers is interested in review this patch? Thanks I'm not a Browse developer but I've tested this change and works for me. btw I also tested with your cairo modification on sugar-0.88/sweets for multitabs (should be in another patch) but must be added also. Cheers Gonzalo ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Turtle Blocks-110
Activity Homepage: http://activities.sugarlabs.org/addon/4027 Sugar Platform: 0.82 - 0.92 Download Now: http://activities.sugarlabs.org/downloads/file/27423/turtle_art-110.xo Release notes: 110 BUG FIX * Fixed regression problem with brightness block 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] [PATCH] Fix for first undo, undo/redo mechanism refactored
Thanks Manu,
I did a few comments in the ticket.
Gonzalo
2011/6/16 manuel quiñones manuel.por@gmail.com
This is for Paint activity, ticket #10771
http://dev.laptop.org/ticket/10771
I still have to learn git send-email :/
Regards,
El día 16 de junio de 2011 09:03, Manuel Quiñones ma...@laptop.org
escribió:
---
Area.py | 114
++
1 files changed, 41 insertions(+), 73 deletions(-)
diff --git a/Area.py b/Area.py
index 5011fd3..71ef6aa 100644
--- a/Area.py
+++ b/Area.py
@@ -177,16 +177,9 @@ class Area(gtk.DrawingArea):
self._set_selection_bounds(0, 0, 0, 0)
-#start of UNDO and REDO
-## This flag is used when is the first time you click on Undo
-self.first_undo = True
-## When you are just clicking on undo or redo and not
-# drawing undo_surf is True
-self.undo_surf = False
-self.undo_times = 0
-self.redo_times = 0
-##pixmaps list to Undo func
+# List of pixmaps for the Undo function:
self.undo_list = []
+self.undo_index = None
# variables to show the tool shape
self.drawing = False
@@ -197,6 +190,7 @@ class Area(gtk.DrawingArea):
Configure the Area object.
if self.pixmap:
+# Already set up
return
logging.debug('Area.setup: w=%s h=%s' % (width, height))
@@ -244,7 +238,7 @@ class Area(gtk.DrawingArea):
gtk.gdk.CAP_ROUND, gtk.gdk.JOIN_ROUND)
self.gc_selection1.set_foreground(self.white)
-self.enableUndo(self)
+self.enableUndo(self, size=(width, height))
# Setting a initial tool
self.set_tool(self.tool)
@@ -711,27 +705,15 @@ class Area(gtk.DrawingArea):
logging.debug('Area.undo(self)')
width, height = self.window.get_size()
-# if is the first time you click on UNDO
-# (because undo_list always wait for the NEXT image)
-if self.first_undo:
-self.undo_times -= 1
-
-#print Undo no.%d %(self.undo_times)
-if self.undo_times 0:
-self.undo_times -= 1
-self.redo_times += 1
-try: # to not try paint someting wrong
-self.pixmap.draw_drawable(self.gc,
-self.undo_list[self.undo_times], 0, 0, 0, 0, width,
height)
-except:
-logging.debug('Cant draw')
-pass
-self.queue_draw()
-else:
-self.undo_times = 0
+if self.undo_index == 0:
+# first undo:
+pass
+elif self.undo_index 0:
+self.undo_index -= 1
-self.first_undo = False
-self.undo_surf = True
+undo_pix = self.undo_list[self.undo_index]
+self.pixmap.draw_drawable(self.gc, undo_pix, 0, 0, 0, 0, width,
height)
+self.queue_draw()
#special case for func polygon
if self.tool['name'] == 'freeform':
@@ -747,50 +729,47 @@ class Area(gtk.DrawingArea):
logging.debug('Area.redo(self)')
width, height = self.window.get_size()
-#print REDO no.%d %(self.redo_times)
-if self.redo_times 0:
-self.redo_times -= 1
-self.undo_times += 1
+if self.undo_index len(self.undo_list)-1:
+self.undo_index += 1
-try: # to not try paint someting wrong
-self.pixmap.draw_drawable(self.gc,
-self.undo_list[self.undo_times], 0, 0, 0, 0,
-width, height)
-except:
-logging.debug('Cant draw')
-self.undo_times -= 1
+undo_pix = self.undo_list[self.undo_index]
+self.pixmap.draw_drawable(self.gc, undo_pix, 0, 0, 0, 0, width,
height)
self.queue_draw()
self.emit('redo')
-def enableUndo(self, widget):
+def enableUndo(self, widget, size=None):
Keep the last change in a list for Undo/Redo commands.
@param self -- the Area object (GtkDrawingArea)
@param widget -- the Area object (GtkDrawingArea)
-#logging.debug('Area.enableUndo(self,widget)')
+logging.debug('Area.enableUndo(self,widget)')
width, height = self.window.get_size()
-
-if self.undo_surf:
-self.undo_times += 1
-
-self.undo_list.append(None) # alloc memory
-self.undo_list[self.undo_times] = gtk.gdk.Pixmap(widget.window,
-width, height, -1) # define type
-self.undo_list[self.undo_times].draw_drawable(self.gc,
self.pixmap,
-0, 0, 0, 0, width, height) # copy workarea
-self.undo_times += 1
-self.redo_times = 0
-
Re: [Sugar-devel] Fw: [Csnd] Default Scons build and backward compatibility (Csound/Fedora15)
I too can verify that without ethernet connection there are no activities-not-starting issues at all. Indeed, just about everything seems a bit snappier. Now if the latest (audio) Records only worked with Fedora15. (For me, the activity seems to record, but plays back a silent file. Then, too, it seems confused as to whether the format is Ogg Speex or Ogg Vorbis.) Art Hunkins - Original Message - From: Peter Robinson To: Art Hunkins Cc: sugar-devel@lists.sugarlabs.org Sent: Wednesday, June 15, 2011 4:05 PM Subject: Re: Fw: [Csnd] Default Scons build and backward compatibility (Csound/Fedora15) Hey Art, AWESOME on the csound. On the Activities I've encountered similar results. Cheers, Peter On Wed, Jun 15, 2011 at 8:56 PM, Art Hunkins abhun...@uncg.edu wrote: Peter - Great news - your new Csound modules work *perfectly*. FWIW, perfectly includes not only the crucial old-parser default, but also MIDI and multiple-controller MIDI. (I hadn't suspected problems with these latter two items, but thought I'd mention them anyway.) In any case, my Csound-based activities run fine now without modification, and the new Fedora 15 SoaS release will be backwardly compatible as far as Csound (and Csound-python) is concerned. BTW, I've a little hint about the activities not opening phenomenon. Though often (usually?) they do not open the first time they are selected, if they are selected *again* immediately, they always do open. (Or so it seems.) Thanks again for all your help and forbearance with Csound. Art Hunkins - Original Message - From: Peter Robinson To: Art Hunkins Sent: Wednesday, June 15, 2011 3:09 AM Subject: Re: Fw: [Csnd] Default Scons build and backward compatibility easiest will be rpm -Uvh http://kojipkgs.fedoraproject.org/packages/csound/5.13.0/5.fc15/i686/csound-5.13.0-5.fc15.i686.rpm http://kojipkgs.fedoraproject.org/packages/csound/5.13.0/5.fc15/i686/csound-python-5.13.0-5.fc15.i686.rpm; Peter On Wed, Jun 15, 2011 at 4:51 AM, Art Hunkins abhun...@uncg.edu wrote: Thanks, Peter. I'll try this out tomorrow. Do I upgrade simply with: yum upgrade csound ? Art Hunkins - Original Message -h From: Peter Robinson To: Art Hunkins Sent: Tuesday, June 14, 2011 7:06 PM Subject: Re: Fw: [Csnd] Default Scons build and backward compatibility https://admin.fedoraproject.org/updates/csound-5.13.0-5.fc15 On Tue, Jun 14, 2011 at 10:42 PM, Peter Robinson pbrobin...@gmail.com wrote: Hmm. We'll see how we get on. Build csound-5.13.0-5.fc15 will have the change in it. It will be submitted as an update shortly. Peter On Tue, Jun 14, 2011 at 9:52 PM, Art Hunkins abhun...@uncg.edu wrote: Peter, FYI (another response). Felipe is the Debian maintainer for Csound. He's quite active and knowledgeable about Csound (and has followed it over a period of time), FWIW. bmity Art Hunkins - Original Message - From: Felipe Sateler fsate...@gmail.com To: cso...@lists.bath.ac.uk Sent: Tuesday, June 14, 2011 4:32 PM Subject: Re: [Csnd] Default Scons build and backward compatibility I agree with most of your comments but... On Tue, Jun 14, 2011 at 13:02, Art Hunkins abhun...@uncg.edu wrote: Everyone knows I'm a Windows person, and normally wouldn't be affected by such largely Linux issues. However, I am involved with the Fedora-based Sugar-on-a-Stick project. A new release is about to come out, and Csound has been built with default Scons options, resulting in its being incompatible with the Activities I've written, as well as with all previous Sugar-on-a-Stick releases. This is a problem that shouldn't be. This is really a problem that shouldn't be, but not for the reasons you argue. The csound maintainer in fedora should be specifying all the features he wants and disabling all that he doesn't. Leaving the build script to do whatever it feels like is wrong. At the very least, the default Scons script should indicate clearly the meaning of each option, and *in giant red letters/flags* (or the equivalent) indicate experimental and untested features. Then by all means, make a safe and compatible default build. Am I way off base? Please let me know what I'm missing. This is my opinion only, but relying on defaults is the wrong way to build software.
Re: [Sugar-devel] [IAEP] 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. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Olidata computers in Uruguay
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
