[Sugar-devel] [PATCH] TurtleArt - escaping HTML entities while exporting to HTML #sl1854
This patch attempts to fix http://bugs.sugarlabs.org/ticket/1854. It assumes that the only place where , , could enter the file in a troublesome manner is when the TurtleArt code is being imported into the content div. Author: Tim McNamara paperl...@timmcnamara.co.nz Date: Sat Jul 3 19:00:34 2010 +1200 HTML chars escaped in TA code , , This commit utilises cgi.escape to escape troublesome HTML entities. The only place where this function is called is when the Turtleart code is being extracted and presented in a div. The SVG input is assumed to be clean - escaping those chars would result in the XML text being rendered rather than the image. diff --git a/taexporthtml.py b/taexporthtml.py index 5a0d163..47577f0 100644 --- a/taexporthtml.py +++ b/taexporthtml.py @@ -24,6 +24,7 @@ import gtk import os.path from tautils import data_to_string, save_picture, image_to_base64 from gettext import gettext as _ +from cgi import escape def save_html(self, tw, embed_flag=True): Either: Save canvas and code or pictures to HTML @@ -114,7 +115,7 @@ def save_html(self, tw, embed_flag=True): code += (self.html_glue['img'][0] + imgdata + \ self.html_glue['img'][1]) code += self.html_glue['div'][0] -code += data_to_string(tw.assemble_data_to_save(False, True)) +code += escape(data_to_string(tw.assemble_data_to_save(False, True))) code += self.html_glue['div'][1] if tw.running_sugar: ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Setting Palette delay timing
Hi all, I'm reading http://bugs.sugarlabs.org/ticket/1169, which talks about the delay of GTK Palettes/drop down menus. I think this is a worthy bug to squash, but I'm not really sure where to start. Given that this has been high/critical priority since 0.86, I'm assuming that it's harder than the sugar-love status it has been triaged as. Noting that there probably isn't a global setting, how is the delay animation established? If there is a global toggle/setting, let's get on to increasing the perceived responsiveness of these menus. -Tim. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] TurtleArt - escaping HTML entities while exporting to HTML #sl1854
Excerpts from Tim McNamara's message of Sat Jul 03 07:14:01 + 2010: [taexporthtml.py] +from cgi import escape [...] -code += data_to_string(tw.assemble_data_to_save(False, True)) +code += escape(data_to_string(tw.assemble_data_to_save(False, True))) I don't grok the current code 100%, but your change appears to be correct and complete. Reviewed-By: Sascha Silbe sascha-ml-reply-to-201...@silbe.org Sascha -- 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] Clocks on XOs
Excerpts from Hal Murray's message of Sat Jul 03 03:15:38 + 2010: Why aren't we using ntp? ntp is probably overkill for XOs. Besides, who would want to give up that much ram? openntpd uses 390.5 KB on my XO-1 (measured using ps_mem.py after an uptime of 22 days). On top of that, ntpd doesn't get along with power saving mode. I haven't noticed anything odd. Either it's been fixed in the meantime or it was only subtle misbehaviour. Do you have a ticket number or link to a description of the problem that has been experienced before? Sascha -- 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] [PATCH] TurtleArt - escaping HTML entities while exporting to HTML #sl1854
On Sat, Jul 3, 2010 at 3:14 AM, Tim McNamara paperl...@timmcnamara.co.nz wrote: This patch attempts to fix http://bugs.sugarlabs.org/ticket/1854. It assumes that the only place where , , could enter the file in a troublesome manner is when the TurtleArt code is being imported into the content div. Author: Tim McNamara paperl...@timmcnamara.co.nz Date: Sat Jul 3 19:00:34 2010 +1200 HTML chars escaped in TA code , , This commit utilises cgi.escape to escape troublesome HTML entities. The only place where this function is called is when the Turtleart code is being extracted and presented in a div. The SVG input is assumed to be clean - escaping those chars would result in the XML text being rendered rather than the image. diff --git a/taexporthtml.py b/taexporthtml.py index 5a0d163..47577f0 100644 --- a/taexporthtml.py +++ b/taexporthtml.py @@ -24,6 +24,7 @@ import gtk import os.path from tautils import data_to_string, save_picture, image_to_base64 from gettext import gettext as _ +from cgi import escape def save_html(self, tw, embed_flag=True): Either: Save canvas and code or pictures to HTML @@ -114,7 +115,7 @@ def save_html(self, tw, embed_flag=True): code += (self.html_glue['img'][0] + imgdata + \ self.html_glue['img'][1]) code += self.html_glue['div'][0] - code += data_to_string(tw.assemble_data_to_save(False, True)) + code += escape(data_to_string(tw.assemble_data_to_save(False, True))) code += self.html_glue['div'][1] if tw.running_sugar: ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Thanks Tim. I'll include this patch in the next release of TA. -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] TurtleArt - SVG text wrapping #sl1856
Hi Walter, et all,
This patch should go most of the way to fixing the bug. However, I haven't
tested it locally it contains a few assumptions about what the SVG files
look like that that it's processing. I'm also not 100% sure about the
elementtree implementation of ElementTree (am used to lxml). That said, I
would like your feedback about whether you consider this to be an
appropriate way to approach the problem.
diff --git a/taexporthtml.py b/taexporthtml.py
index 5a0d163..daad983 100644
--- a/taexporthtml.py
+++ b/taexporthtml.py
@@ -25,6 +25,78 @@ import os.path
from tautils import data_to_string, save_picture, image_to_base64
from gettext import gettext as _
+try: import xml.etree.cElementTree as ET
+except ImportError:
+try: import cElementTree as ET # python 2.5
+except ImportError:
+try: import lxml.etree as ET
+except ImportError:
+try: import xml.etree.ElementTree as ET
+except ImportError:
+import elementtree.ElementTree as ET
+
+def split_at_len(s, max_len=50, delimiter=None):
+
+Returns a list of strings, that are split from an
+input string. Delimits on whitespace by default.
+
+if delimiter is None:
+s = s.split()
+else:
+s = s.split(delimiter)
+
+lines = []
+current_line = ''
+for word in s:
+if len(current_line) = max_len:
+short.append(current_line)
+current_line = word
+else:
+current_line = '%s %s' % (current_line, word);
+lines[0] = lines[0][1:] #hack required by string formatting
+lines.append(current_line)
+return lines
+
+def process_svg_text_element(el, max_len=50, line_height='1.1em'):
+
+Turns
+ textlong ... content/text
+into
+ text
+tspanlong/tspantspan.../tspantspancontent/tspan
+ /text
+
+# NOTE Assumes that there are no subelements this
+# should be safe because TurtleArt shouldn't
+# generate any
+data = split_at_len(el.text, max_len=max_len)
+
+for line in data:
+ET.SubElement(el, 'tspan')
+
+i = 0
+while i len(data):
+el[i].text = data[i]
+el[i].attrib['dy'] = (i*line_height)
+i = i+1
+return el
+
+def process_text_in_svg(svg, max_len=50, line_height='1.1em'):
+
+Takes an SVG as a string or file-like object
+and returns a string with text elements split
+into multiple lines surrounded by tspan.
+
+tree = ET.parse(svg)
+svg_text = tree.findall('text')
+if len(svg_text) 0:
+for el in svg_text:
+# TODO check if this actually replaces the element in tree
+el = process_svg_text_element(el,
+ max_len=max_len,
+ line_height=line_height)
+return ET.tostring(tree)
+
def save_html(self, tw, embed_flag=True):
Either: Save canvas and code or pictures to HTML
self.embed_images = embed_flag
@@ -85,7 +157,7 @@ def save_html(self, tw, embed_flag=True):
imgdata = f.read()
f.close()
if p.endswith(('.svg')):
-tmp = imgdata
+tmp = process_text_in_svg(imgdata)
else:
pixbuf = gtk.gdk.pixbuf_new_from_file(p)
imgdata = image_to_base64(pixbuf, tw.activity)
@@ -97,7 +169,7 @@ def save_html(self, tw, embed_flag=True):
f = open(p, r)
imgdata = f.read()
f.close()
-tmp = imgdata
+tmp = process_text_in_svg(imgdata)
else:
tmp = self.html_glue['img3'][0]
tmp += p
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] fixes sl#2062
On 2 July 2010 20:42, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.orgwrote:
TypeError should be catched in
jarabe.desktop.schoolserver.register_laptop()
and rethrown as a RegisterError.
Sascha
diff --git a/src/jarabe/desktop/schoolserver.py
b/src/jarabe/desktop/schoolserver.py
index fc9ddeb..a05f56c 100644
--- a/src/jarabe/desktop/schoolserver.py
+++ b/src/jarabe/desktop/schoolserver.py
@@ -99,7 +99,7 @@ def register_laptop(url=REGISTER_URL):
server = ServerProxy(url)
try:
data = server.register(sn, nick, uuid_, profile.pubkey)
-except (Error, socket.error):
+except (Error, TypeError, socket.error):
logging.exception('Registration: cannot connect to server')
raise RegisterError(_('Cannot connect to the server.'))
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Schoolserver security
El Thu, 01-07-2010 a las 20:55 -0600, Daniel Drake escribió: Child connects to a network, perhaps just to go online outside of school. The network has an XS. The laptop registers. The journal is backed up to the server. Ok, this is a serious security issue. How about asking the user to confirm registration to an unknown server, like ssh does? For slightly improved security, we could hash the ssh fingerprint to a color pair, so the teacher could say your schoolserver is blue and red, don't register to any other. Sadly, adding this UI requirement means that this feature won't be ready n time for this release :-( I think the current XO-XS communication is secure enough in the places where it needs to be. But registration indeed is a big problem and it could do with a rethink which would probably involve some kind of key-based auth to achieve the best results in terms of user experience. Well, communication being secure does not help much if the registration step is fatally flawed. Anyone passing nearby a school can make their computer register to the schoolserver with any made up serial number, then steal all journals, fill up the hard-drive with junk... probably even hijack the schoolserver, as it's a Fedora 9 without security patches, running plenty of scary webapps. We could be plug both this hole and the auto-registration security issue by making laptops receive their private ssh keys from the OATS server and distribute the matching public keys to the schoolserver. The same could be done with SSL client and server certificates. Thanks to your earlier work and Inventario, Paraguay already has all the infrastructure in place to do this, but it's kind of demanding for most deployments, especially those without a centralized anti-theft server. Can you think of a simpler scheme to perform mutual authentication. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Activity list favorites view
[cc += sugar-de...@] El Fri, 02-07-2010 a las 05:57 -0500, Mikus Grinbergs escribió: Does this solve the issue? I will apply it tomorrow. --- src/jarabe/desktop/activitieslist.py This change was already in sugar-0.88.1-5.11bernie.fc11 But - which issue are you referring to here? If it is to Home List View being shown oldest first -- that problem is still present, even with sugar-0.88.1-5.11bernie.fc11 installed on top of os284py. Yes, this is the issue I was referring to. I've applied Jorge's patch to sugar-0.88.1-5.12bernie.fc11 and it appears to work. [If by issue you are referring to my 0.88 Home Ring View sometimes showing many many icons (which overlap themselves), one symptom appears to be obsolete activity versions in ~/.sugar/default/favorite_activities -- and I have defensively put favorite_activities reset code in .bashrc The difficulty lies in this issue seeming random - I don't know how to make it occur. I'll take my reset code out, and run for some days with the changed activitieslist.py - and see if my Home Ring View behaves.] I have never seen the issue you describe myself. However, multiple teachers swear that in some cases *ALL* the activities disappear from the activity circle. It's not clear whether they are deleted from the filesystem too. Did anyone ever see this? [If by issue you mean how does 'Software Update' affect the places where activities are listed? - currently I have no back-level activities installed - so I can't check 'Software Update' affects.] -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] fixes sl#2062
Excerpts from Tim McNamara's message of Sat Jul 03 11:49:50 + 2010:
diff --git a/src/jarabe/desktop/schoolserver.py
b/src/jarabe/desktop/schoolserver.py
index fc9ddeb..a05f56c 100644
--- a/src/jarabe/desktop/schoolserver.py
+++ b/src/jarabe/desktop/schoolserver.py
@@ -99,7 +99,7 @@ def register_laptop(url=REGISTER_URL):
server = ServerProxy(url)
try:
data = server.register(sn, nick, uuid_, profile.pubkey)
-except (Error, socket.error):
+except (Error, TypeError, socket.error):
logging.exception('Registration: cannot connect to server')
raise RegisterError(_('Cannot connect to the server.'))
Reviewed-By: Sascha Silbe sascha-...@silbe.org
Thanks!
Sascha
signature.asc
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] fixes sl#2062
El Sat, 03-07-2010 a las 12:41 +, Sascha Silbe escribió:
Excerpts from Tim McNamara's message of Sat Jul 03 11:49:50 + 2010:
diff --git a/src/jarabe/desktop/schoolserver.py
b/src/jarabe/desktop/schoolserver.py
index fc9ddeb..a05f56c 100644
--- a/src/jarabe/desktop/schoolserver.py
+++ b/src/jarabe/desktop/schoolserver.py
@@ -99,7 +99,7 @@ def register_laptop(url=REGISTER_URL):
server = ServerProxy(url)
try:
data = server.register(sn, nick, uuid_, profile.pubkey)
-except (Error, socket.error):
+except (Error, TypeError, socket.error):
logging.exception('Registration: cannot connect to server')
raise RegisterError(_('Cannot connect to the server.'))
Reviewed-By: Sascha Silbe sascha-...@silbe.org
Tim, thank you very much for fixing this. I would like to include your
fix in my Sugar 0.88 packages. Could you please repost the complete
patch with this amendment included? (git commit --amend makes it easy)
Also, could you look into these related bugs?
http://bugs.sugarlabs.org/ticket/1940
http://bugs.sugarlabs.org/ticket/1977
http://bugs.sugarlabs.org/ticket/1976
I'm trying to spread idea of letting children and teachers upgrade their
laptops without relying on technicians to do it. To lower the barrier,
it's important to make the Register procedure free of quirks.
--
// Bernie Innocenti - http://codewiz.org/
\X/ Sugar Labs - http://sugarlabs.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] fixes sl#2062
Excerpts from Bernie Innocenti's message of Sat Jul 03 13:32:44 + 2010: -except (Error, socket.error): +except (Error, TypeError, socket.error): Tim, thank you very much for fixing this. I would like to include your fix in my Sugar 0.88 packages. Could you please repost the complete patch with this amendment included? (git commit --amend makes it easy) This _is_ the complete patch. :D FTR, this was my reasoning for amending the existing except block instead of adding a new one: 2010-07-02 13:53:27 silbe timClicks: to me it's always just a failure to connect to the server. I'm not sure TypeError always implies lack of a network connection and other errors imply there's a network connection (but a different error occured), so I'd just always present the same message (and maybe change it to hint at establishing a network connection). But since you might know better I thought I'd ask first. Sascha signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Clocks on XOs
El Fri, 02-07-2010 a las 20:15 -0700, Hal Murray escribió: Is that one of the old XOs that had troubles with the tiny battery feeding the TOY/RTC clock when the main battery and wall power are both disconnected? I forget the details, but I think there was a problem with the battery holder. Likely so, but the software should be able to compensate for it. After discussing it on IRC, it seems that olpc-update-query should automatically update the clock from the OATS server. NetworkManager used to call ntpdate when it setup a connection. Was that an OLPC addition? We figured out that the ntp package has never been present on the XO images. I think this area gets tangled up with security and lease checking. Do we want/need two separate modes, one for the secure case and another for developers without a school server? Maybe. We discussed the security implications of using unauthenticated ntp on XOs with anti-theft enabled yesterday on IRC. The concern is that a clever thief could setup a LAN with DHCP, DNS and NTP to set a date in te past and thus subvert the leases expiration scheme. However, with root access on the laptop, one does not need to bother so much: they could simply change the time from the console or, better, in /etc/rc.local. There's no way to practical way to implement effective anti-theft without taking away root from the user. And once we take away root access, we've also taken away olpc's principle #1: child ownership. What are the school servers doing to keep their clocks reasonable? They're using ntp, with the Fedora pool of ntp servers. Why aren't we using ntp? ntp is probably overkill for XOs. Besides, who would want to give up that much ram? On top of that, ntpd doesn't get along with power saving mode. Wow, 2MB of RSS! I had no idea ntp was such a hog. Aside from quirks like this one, is time on the XO normally good enough? I would have to check... -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] MANIFEST pointlessness
El Fri, 02-07-2010 a las 15:54 +1000, James Cameron escribió: A fascinating meaning of the word MANIFEST that I had not previously encountered. That sounds like an INVENTORY. What's the point of a file that is automatically generated? None, this is why I removed it. IIRC, the original plan was to make the MANIFEST contain hashes, so it could be used for integrity checking and to update activities by downloading only deltas. In 3 years, nobody ever got around to implement any of these advanced features... And in case anyone ever did, the current MANIFEST format would have to be redesigned anyway. To simplify the life of activity authors, we should simply remove any mention of it from the documentation and maybe teach setup.py to generate bundles out of git ls-files. Meanwhile, SoaS, USR and the new ARM-based XO laptop are pressing hard for switching from xo bundles to a full-featured packaging system, which would also solve the problem that the MANIFEST was supposed to address. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Journal:show error message on write failure: #1842
Excerpts from anishmangal2002's message of Fri Jul 02 19:25:56 + 2010:
After this patch, the information flow will be the following:
* model.copy throws *Error
* BaseButton emits volume-error (strerror)
* VolumesToolbar emits volume-error (strerror)
* JournalActivity instantiates NotifyAlert
This looks a bit convoluted to me, but I don't know whether there's a
better way.
[src/jarabe/journal/journalactivity.py]
+def _alert_notify_cb(self, gobject, strerror, severity):
+alert = ErrorAlert()
+alert.props.title= severity
+alert.props.msg = strerror
Please consider passing these directly to the constructor.
@@ -161,6 +175,8 @@ class JournalActivity(Window):
self._volumes_toolbar = VolumesToolbar()
self._volumes_toolbar.connect('volume-changed',
self.__volume_changed_cb)
+self._volumes_toolbar.connect('volume-error', self._alert_notify_cb,
+ 'Error')
Why do you add an additional parameter ('Error')? AFAICT all signal
handlers should pass through strerror.
[src/jarabe/journal/volumestoolbar.py]
@@ -137,7 +150,14 @@ class BaseButton(RadioToolButton):
info, timestamp):
object_id = selection_data.data
metadata = model.get(object_id)
-model.copy(metadata, self.mount_point)
+try:
+model.copy(metadata, self.mount_point)
+except IOError as (errno, strerror):
Please don't use the except ... as ... syntax. It has been introduced in Python
2.6, but we still support 2.5.
+logging.error('BaseButton._drag_data_received_cb: IOError: %s;
%s' % (errno, strerror))
If you leave the exception intact while catching it (i.e. except IOError,
exception:), it will do most of the formatting for you. You might even get
below the 80 character line length limit this way. ;)
+except ValueError as (strerror):
In what cases does model.copy() throw a ValueError? This sounds more like an
internal error we should avoid...
If it does make sense to catch this here, please combine the two except blocks
(which will be possible after the logging change mentioned above).
Sascha
--
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] [PATCH] Journal Volumes Backup and Restore
A few screenshots of the actual work. Please, if there is some other text I should add or change let me know. http://img25.imageshack.us/i/screenshotlym.png/ http://img41.imageshack.us/i/screenshot1dk.png/ http://img534.imageshack.us/i/screenshot2wl.png/ http://img37.imageshack.us/i/screenshot3cfv.png/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Clocks on XOs
On Fri, Jul 02, 2010 at 08:15:38PM -0700, Hal Murray wrote: Was: Subject: =?ISO-8859-1?Q?Caacup=E9?= war bullettin -- day 1 ber...@codewiz.org said: * Date not being updated One laptop booted with clock set to the Epoch. Is that one of the old XOs that had troubles with the tiny battery feeding the TOY/RTC clock when the main battery and wall power are both disconnected? I forget the details, but I think there was a problem with the battery holder. the 'd6 bricking' has 2 common symptoms: the laptop boots with a dark screen and the mic light flashes and never goes further or the laptop boots with a message about an invalid date and goes no further. That is for non-lease-bound XOs. The lease complicates this as because when you have to re-image the laptop, you need to get a lease file onto the laptop to activate the laptop. See: http://wiki.laptop.org/go/Fix_Clock (let me know if you want to add a spanish translation) cheers, Kev -- | .''`. == Debian GNU/Linux ==.| http://kevix.myopenid.com..| | : :' : The Universal OS| mysite.verizon.net/kevin.mark/.| | `. `' http://www.debian.org/.| http://counter.li.org [#238656]| |___`-Unless I ask to be CCd,.assume I am subscribed._| ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] TurtleArt - SVG text wrapping #sl1856
On Sat, Jul 3, 2010 at 7:44 AM, Tim McNamara
paperl...@timmcnamara.co.nz wrote:
Hi Walter, et all,
This patch should go most of the way to fixing the bug. However, I haven't
tested it locally it contains a few assumptions about what the SVG files
look like that that it's processing. I'm also not 100% sure about the
elementtree implementation of ElementTree (am used to lxml). That said, I
would like your feedback about whether you consider this to be an
appropriate way to approach the problem.
I don't know much about ElementTree, but the patch itself looks OK.
What I don't understand is how the textbox width is determined. How do
we know how long to make the strings?
-walter
diff --git a/taexporthtml.py b/taexporthtml.py
index 5a0d163..daad983 100644
--- a/taexporthtml.py
+++ b/taexporthtml.py
@@ -25,6 +25,78 @@ import os.path
from tautils import data_to_string, save_picture, image_to_base64
from gettext import gettext as _
+try: import xml.etree.cElementTree as ET
+except ImportError:
+ try: import cElementTree as ET # python 2.5
+ except ImportError:
+ try: import lxml.etree as ET
+ except ImportError:
+ try: import xml.etree.ElementTree as ET
+ except ImportError:
+ import elementtree.ElementTree as ET
+
+def split_at_len(s, max_len=50, delimiter=None):
+
+ Returns a list of strings, that are split from an
+ input string. Delimits on whitespace by default.
+
+ if delimiter is None:
+ s = s.split()
+ else:
+ s = s.split(delimiter)
+
+ lines = []
+ current_line = ''
+ for word in s:
+ if len(current_line) = max_len:
+ short.append(current_line)
+ current_line = word
+ else:
+ current_line = '%s %s' % (current_line, word);
+ lines[0] = lines[0][1:] #hack required by string formatting
+ lines.append(current_line)
+ return lines
+
+def process_svg_text_element(el, max_len=50, line_height='1.1em'):
+
+ Turns
+ textlong ... content/text
+ into
+ text
+ tspanlong/tspantspan.../tspantspancontent/tspan
+ /text
+
+ # NOTE Assumes that there are no subelements this
+ # should be safe because TurtleArt shouldn't
+ # generate any
+ data = split_at_len(el.text, max_len=max_len)
+
+ for line in data:
+ ET.SubElement(el, 'tspan')
+
+ i = 0
+ while i len(data):
+ el[i].text = data[i]
+ el[i].attrib['dy'] = (i*line_height)
+ i = i+1
+ return el
+
+def process_text_in_svg(svg, max_len=50, line_height='1.1em'):
+
+ Takes an SVG as a string or file-like object
+ and returns a string with text elements split
+ into multiple lines surrounded by tspan.
+
+ tree = ET.parse(svg)
+ svg_text = tree.findall('text')
+ if len(svg_text) 0:
+ for el in svg_text:
+ # TODO check if this actually replaces the element in tree
+ el = process_svg_text_element(el,
+ max_len=max_len,
+ line_height=line_height)
+ return ET.tostring(tree)
+
def save_html(self, tw, embed_flag=True):
Either: Save canvas and code or pictures to HTML
self.embed_images = embed_flag
@@ -85,7 +157,7 @@ def save_html(self, tw, embed_flag=True):
imgdata = f.read()
f.close()
if p.endswith(('.svg')):
- tmp = imgdata
+ tmp = process_text_in_svg(imgdata)
else:
pixbuf = gtk.gdk.pixbuf_new_from_file(p)
imgdata = image_to_base64(pixbuf, tw.activity)
@@ -97,7 +169,7 @@ def save_html(self, tw, embed_flag=True):
f = open(p, r)
imgdata = f.read()
f.close()
- tmp = imgdata
+ tmp = process_text_in_svg(imgdata)
else:
tmp = self.html_glue['img3'][0]
tmp += p
___
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] Schoolserver icon
On Sat, 3 Jul 2010 03:58:54 +0100, Gary Martin garycmar...@googlemail.com wrote: On 3 Jul 2010, at 03:07, Eben Eliason wrote: Ah, I see now. At first glance at the previous iteration I thought that it was just the stroke of a bell shape; I didn't read the bell within the arch. I do like that idea, actually, but this version does read more clearly. It looks great! I'm not sure if this would be any better or not, but have you tried a solid stroke-color cap on the steeple? You could also widen the steeple a bit to make the bell even larger for clarity. (These are just what ifs, though, not recommendations…it already looks great.) I think I do like the solid steeple cap, certainly it is simpler at least. The steeple tower now seems a little fat/dumpy and un-tower like to my eye (made the steeple a little wider and the bell slightly larger, vertical space is more the limit now on bell size) – though I've likely been staring at the shapes too long now :) :D! Great work, others icons looks amazing too, but personally I like this one better :) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Clocks on XOs
On top of that, ntpd doesn't get along with power saving mode. I haven't noticed anything odd. Either it's been fixed in the meantime or it was only subtle misbehaviour. Do you have a ticket number or link to a description of the problem that has been experienced before? Are you running XO-1s with power saving enabled? Last I knew that didn't work and recent OSes ship with it pre-configured to off. With power saving disabled, ntpd works as expected. doesn't get along may be too strong. The symptoms were that the clock drifted wildly. I'll dig out some data if it matters, but that was with the old kernel from Fedora 9, when power saving worked. I don't have a ticket number. Linux seems to break things when somebody cleans up something in this area. I think there has been more work in this area recently, but it may not be that recent. I'm procrastinating until power saving works again. Clocks are hard. Clocks on XOs are doubly hard because you don't have anyplace to stand when the CPU and its clocks are powered down. -- These are my opinions, not necessarily my employer's. I hate spam. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Journal Volumes Backup and Restore
Hi Martin, On 3 Jul 2010, at 18:13, Martin Abente mabe...@paraguayeduca.org wrote: A few screenshots of the actual work. Thanks for the screen shots! Please, if there is some other text I should add or change let me know. http://img25.imageshack.us/i/screenshotlym.png/ Perhaps, in a future pass, we can make some better icons for the backup/restore menu items, rather than using the upload/download arrow icons; but don't let that block the patch. http://img41.imageshack.us/i/screenshot1dk.png/ Can the dialogue buttons be named Restore/Cancel, and Backup/Cancel for the backup case? http://img534.imageshack.us/i/screenshot2wl.png/ http://img37.imageshack.us/i/screenshot3cfv.png/ Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Clocks on XOs
Excerpts from Hal Murray's message of Sat Jul 03 18:42:48 + 2010: On top of that, ntpd doesn't get along with power saving mode. I haven't noticed anything odd. Either it's been fixed in the meantime or it was only subtle misbehaviour. Do you have a ticket number or link to a description of the problem that has been experienced before? Are you running XO-1s with power saving enabled? Last I knew that didn't work and recent OSes ship with it pre-configured to off. I'm running Debian squeeze with powerd on both XO-1 and XO-1.5 doesn't get along may be too strong. The symptoms were that the clock drifted wildly. Then it seems fixed. I would have noticed a wildly drifting system clock. I'll dig out some data if it matters, but that was with the old kernel from Fedora 9, when power saving worked. This is with the latest OLPC kernel (2.6.31). Linux seems to break things when somebody cleans up something in this area. I think there has been more work in this area recently, but it may not be that recent. I'm procrastinating until power saving works again. Ah, so you're talking about power saving, not clocks (re. cleaning up). Yes, suspend still contains too many race conditions to enable auto-suspend by default unfortunately. But as this is where the embedded world seems to be going as well, there's a good chance this will improve near to medium term. Clocks are hard. Clocks on XOs are doubly hard because you don't have anyplace to stand when the CPU and its clocks are powered down. Unless you happen to hit the bad RTC battery holder problem or don't use your XO for several months, the RTC will always be powered on the XO-1, even if you took the battery out. PS: Follow-Up set to de...@l.l.o as this is about XOs, not Sugar. Sascha signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [sugar-artwork] Revert to GTK_WIDGET_IS_SENSITIVE() macro
El Fri, 02-07-2010 a las 20:46 +0200, Benjamin Berg escribió: Signed-off-by: Bernie Innocenti ber...@codewiz.org Sounds good. We are using some deprecated macros already anyways. Thanks, pushed. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Journal Volumes Backup and Restore
On Sat, 3 Jul 2010 20:53:52 +0100, Gary Martin garycmar...@googlemail.com wrote: Hi Martin, On 3 Jul 2010, at 18:13, Martin Abente mabe...@paraguayeduca.org wrote: A few screenshots of the actual work. Thanks for the screen shots! Please, if there is some other text I should add or change let me know. http://img25.imageshack.us/i/screenshotlym.png/ Perhaps, in a future pass, we can make some better icons for the backup/restore menu items, rather than using the upload/download arrow icons; but don't let that block the patch. http://img41.imageshack.us/i/screenshot1dk.png/ Can the dialogue buttons be named Restore/Cancel, and Backup/Cancel for the backup case? of course :) http://img534.imageshack.us/i/screenshot2wl.png/ http://img37.imageshack.us/i/screenshot3cfv.png/ Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Window borders show up briefly on activity startup
El Fri, 02-07-2010 a las 18:39 +0530, Joshua N Pritikin escribió: I am still seeing Activities sometimes start and remain in window, File:Untitled.jpg screenshot File:TmpxWzNZv.png ; (Window appears at least briefly on all launches) This bug is not fixed. I'm afraid it can't be completely eliminated due to the way Metacity interacts with Sugar to make all applications go full-screen. On the XO-1 the delay is longer than on a faster machine, especially when the CPU is hogged by multiple processes. However, before we had occasionally an activity that would *stay* in window forever. That bug should be fixed. It seems to happen frequently with Gcompris. Yes, I would expect only non-Python activities to do it. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] TurtleArt - SVG text wrapping #sl1856
On 4 July 2010 05:08, Walter Bender walter.ben...@gmail.com wrote: On Sat, Jul 3, 2010 at 7:44 AM, Tim McNamara paperl...@timmcnamara.co.nz wrote: Hi Walter, et all, This patch should go most of the way to fixing the bug. However, I haven't tested it locally it contains a few assumptions about what the SVG files look like that that it's processing. I'm also not 100% sure about the elementtree implementation of ElementTree (am used to lxml). That said, I would like your feedback about whether you consider this to be an appropriate way to approach the problem. I don't know much about ElementTree, but the patch itself looks OK. What I don't understand is how the textbox width is determined. How do we know how long to make the strings? My patch includes the max_len argument twice, for convenience only. process_text_in_svg passes those arguments to process_text_in_svg, which itself passes those arguments to split_at_len. My thought was that it would enable the functions to be accessed externally. Then again, I should use objects if I would like to maintain state like this. As far as how the width is calculated, I've created an arbitrary cut-off at 50 characters. This is used by split_at_len. It would be better to draw an inference about the available space left on the page from the element's x/y position and the height/width of the whole page. However, I consider this patch an intermediate step patch submission as a pit stop to get review comments. Relationship between three functions process_text_in_svg accepts whole SVG file/string, calls process_svg_text_element on text tags, returns SVG as a string process_svg_text_element accepts a list of Element objects, calling split_at_len on their content, returning the Element split_at_len accepts single string, returns list of strings I'll work on an OO implementation on this. It'll add flexibility clarity. -Tim. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Remove hard-coded School Server URL when XOs register #sl1976
Hi there,
Ref http://bugs.sugarlabs.org/ticket/1976
Bevaviour of the software is now independent of the hardware that Sugar is
running. All registrations will look for Jabber server settings from
/desktop/sugar/collaboration/jabber_server. However, this patch retains the
REGISTER_URL as an option for systems administrators. This prevents
currently written documentation for the XS / XO registration from breaking.
Please note, I haven't got an XS to test this on, so am relying on
maintainter to see if this fixes the bug.
-Tim
diff --git a/src/jarabe/desktop/schoolserver.py b/src/jarabe/desktop/schoolserver.py
index fc9ddeb..6a59cb2 100644
--- a/src/jarabe/desktop/schoolserver.py
+++ b/src/jarabe/desktop/schoolserver.py
@@ -29,7 +29,9 @@ import gconf
from sugar import env
from sugar.profile import get_profile
-REGISTER_URL = 'http://schoolserver:8080/'
+REGISTER_URL = ''
+# this setting is depreciated, consider changing XMPP settings
+# in /desktop/sugar/collaboration/jabber_server
def generate_serial_number():
Generates a serial number based on 3 random uppercase letters
@@ -89,10 +91,14 @@ def register_laptop(url=REGISTER_URL):
else:
sn = generate_serial_number()
uuid_ = str(uuid.uuid1())
-setting_name = '/desktop/sugar/collaboration/jabber_server'
-jabber_server = client.get_string(setting_name)
-store_identifiers(sn, uuid_, jabber_server)
+
+setting_name = '/desktop/sugar/collaboration/jabber_server'
+jabber_server = client.get_string(setting_name)
+store_identifiers(sn, uuid_, jabber_server)
+if len(url) == 0:
url = 'http://' + jabber_server + ':8080/'
+else:
+url = url
nick = client.get_string('/desktop/sugar/user/nick')
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Clocks on XOs
El Sat, 03-07-2010 a las 09:54 -0400, Bernie Innocenti escribió: Likely so, but the software should be able to compensate for it. After discussing it on IRC, it seems that olpc-update-query should automatically update the clock from the OATS server. I checked: olpc-update-query only sets the clock if it's off by more than 24hours, so it cannot serve as a replacement for ntpdate. Besides, I can't find where NetworkManager would be running ntpdate... The most logical place would be /etc/NetworkManager/dispatcher.d, but there's nothing. The ntp packate drops a script in /etc/dhcp/dhclient.d, but it seems to kick into action only if the dhcp server provides an ntp server option. My conclusion: currently there's no straight-forward way to set the clock on the XO (even when we don't care about the time hijacking scenario). -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Q on tracker cleanup / triage
Hi devs, 500+ unclosed bugs causes problems. I feel intimidated overwhelmed by this number. I also find it difficult to find material sift through bug reports, to find areas where I can help (although, at the moment, I'm quite content with sugar-love level problems). However, 500+ bugs isn't that accurate. Some have been identified as upstream problems, but their resolution status remains open. I suggest that we make more use of the wontfix resolution status. In 5 minutes, I've found some likely candidates. wontfix comes with a high risk of alienating people submitting bugs, but a polite note saying that it's upstream or possibly something like Unfortunately, we have higher priority areas to work on right now. However we would welcome a patch if you are still wiling to work on this issue. It's great that you've taken the time to submit the bug, and we have looked into resolving things for you. Some candidates: wontfix - upstream http://bugs.sugarlabs.org/ticket/1307 wontfix - other priorities http://bugs.sugarlabs.org/ticket/288 http://bugs.sugarlabs.org/ticket/292 duplicates http://bugs.sugarlabs.org/ticket/172 http://bugs.sugarlabs.org/ticket/394 I think that resolving bugs, even if by using the wontfix tag will make other areas easier. Also, I don't know if I have the permission to change resolution status when something hasn't been touched for 12+ months. If I were to change status on likely candidates, would this anger the other developers? Tim ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] UI experiments: pop-up menus and hot corners
El Fri, 02-07-2010 a las 04:49 -0500, Mikus Grinbergs escribió: sugar-toolkit/kill-the-delayed-menus-for-good.patch I received no comments so far. I'll ask my testers to give an opinion whether they like it more this way after a few days of adjustment. Sounds like something I would have an interest in. What does this do ? It makes menus pop-up immediately instead of after a 2 seconds delay. Ideally, we'd want users to click the right button explicitly, but even if we increase the delay, most users sit and wait patiently for the menu to open automatically. It seems to be a perverse form of laziness :-) In F11-0.88 I have also disabled the hot-corners for the frame. I don't like it, but Tim Falconer asked me to do it at Realness and there was a chorus of approval. They're probably still using the G1G1 crap software with the jumpy touchpad (I fixed it over 2 years ago :-) At some point, I will ask the children and their teachers to comment on these changes. So far nobody said anything: whether they like it or not, it's probably not a very big deal for them. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] StarChart = ASLO
Hello, I was told that that your activity is great. Would you mind uploading it to activities.sugarlabs.org, so users can find it more easily? The wiki.laptop.org site is no longer where Sugar activities reside. Also, if you have time, it would be good it you could migrate the home page to wiki.sugarlabs.org and the code to git.sugarlabs.org. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Q on tracker cleanup / triage
Excerpts from Tim McNamara's message of Sat Jul 03 23:11:42 + 2010: Some have been identified as upstream problems, but their resolution status remains open. That's because they still affect users. Some might need Sugar changes once they have been handled upstream. The current status fields we use in Trac are inconsistent (probably for historic reasons). There's a better way (called Workflow [1]) to handle this now, but so far nobody had time to design a new set of status fields and matching Workflow for our Trac instance. Help in that area would be very welcome - especially if it has a good way of indicating that we are waiting for some other party (reporter, upstream, whatever) to do something. I suggest that we make more use of the wontfix resolution status. I recommend to use wontfix sparingly. It tends to alienate bug reporters (as you mention yourself further down). If it needs fixing in some component other than Sugar and we don't need to do anything once it has been fixed, please file a bug against the other component (i.e. upstream) and set resolution to NOTSUGAR. [...] or possibly something like Unfortunately, we have higher priority areas to work on right now. Never close bugs because nobody has time to fix them. Rather use the priority field to indicate the maintainer isn't interested in working on the issue, but would welcome patches. wontfix - upstream http://bugs.sugarlabs.org/ticket/1307 This isn't a clear one. Yes, Firefox also behaves this way - but that doesn't imply Browse _should_ do it. If we decide we want Browse to be different, there's a good chance we can add some code to achieve that. Mozilla won't change their code to accommodate our UI design decisions. wontfix - other priorities http://bugs.sugarlabs.org/ticket/288 The original request should be easy to handle. Turtle Art (or Turtle Blocks or whatever it's called now, can't remember) already has an icon with a snake that symbolises Python code. http://bugs.sugarlabs.org/ticket/292 #288 evolved into a more generic discussion, which is how to handle related MIME types (sub types, sibling types). #292 was opened to handle this broader issue. We might add a milestone 1.0 (or even after-1.0) to indicate this will need to be fixed eventually, but not right away. duplicates http://bugs.sugarlabs.org/ticket/172 http://bugs.sugarlabs.org/ticket/394 Duplicates are something a bug master would handle (by resolving bugs as duplicate and adding the reporter of the dupe to the CC list of the first filed ticket) if we had one. A bug master also ensures tickets are filed against the correct component and are (apparently) complete. In this particular case however the maintainer himself filed a second bug on purpose, so please don't mark it as duplicate. Also, I don't know if I have the permission to change resolution status when something hasn't been touched for 12+ months. If I were to change status on likely candidates, would this anger the other developers? You're free to handle most bugs in a way that helps resolving them. But I would advise against closing bugs as WONTFIX or similar unless you're sure the maintainer is of the same opinion. Sascha [1] https://bugs.sugarlabs.org/wiki/TracWorkflow -- 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] Q on tracker cleanup / triage
On 4 Jul 2010, at 00:11, Tim McNamara paperl...@timmcnamara.co.nz wrote: Hi devs, 500+ unclosed bugs causes problems. I feel intimidated overwhelmed by this number. I also find it difficult to find material sift through bug reports, to find areas where I can help (although, at the moment, I'm quite content with sugar-love level problems). However, 500+ bugs isn't that accurate. Some have been identified as upstream problems, but their resolution status remains open. I suggest that we make more use of the wontfix resolution status. In 5 minutes, I've found some likely candidates. wontfix comes with a high risk of alienating people submitting bugs, but a polite note saying that it's upstream or possibly something like Unfortunately, we have higher priority areas to work on right now. However we would welcome a patch if you are still wiling to work on this issue. It's great that you've taken the time to submit the bug, and we have looked into resolving things for you. Some candidates: wontfix - upstream http://bugs.sugarlabs.org/ticket/1307 wontfix - other priorities http://bugs.sugarlabs.org/ticket/288 http://bugs.sugarlabs.org/ticket/292 duplicates http://bugs.sugarlabs.org/ticket/172 http://bugs.sugarlabs.org/ticket/394 I think that resolving bugs, even if by using the wontfix tag will make other areas easier. Also, I don't know if I have the permission to change resolution status when something hasn't been touched for 12+ months. If I were to change status on likely candidates, would this anger the other developers? I know it's sensitive, for us slightly more delicate souls, but if you feel strongly about a bug status... I'd say go for its change of status. It will trigger either action/indifference from genuinely interested parties, possibly patches/discussion, action, and glory ;) It seems fair to say there is some level of (completely understandable) analysis paralysis for some level of bugs. Bug triage activity is at a low at the moment. Don't apologise for bringing that task back up in everyones focus/face. Regards, --Gary Tim ___ 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] UI experiments: pop-up menus and hot corners
On 4 Jul 2010, at 00:15, Bernie Innocenti ber...@codewiz.org wrote: El Fri, 02-07-2010 a las 04:49 -0500, Mikus Grinbergs escribió: sugar-toolkit/kill-the-delayed-menus-for-good.patch I received no comments so far. I'll ask my testers to give an opinion whether they like it more this way after a few days of adjustment. Sounds like something I would have an interest in. What does this do ? It makes menus pop-up immediately instead of after a 2 seconds delay. Ideally, we'd want users to click the right button explicitly, but even if we increase the delay, most users sit and wait patiently for the menu to open automatically. It seems to be a perverse form of laziness :-) In F11-0.88 I have also disabled the hot-corners for the frame. I don't like it, but Tim Falconer asked me to do it at Realness and there was a chorus of approval. They're probably still using the G1G1 crap software with the jumpy touchpad (I fixed it over 2 years ago :-) At some point, I will ask the children and their teachers to comment on these changes. So far nobody said anything: whether they like it or not, it's probably not a very big deal for them. FWIW, some current (ongoing) future design changes will remove this issue completely with a full screen dialogue for deciding new/resume. One click on a home view activity displays a new gallery/journal like display of past work or a new blank template (equal priority). There's a proposed design meeting on Sunday, but no time confirmed yet. Regards, --Gary -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://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
