Re: [Sugar-devel] ANNOUNCE: Sugar 0.88 for the XO-1
On Tue, May 25, 2010 at 23:12, Peter Robinson pbrobin...@gmail.com wrote: On Tue, May 25, 2010 at 9:23 PM, Bernie Innocenti ber...@codewiz.org wrote: El Tue, 25-05-2010 a las 19:16 +0100, Peter Robinson escribió: Is F-11 still the base OS for this? Unfortunately, this build is still based on Fedora 11. Fedora 13 dropped support for the Geode processor, so it's not an option. Upgrading to Fedora 12 would be possible, but there are unsolved issues with the Geode video driver (jnettlet is working on it). That's not entirely true. The was no changes in CPU support from F-12 to F-13. What has happened was a change in gcc which causes issues with F-13 on geode processors. There's a bit missing from gcc for geode support that would need to be added. dsd and cjb know more of the details. I'm happy to hear this. F14 may bring interesting changes for the XO1, can we hope that support for the Geode won't have been dropped by then? Thanks, Tomeu Considering the potential for hard to fix regressions, I felt that upgrading to Fedora 12 was probably not worth the effort. Instead, I've back-ported some useful things from Fedora 13: metacity-2.30, xulrunner-1.9.2.3 and usb_modeswitch-1.1.2. Someone could try rebasing the builds on Fedora 12 in parallel with us. If the result turns out to be very stable, we could consider switching. All this would probably have happen before the first beta, so there's not much time. If there's demand for it and its considered a 'good thing' I would consider pushing sugar 0.88 back to F-12. Not guaranteed, but its something that could be considered. Peter ___ 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] ANNOUNCE: Sugar 0.88 for the XO-1
On Wed, May 26, 2010 at 9:14 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On Tue, May 25, 2010 at 23:12, Peter Robinson pbrobin...@gmail.com wrote: On Tue, May 25, 2010 at 9:23 PM, Bernie Innocenti ber...@codewiz.org wrote: El Tue, 25-05-2010 a las 19:16 +0100, Peter Robinson escribió: Is F-11 still the base OS for this? Unfortunately, this build is still based on Fedora 11. Fedora 13 dropped support for the Geode processor, so it's not an option. Upgrading to Fedora 12 would be possible, but there are unsolved issues with the Geode video driver (jnettlet is working on it). That's not entirely true. The was no changes in CPU support from F-12 to F-13. What has happened was a change in gcc which causes issues with F-13 on geode processors. There's a bit missing from gcc for geode support that would need to be added. dsd and cjb know more of the details. I'm happy to hear this. F14 may bring interesting changes for the XO1, can we hope that support for the Geode won't have been dropped by then? There was a bug report [1] that was filed about it to do with glibc. Since I last looked at the bug there was an update added mentioning a kernel patch [2] to fix the problem. So by the look of it we could actually get it supported in F-13 with little effort once that patch has been accepted upstream. Yay! Cheers, Peter [1] https://bugzilla.redhat.com/show_bug.cgi?id=579838 [2] http://marc.info/?l=linux-kernelm=126748102722641w=2 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] review process follow-up.
On Tue, May 25, 2010 at 17:48, David Farning dfarn...@gmail.com wrote: On Tue, May 25, 2010 at 9:34 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: Hi David, thanks a lot for putting some new energy on this discussion, there's certainly more opportunities for us in revising this process. Certainly, and I will do my best to insure that the process revision is driven by an increase in useful patches which need to processed And I will be happy to read the reviews from the submitters ;) For background, Bernie and me talked on the phone last week and it helped a lot in aligning our positions on this. When we get the community team up and running I will propose that when a discussion gets a bit too heated, that someone proposes the interested parties to have a conf call. On Tue, May 25, 2010 at 16:00, David Farning dfarn...@gmail.com wrote: I would like to invite input on the new process that Tomeu and Bernie have been developing. I am specifically interested in see how Sugar Labs, OLPC, and third parties such as Activity Central can work together most effectively. Admittedly we are causing a disruption, hopefully one which will cause a net improvement. 1. Value and review of patches. The task we are doing are directly driven by deployments. As such we need to deal with version issues. Most of the deployments are using and will continue to use .82/4 for the near future. Paraguay is leading a push to stabilize on .88 by August of 2010. One of the mantras of Activity Central is upstream. We don't have our own mailing lists or bug trackers. This begs the question of dealing with versions. I am encouraging, but not requiring, that patches fix the issue for the version of sugar the customer uses plus the current develop version if applicable. About the specific issue of stable branches, my recommendation is that they are maintained by someone a bit closer to downstreams and that there's a strong requirement for only pushing backported bugfixes and, occasionally, features. Yes, I am not asking of expecting Sugar Labs to carry they burden of backporting. That is role is often played by a downstream distributor. Well, but if a stable version is deployed by more than one entity, they will have to work together, and isn't the main purpose of SLs to provide a place where people interested in Sugar can work together? Of course, resources will have to come from downstreams, but they will be doing upstream work when they maintain a stable branch. 2. Maintainer-ship. To avoid possible conflicts of interest, ie ramming ideas down the communitie's throat, I have avoided directly engaging key developers, comitters, and maintainer. For this to work we must gain credibility as useful participants. If and only if is acceptable to the current development team, I would like to make an effort to increase the number of activities maintained by Activity Central. Hmm, I'm not sure this decision belongs to the development team. What if AC starts by taking a couple of the several orphaned activities that are seeing more requests and we see how it works? The tricky thing here is that as a company, we are only interested in a few high value activities. So this is a place where crowding out _can_ occur if we are not careful. Sure, but may not be a problem right now if a downstream takes maintenance of 2 orphaned activities. And it could help us understand better how we want to work in the future. In a couple of months we should have the community and deployment teams running, which could be more appropriate forums to discuss this. I support the idea of a stronger emphasis on community engagement via a community team. I am a bit more hesitant about a deployment team. The needs of deployments are very specific and hard for a upstream community to effectively meet. Rather than working top down, it might be more effective to work bottom up by focusing on helping projects like ceibaljam and Ole Nepal push their deployments driven innovations upstream. Yes, this is how things would work ideally. And if it had worked that way, we would have had release managers, a QA team, our modules would be maintained, our teams would have coordinators with lively meetings, and a long etc. We have the same problem in GNOME and I cannot but suggest that upstreams shouldn't expect for their downstreams to behave as they should without some doing some serious and sustained talking. Also, I don't think that having a place in SLs where downstreams talk together about Sugar needs to mean that SLs will control them. SLs is nothing without downstreams and if today's SLs is given shape by people not affiliated to any downstream is because downstreams have been slow to join. But it's not the normal state of an upstream. I personally don't care if downstreams talk instead about Sugar in a mailing list in laptop.org, in groups.google.com or anywhere else, but I want them to stop
Re: [Sugar-devel] #1686 UNSP: Accessibility - virtual keyboard
On Sun, May 23, 2010 at 21:46, Michael Stone mich...@laptop.org wrote:
On Sun, May 23, 2010 at 03:18:47PM -0400, Michael Stone wrote:
On Wed, May 19, 2010 at 03:10:52PM +0200, Tomeu Vizoso wrote:
On Sat, May 15, 2010 at 23:48, Sugar Labs Bugs
bugtracker-nore...@sugarlabs.org wrote:
#1686: Accessibility - virtual keyboard
--+-
Reporter: earias | Owner: tomeu
Type: defect | Status: new
Priority: Unspecified by Maintainer | Milestone: Unspecified
by Release Team
Component: sugar | Version: Unspecified
Severity: Unspecified | Keywords: r?
Distribution: Unspecified | Status_field: Unconfirmed
--+-
Changes (by bernie):
* keywords: = r?
Comment:
Can someone please review this patch?
Any volunteers in the mailing list?
I'll offer a couple of observations. First, though, I'll reproduce the
patch
inline so that I can reply inline and so that everyone can take a good
look at
it.
Michael
From 6781e1bec2c387a740aafe0943c0aa9250482e1a Mon Sep 17 00:00:00 2001
From: Esteban ear...@localhost.localdomain
Date: Mon, 25 Jan 2010 14:52:17 -0200
Subject: [PATCH] virtualkeyboard
---
extensions/globalkey/Makefile.am | 4 +-
extensions/globalkey/virtualkeyboard.py | 12 +
src/jarabe/model/Makefile.am | 3 +-
src/jarabe/model/virtualkeyboard.py | 184 +++
src/jarabe/view/Makefile.am | 3 +-
src/jarabe/view/virtualkeyboard.py | 865
+++
6 files changed, 1068 insertions(+), 3 deletions(-)
create mode 100644 extensions/globalkey/virtualkeyboard.py
create mode 100755 src/jarabe/model/virtualkeyboard.py
create mode 100755 src/jarabe/view/virtualkeyboard.py
diff --git a/extensions/globalkey/Makefile.am
b/extensions/globalkey/Makefile.am
index 69afac2..dff13fb 100644
--- a/extensions/globalkey/Makefile.am
+++ b/extensions/globalkey/Makefile.am
@@ -3,4 +3,6 @@ sugardir = $(pkgdatadir)/extensions/globalkey
sugar_PYTHON = \
__init__.py \
screenshot.py \
- viewsource.py
+ viewsource.py \
+ virtualkeyboard.py
+
diff --git a/extensions/globalkey/virtualkeyboard.py
b/extensions/globalkey/virtualkeyboard.py
new file mode 100644
index 000..9291142
--- /dev/null
+++ b/extensions/globalkey/virtualkeyboard.py
@@ -0,0 +1,12 @@
+import os
+import gtk
+import logging
+
+from jarabe.model import shell
+import jarabe.view.virtualkeyboard
+
+BOUND_KEYS = ['altk']
+
+def handle_key_press(key):
+ logging.debug('load virtual keyboard')
+ jarabe.view.virtualkeyboard.Teclado()
diff --git a/src/jarabe/model/Makefile.am b/src/jarabe/model/Makefile.am
index 18d44da..ae3dce9 100644
--- a/src/jarabe/model/Makefile.am
+++ b/src/jarabe/model/Makefile.am
@@ -14,4 +14,5 @@ sugar_PYTHON = \
shell.py \
screen.py \
session.py \
- sound.py
+ sound.py \
+ virtualkeyboard.py
diff --git a/src/jarabe/model/virtualkeyboard.py
b/src/jarabe/model/virtualkeyboard.py
new file mode 100755
index 000..6867f10
--- /dev/null
+++ b/src/jarabe/model/virtualkeyboard.py
@@ -0,0 +1,184 @@
+#!/usr/bin/env python
+# -*- coding: iso-8859-1 -*-
+# virtualkeyboard
+# Copyright (C) 2009 Plan Ceibal
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
First observation: the patch is GPLv3+, yet Sugar is usually distributed
under
GPLv2+. Yes?
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/.
+#
+# Contact information: comuni...@plan.ceibal.edu.uy
+# Plan Ceibal http://www.ceibal.edu.uy
+
+import pygtk
+pygtk.require('2.0')
+import gtk
+import sys, os
+import time
+import pango
+import Xlib.display
+import Xlib.X
+import Xlib.XK
+import Xlib.protocol.event
Next observation: the patch introduces a dependency on python-xlib, which I
don't think we've depended on before. This doesn't seem hard to support but
it
does need to be more clearly explained.
+
+class Teclado:
+ special_X_keysyms = {
+ ' ' : space,
+ '\t' :
Re: [Sugar-devel] [PATCH] Set the DISPLAY env var once Xephyr has been launched
On Wed, May 19, 2010 at 23:15, James Cameron qu...@laptop.org wrote: I'm unsure of the reasons for the change. Instead of setting DISPLAY and SUGAR_EMULATOR_PID environment variables repeatedly for each attempt to run Xephyr, set the variables once. But that's what the patch does, moves setting those variables from the loop in _start_xephyr to somewhere close to the end of main(). Bernie has sent another patch that does this same thing. This would be effective in reducing CPU cost if there is contention in display numbers. Further efficiency during contention could also be gained by factoring much of _run_xephyr; there are many other steps there that might be done only once. Further readability might be gained by considering _setup_env. It sets environment variables that will be available to the Xephyr process, though I can't see a need for them there. Perhaps all environment variables could be moved there, and the display and pipe passed to it. That sounds good to me. Regards, Tomeu Not tested. Reviewed-by: James Cameron qu...@laptop.org -- 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 mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Set the DISPLAY env var once Xephyr has been launched
On Wed, May 19, 2010 at 23:21, Bert Freudenberg b...@freudenbergs.de wrote: On 19.05.2010, at 14:15, James Cameron wrote: each attempt to run Xephyr Just want to mention that I've been using the VNC-based Sugar emulator for quite a while, and it works much better than Xephyr. http://bugs.sugarlabs.org/ticket/1659 Yeah, it may be more worthy to just move to VNC. There were some issues last time I talked about it with Sascha, but I think he addressed them all. Regards, Tomeu - Bert - ___ 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] #1686 UNSP: Accessibility - virtual keyboard
On 26.05.2010, at 11:01, Tomeu Vizoso wrote: On Sun, May 23, 2010 at 21:46, Michael Stone mich...@laptop.org wrote: Final remark: this patch names variables, methods, and classes in Spanish. Anyone troubled by this? (I ask because, while it's fine with me personally, I don't think I know a consensus opinion on the subject.) I'm not so happy about it, I think it raises considerably the effort needed to read the code, even for spanish speakers like me. Regards, Tomeu IMHO the whole code base should be in English. This is the language we use for collaborating. - Bert - (native German speaker) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] review process follow-up.
On Wed, May 26, 2010 at 10:47:35AM +0200, Tomeu Vizoso wrote: I want them to stop doing redundant work, Please tell me if I'm doing redundant work, and I'll back off. It is often difficult to know what work is being done, so without knowledge of this it is quite likely that redundancy will occur. waiting for others to do something that nobody ends up doing, I think a downstream might want to wait for others to do something that nobody ends up doing ... that's a potential result of prioritisation by the downstream. (Why did you fix that, James, when there were more important things to fix?) and stop waiting for SLs to do what they need without having to even talk about it. I'm puzzled at that concept ... I can't see how SL can do something without any communication at all. ;-) I know there are several people working in finding ways for resources to reach upstream right now, but I find quite scary that SLs is seen as a group with a strong identity that intends to control users of Sugar. That's a side-effect of strong maintenance principles. Control of the code means some control of users. An alternative is a plethora of forks. Lower barriers on a fork demonstrates less control of users. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] #1686 UNSP: Accessibility - virtual keyboard
On Wed, May 26, 2010 at 11:14:37AM +0200, Bert Freudenberg wrote: IMHO the whole code base should be in English. This is the language we use for collaborating. I agree. (Though personally I find unusual object names easy to deal with because I'm from a time when names had to be so abbreviated as to be senseless.) -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Set the DISPLAY env var once Xephyr has been launched
On Wed, May 26, 2010 at 11:05:11AM +0200, Tomeu Vizoso wrote: On Wed, May 19, 2010 at 23:15, James Cameron qu...@laptop.org wrote: I'm unsure of the reasons for the change. Instead of setting DISPLAY and SUGAR_EMULATOR_PID environment variables repeatedly for each attempt to run Xephyr, set the variables once. But that's what the patch does, moves setting those variables from the loop in _start_xephyr to somewhere close to the end of main(). Sorry, my statement above Instead ... once. was my interpretation of what the patch does. I should have introduced it with Here is a possible reason for the change: -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Patch: use standard cursors in Paint
On Wed, May 26, 2010 at 1:42 AM, James Cameron qu...@laptop.org wrote:
On Tue, May 25, 2010 at 06:40:44AM -0300, Gonzalo Odiard wrote:
Use standard cursors for pencil, brush, eraser and paint-bucket. The
other tools need a custom cursor.
Bugs #40, #296 and OLPC #4316, #8864
Reviewed and tested ...
1. does fix dev.laptop.org #4316,
2. doesn't properly fix sugarlabs.org #296, some additional tuning of
coordinates may be needed; drawing effect still appears at an offset,
3. doesn't fix sugarlabs.org #40, in that the other cursors continue to
be invisible against similar backgrounds,
Yes, I am redrawing the images for the othr cursors.
4. doesn't remove images/{pencil,brush,bucket,eraser}.png
The coding style was a bit repetitive, here's an alternate method which
uses a dictionary and wraps the code better:
Thanks.
From e430f2742f910d16a59318060bd39fc80e37822b Mon Sep 17 00:00:00 2001
From: James Cameron qu...@laptop.org
Date: Wed, 26 May 2010 14:36:13 +1000
Subject: [PATCH] use cursors from Sugar theme
Use Sugar theme cursors for pencil, brush, eraser and paint-bucket.
http://dev.laptop.org/ticket/4316
---
Area.py | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/Area.py b/Area.py
index 611f944..8af2b9b 100644
--- a/Area.py
+++ b/Area.py
@@ -1057,8 +1057,18 @@ class Area(gtk.DrawingArea):
# Setting the cursor
try:
-pixbuf = gtk.gdk.pixbuf_new_from_file('./images/' +
tool['name'] + '.png')
-cursor = gtk.gdk.Cursor(gtk.gdk.display_get_default() ,
pixbuf, 6, 21)
+cursors = { 'pencil': 'pencil',
+'brush': 'paintbrush',
+'eraser': 'eraser',
+'bucket': 'paint-bucket' }
+display = gtk.gdk.display_get_default()
+if self.tool['name'] in cursors:
+name = cursors[self.tool['name']]
+cursor = gtk.gdk.cursor_new_from_name(display, name)
+else:
+filename = os.path.join('images', tool['name'] + '.png')
+pixbuf = gtk.gdk.pixbuf_new_from_file(filename)
+cursor = gtk.gdk.Cursor(display, pixbuf, 6, 21)
except gobject.GError:
cursor = None
--
1.7.1
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
--
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] review process follow-up.
On Wed, May 26, 2010 at 11:56, James Cameron qu...@laptop.org wrote: On Wed, May 26, 2010 at 10:47:35AM +0200, Tomeu Vizoso wrote: I want them to stop doing redundant work, Please tell me if I'm doing redundant work, and I'll back off. It is often difficult to know what work is being done, so without knowledge of this it is quite likely that redundancy will occur. Everybody is supposed to tell their colleagues when they are doing redundant work without a good reason for that. I wasn't referring to you because you read and participate on the mailing lists, but there's quite a bit of Sugar work being done out there that we don't know about. waiting for others to do something that nobody ends up doing, I think a downstream might want to wait for others to do something that nobody ends up doing ... that's a potential result of prioritisation by the downstream. Not referring to that, a good example is the F11 on XO-1 effort. I talked to two deployments and both told me that they were waiting for OLPC to release a stable version, but OLPC had publicly stated that they would not work on that. This case of miscommunication set the f11-on-xo1 effort some months back for no good reason. I don't see why a SLs developer has to take a plane in order to realize the situation and put people talking together. (Why did you fix that, James, when there were more important things to fix?) and stop waiting for SLs to do what they need without having to even talk about it. I'm puzzled at that concept ... I can't see how SL can do something without any communication at all. ;-) I know there are several people working in finding ways for resources to reach upstream right now, but I find quite scary that SLs is seen as a group with a strong identity that intends to control users of Sugar. That's a side-effect of strong maintenance principles. Control of the code means some control of users. An alternative is a plethora of forks. Lower barriers on a fork demonstrates less control of users. But maintainers are supposed to come from downstreams, not paid by SLs. Regards, Tomeu -- 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 mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] review process changes
Hi, would be good to reach some consensus and finally change the review process as defined in http://wiki.sugarlabs.org/go/Development_Team/Code_Review == Changes I would like to see == * Having _all_ reviews in the mailing list. The process already allows patches to be sent and discussed in the mailing list, but restricts it to new feature[s] and reasonably big. * Reduce the time spent creating and changing tickets in Trac == Issues I need help with == * How can a maintainer keep track of his queue with something like http://bugs.sugarlabs.org/wiki/TomeuReviewQueue if patches are sent to the list? * How can we make sure that patches don't fall through the cracks? * How can I know if the patch I'm staring at is the latest version? * How can we make easy to go from git blame to the review thread, the bug report and the feature page? == Opportunities brought by this change == * Share the code review tasks with more people. Somewhat orthogonal to the approval process itself, but having all reviews in the mailing list may make this more natural and efficient. * Get more people doing maintenance tasks and eventually becoming maintainers. Thanks for any opinions, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] #1686 UNSP: Accessibility - virtual keyboard
On Wed, May 26, 2010 at 11:14:37AM +0200, Bert Freudenberg wrote: IMHO the whole code base should be in English. This is the language we use for collaborating. +1 FWIW Martin pgpyCNHg72HXH.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ANNOUNCE: Sugar 0.88 for the XO-1
El Wed, 26-05-2010 a las 09:29 +0100, Peter Robinson escribió: I'm happy to hear this. F14 may bring interesting changes for the XO1, can we hope that support for the Geode won't have been dropped by then? There was a bug report [1] that was filed about it to do with glibc. Since I last looked at the bug there was an update added mentioning a kernel patch [2] to fix the problem. So by the look of it we could actually get it supported in F-13 with little effort once that patch has been accepted upstream. Yay! More than a bugfix, this is a work-around for the Geode not being fully compatible with the instruction set which Fedora is compiled for. Emulating the missing NOPL opcode in a kernel trap handler is going to be 10-100 times slower than the original instruction sequence. Let's just hope that GCC doesn't have the habit of generating any of these inside tight loops. -- // 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] ANNOUNCE: Sugar 0.88 for the XO-1
On Wed, May 26, 2010 at 2:31 PM, Bernie Innocenti ber...@codewiz.org wrote: El Wed, 26-05-2010 a las 09:29 +0100, Peter Robinson escribió: I'm happy to hear this. F14 may bring interesting changes for the XO1, can we hope that support for the Geode won't have been dropped by then? There was a bug report [1] that was filed about it to do with glibc. Since I last looked at the bug there was an update added mentioning a kernel patch [2] to fix the problem. So by the look of it we could actually get it supported in F-13 with little effort once that patch has been accepted upstream. Yay! More than a bugfix, this is a work-around for the Geode not being fully compatible with the instruction set which Fedora is compiled for. Emulating the missing NOPL opcode in a kernel trap handler is going to be 10-100 times slower than the original instruction sequence. Let's just hope that GCC doesn't have the habit of generating any of these inside tight loops. yea, or you can install your own koji infrastructure and setup a i586/i383 secondary arch, rebuild all of fedora, provide hosting, servers,storage and infrastructure infrastructure for it. TBH I don't know what changed between F-12 and F-13. It wasn't the compile flag changes as I checked them so I'm wondering wondering why its suddenly a problem. I have a mostly stable XO-1 running SOAS-2 without issues when fully updated (except for some black icons). So it could be that for some reason we're suddenly triggering this where we haven't in the past. Other suggestions are welcome. I'm really not up to speed on random x86 assembler quirks between chips. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ANNOUNCE: Sugar 0.88 for the XO-1
Hi, TBH I don't know what changed between F-12 and F-13. It wasn't the compile flag changes as I checked them so I'm wondering wondering why its suddenly a problem. gcc changed; it started emitting NOPL instructions under i686. - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] #1686 UNSP: Accessibility - virtual keyboard
Tomeu, Bert, James, Martin D., and Michael wrote: T: Thanks a lot for lending a hand here. My pleasure, and thanks for mentioning the ticket. M: Final remark: this patch names variables, methods, and classes in Spanish. Anyone troubled by this? (I ask because, while it's fine with me personally, I don't think I know consensus opinion on the subject.) T: I'm not so happy about it, I think it raises considerably the effort needed to read the code, even for spanish speakers like me. B,J,MD: IMHO the whole code base should be in English. This is the language we use for collaborating. You and I certainly collaborate in English but the folks dealing with Sugar on a daily basis in Uruguay, Peru, and Paraguay largely do not, at least in their daily dealings among themselves. For this sole strategic reason, I think we need to consider accepting well-written patches that come to us in Spanish or in English. The main cost of pursuing this course is that patches written in Spanish are somewhat harder for some prominent Sugar contributors to read than are patches written in English. Additionally, having a mixed-language codebase may be off-putting to some potential contributors. On the other hand, does it not seem likely that by welcoming patches written in the first and most common language of our largest groups of users, we would receive more patches, thereby gaining more contributors, some of whom might grow to become integral members of our community? (Finally, if we don't receive many patches, then what will be the loss for having tried? At most, we will have a small number of patches to translate from Spanish to English. Not a big deal, right?) Regards, Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ANNOUNCE: Sugar 0.88 for the XO-1
On 25 May 2010 18:12, Peter Robinson pbrobin...@gmail.com wrote: That's not entirely true. The was no changes in CPU support from F-12 to F-13. What has happened was a change in gcc which causes issues with F-13 on geode processors. There's a bit missing from gcc for geode support that would need to be added. dsd and cjb know more of the details. Interesting, I hadn't realised that. The change from i586 to i686 happened for F12, not F13 as I had thought. So in fact, it is likely that F12 will not work on XO-1, but it might only affect a handful of packages. The problem is that the Geode is an i586, not an i686. It does support the majority of the new i686 instructions, but not all. So it's not quite an i686. The reason that the problem is more evident on F13 will be due to improvements in the compiler (gcc), which is now better at producing optimized code using the new optimized i686 instructions, including the ones that are not supported on geode. One option is to persuade Fedora that OLPC/Geode matters and ask them to go back to i586. The other is to implement an instruction emulator in the kernel, which will emulate in software the i686 instructions that are not supported on geode. This will introduce a slowdown, but because the instruction in question (nopl) is simple, the kernel can emulate all instances of it at the same time (within the current code section) once the first instance is met. As has been pointed out, there is some kernel code floating around that is working in this direction. However, it's not totally correct and the kernel developers want a more generic system rather than something Geode-specific. And there are efforts going in this direction, but there have been for 1-2 years now, it is slow moving. We need someone like Bernie to pick up the project, hint hint ;) Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] #1686 UNSP: Accessibility - virtual keyboard
First of all, thanks Esteban for the great work! I hope we can spin a new build soon and give it a try. On the other hand, even though I also come from a Spanish speaking country, I'd say having all the code in English (the defacto lingua franca for code) would be best on the long term. It's an extra effort (and I volunteer to help with translations if Esteban is short on time) but I think it is important to maintain consistency in variable names, methods and comments. Cheers, Raúl P.S.: we try to produce all of our code (in git.paraguayeduca.org) under the same rules (all English) so we can share it among deployments.. we hope it results useful for someone some day! :) On Wed, 2010-05-26 at 10:57 -0400, Michael Stone wrote: Tomeu, Bert, James, Martin D., and Michael wrote: T: Thanks a lot for lending a hand here. My pleasure, and thanks for mentioning the ticket. M: Final remark: this patch names variables, methods, and classes in Spanish. Anyone troubled by this? (I ask because, while it's fine with me personally, I don't think I know consensus opinion on the subject.) T: I'm not so happy about it, I think it raises considerably the effort needed to read the code, even for spanish speakers like me. B,J,MD: IMHO the whole code base should be in English. This is the language we use for collaborating. You and I certainly collaborate in English but the folks dealing with Sugar on a daily basis in Uruguay, Peru, and Paraguay largely do not, at least in their daily dealings among themselves. For this sole strategic reason, I think we need to consider accepting well-written patches that come to us in Spanish or in English. The main cost of pursuing this course is that patches written in Spanish are somewhat harder for some prominent Sugar contributors to read than are patches written in English. Additionally, having a mixed-language codebase may be off-putting to some potential contributors. On the other hand, does it not seem likely that by welcoming patches written in the first and most common language of our largest groups of users, we would receive more patches, thereby gaining more contributors, some of whom might grow to become integral members of our community? (Finally, if we don't receive many patches, then what will be the loss for having tried? At most, we will have a small number of patches to translate from Spanish to English. Not a big deal, right?) Regards, Michael ___ 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] Sugar Digest 2010-05-25
I think this can be like the sugar-love tag. I don't know if we can involve volunteers in all the process, but may be i am ignorant al respect. Gonzalo On Wed, May 26, 2010 at 1:24 AM, Michael Stone mich...@laptop.org wrote: On Tue, May 25, 2010 at 11:54:42PM -0400, Chris Ball wrote: That's certainly true in general, but would it have to follow that a bug couldn't be counted as fixed, for the purposes of conducting the competition when a patch is approved? It doesn't have to mean that the bug on SL Trac should be closed as fixed. Cool, then can we have a competition for moving bugs that have fixes with a patch to a release? ;-) Sure. Just award points for every action transition listed on http://wiki.laptop.org/go/Trac_ticket_workflow in addition to the one suggested by Gonzalo. Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard Responsable de Desarrollo Sistemas Australes ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] #1686 UNSP: Accessibility - virtual keyboard
First of all, thanks Esteban for the great work! I hope we can spin a new build soon and give it a try. Thanks, that would indeed be helpful. Meanwhile, something else that you might spin around in your head while you make the build is how do we make a virtual keyboard that works for all the languages we have keyboards for? (and/or, is there another program that already does this that could be integrated with Sugar?) On the other hand, even though I also come from a Spanish speaking country, I'd say having all the code in English (the defacto lingua franca for code) would be best on the long term. I'm not yet convinced, though I certainly appreciate your feedback. Here are three prominent memories that still sway my opinion: 1) I read multi-language files and communications nearly every day so, for me, they're already a fact of life. For example, every time I read my email, every time I write a Makefile, and every time I write a web-app (in SML, HTML, CSS, JS, and SVG) I'm facing the same general problem posed by Spanish-flavored vs. English-flavored patches. 2) When OLPC sent me to visit LATU and Ceibal Jam, I was struck by the large quantities of interesting code written by both of those organizations... in Spanish. I know that I want both that code and the people writing it to be participating more directly in the daily development of Sugar. My best idea for how to achieve this goal is to try to meet them halfway. 3) When I (briefly) taught English in a public school in Dharamsala, India, I found that I could not function effectively without learning enough Hindi to establish a working pidgin communications channel. This channel mattered for two reasons: first, because it served as a control plane for collaboration and second, because it generated enough mutual respect and interest to sustain collaboration. I feel both these needs here too. It's an extra effort (and I volunteer to help with translations if Esteban is short on time) but I think it is important to maintain consistency in variable names, methods and comments. I agree that it's important be (sufficiently) consistent. However, I also believe that an acceptable degree of consistency can be found in a codebase that contains both Spanish and English text. Instead, the kind of inconsistency that I am most concerned with is inconsistency in control and data flow idioms. Regards, Michael P.S.: we try to produce all of our code (in git.paraguayeduca.org) under the same rules (all English) so we can share it among deployments.. we hope it results useful for someone some day! :) P.S. - Thanks for the links and for the thought-provoking discussion! ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] #1686 UNSP: Accessibility - virtual keyboard
On Wed, May 26, 2010 at 10:57:55AM -0400, Michael Stone wrote: Additionally, having a mixed-language codebase may be off-putting to some potential contributors. It's also going to decrease consistency[1] and increase the bar to contribution to (ad absurdum) working knowledge of each language of each patch contributor. [D]oes it not seem likely that by welcoming patches written in the first and most common language of our largest groups of users, we would receive more patches[?] It doesn't seem likely since an understanding of existing English code would seem a prerequisite for any patches to exist in the first place. (Finally, if we don't receive many patches, then what will be the loss for having tried? At most, we will have a small number of patches to translate from Spanish to English. Not a big deal, right?) Oh wait, are you supporting *reviewing* patches in any language but *committing* only translated patches? That seems much less consistency-hostile. Regards, Michael Martin 1. I don't think the second section of PEP-8 diminishes this objection pgpwfkU67ptld.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Change default Neighborhood network settings for greater security
Posted on the Sugar Labs wiki, http://wiki.sugarlabs.org/go/Request_New_Features#Change_default_Mesh_settings_for_greater_security , Change default Mesh settings for greater security We were very excited to try Sugar on a Stick (Mirabelle). However, I was very surprised to find lots of users with whom I could make friends, some of whom seemed to have included their real names! It took some digging in this Wiki to find out that I just had to delete the Mesh entry (i.e., the reference to jabber.sugarlabs.org) so that only Sugar users on our Wi-Fi would show up. There may be a genuine security concern here. We simply have no way of knowing who the other users are with whom a child can make friends. All it would take is for one bad thing to happen for the Sugar project to suffer. While we love the idea of children from all over the world collaborating on-line, perhaps pragmatic concerns about the security of all children should lead us, at the very least, to have the default setting on the Mesh entry as a blank. Parents and teachers will then be responsible for enabling this feature, if they so wish. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH v1 00/10] Journal sorting by file size and creation time.
Hi Andrés, On 24 May 2010, at 01:16, Andrés Ambrois wrote: On Sunday 23 May 2010 04:08:51 pm Michael Stone wrote: Andrés, I've read these patches and tested them locally (with minor changes due to merge conflicts with some of my experimental work) and the results are quite pleasing to me. Thanks! The one issue that I would like you to fix before I merge these patches into my tree is that I would like you to include additional patches for the new icons that your ListViewButton requires to function as intended. (I don't really care whether the new icons are different from the old icons; I merely care that I still have a normal-looking ListViewButton after I select one of your new sort modes rather than the thin grey bar that I currently see.) I only have the filesize icon I made for testing, but I usually stay away from graphics work (I suck at GIMP). Gary, I see you uploaded [0] to the wiki, which is what this patchset is based on. Do you have SVG versions of the icons you put in there? I've built the 3 icons out as SVGs attached, here's PNGs of them as well for easier quick review: inline: view-lastedit.png inline: view-created.png inline: view-size.png Would love to see a quick screenshot of them in place in the palette – it is usually a bit of a struggle (time wise) for me to apply patches and see for myself. Regards, --Gary Regards, and thanks for all your hard work here, Thank you for reviewing! Michael [0] http://wiki.sugarlabs.org/go/File:Journal_mockup_gary_list_extended_palette.png -- -Andrés inline: view-created.svg inline: view-lastedit.svg inline: view-size.svg___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Physics activity (Was: Release v3 tonight?)
Hi SJ, On 20 May 2010, at 20:34, Samuel Klein wrote: An aside about Physics - it was used with great happiness by the children in Gaza, and features in some of the photos we just got back from there. More as soon as we have release to publish them :-) Can't wait! It's always great to see photos with children actually using specific activities, Maze is usually the one that shows up most often :) Regards, --Gary P.S. Physics is next on my radar to update, now I have more spare time. Craig Macomber kindly posted some refactoring patches I need to test and release, and I'd like to at least add new toolbar support. SJ On Tue, Jul 28, 2009 at 11:49 AM, Gary C Martin g...@garycmartin.com wrote: Hi Asaf, On 28 Jul 2009, at 02:41, Asaf Paris Mandoki wrote: Great! For now, we will just be unzipping the elements / box2d .egg libraries into lib/ (until we figure out how to include setuptools from within an activity). Will commit this within the next few days. Could you put the current elements version there? Once I commit the new save method to the Physics activity, what will be missing to have v3 release? Not much I think. I'd like to do some testing here as soon as your new state saving work is committed; also want to make the icon changes we discussed (irregular polygon, hand grab icon). I haven't seen the translations being committed. Does anyone know if there's a problem with the translation system? Another problem I have is that I got a friend to suggest a French translation but I cant set his suggestions as the actual translated text. I'll take a look once I'm back on-line (travelling today), though I didn't notice any po updates last time I checked. Perhaps the translate push cycle is currently being timed along with the current 0.85.x. Regards, --Gary ___ 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] 3G Support: show connection errors- Patch 1759
On Wed, May 26, 2010 at 10:43 AM, Daniel Castelo dcast...@plan.ceibal.edu.uy wrote: Maybe if we show the network manager reason and a suggestion for the user is enough for a first version. +1 I apologize for joining this conversation so late, I think it looks good already, We still need a universal friendly way to display error messages btw. On Wed, May 19, 2010 at 8:54 PM, James Cameron qu...@laptop.org wrote: On Wed, May 19, 2010 at 09:36:12AM -0300, Daniel Castelo wrote: I'd like to know which error messages we should show in each case. I think that will have to wait until it is tested by more users with a diversity of telecommunication networks. Otherwise, the underlying NM reason code should be exposed untranslated to the user. When given more information, users can determine patterns and better understand causes. -- James Cameron http://quozl.linux.org.au/ -- Ing. Daniel Castelo Plan Ceibal - Área Técnica Avda. Italia 6201 Montevideo - Uruguay. Tel.: 601.57.73 Interno 2228 E-mail : dcast...@plan.ceibal.edu.uy ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Really cool developments with SoaS v3
There have been some nice little changes in various parts of SugarLabs recently which make me happy to see that core contributors are really thinking about sugar sustainability and sugar in the field, but I think we've all just been blown out of the water with 4 really great things about the new SoaS release that I'd like to highlight: 1. Scaling to appropriate resources - given that the community isn't that big, they've cut back to something that's maintainable and sustainable, with clear processes, and ideas on how to grow as more resources become available. 2. Piggybacking from other communities - by making sure that everything is sparkly clean and by positioning themselves within the bounds of Fedora's organization, rules and guidelines, they've won support and assistance of Fedora and its community, to the point where SoaS is a download from Fedora itself, and is prominently featured in the Fedora 13 release notes (extremely cool!): http://fedoraproject.org/wiki/F13_one_page_release_notes?F13an 3. Local requirements - I see a change in model with the v3 release, from a model that I never thought would work well (1 version of SoaS for the whole world) to the simple distribution of a reference platform with a clean process for making customizations, which is realistically something that the vast majority of significant soas deployers would want to do. 4. Build/customization documentation - in addition to actually adjusting the process to make customization clean and possible, they've written *good documentation* on how to do it, even ready for the release date and not done as an afterthought: http://download.sugarlabs.org/soas/docs/customization-guide/ Thanks to the SoaS contributors, great work! Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Change default Neighborhood network settings for greater security
On Wed, May 26, 2010 at 10:34:04AM -0700, Frederick Grose wrote: We simply have no way of knowing who the other users are with whom a child can make friends. How is this different from the lack of knowledge one has about the people one's children could meet at a city park? All it would take is for one bad thing to happen for the Sugar project to suffer. This is an unsubstantiated and dangerous assumption to make, and as a parent I would not support such a change to the default. From a learning environment wher collaboration is first class to cripple it for the average downloader by default is silly. We must resist this only one bad thing line of reasoning, which reducto ad absurdum leads to paralysing madness (shall we change the branding in case one bad thing happens like a child misinterpreting Sugar is good and gorging themselves on sugar?). While we love the idea of children from all over the world collaborating on-line, perhaps pragmatic concerns about the security of all children should lead us, at the very least, to have the default setting on the Mesh entry as a blank. Parents and teachers will then be responsible for enabling this feature, if they so wish. Parents and teachers giving their child a computer with a learning environment that promotes collaborative learning (first sentence of the first text on www.sugarlabs.org) have chosen to take responsibility for the nature of their child's learning, including the collaborative part that is so promoted (rightly so). Please don't try to convince me that someone who's downloaded an .iso, installed it on a usb stick, and handed it, or a computer with it, to a child hasn't assumed that responsibility. pragmatic concerns about the security of all children We need to not assume responsibility for the security of all children. [...] at the very least [the default collaboration setting should be effectively off for the individual SoaS user] I cannot imagine what might be meant by the very least here. Martin pgpgjfYgoAciN.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] #1686 UNSP: Accessibility - virtual keyboard
On Wed, May 26, 2010 at 10:57:55AM -0400, Michael Stone wrote: For this sole strategic reason, I think we need to consider accepting well-written patches that come to us in Spanish or in English. I agree. I don't think language, culture of origin, or degree of whitespace should prevent acceptance. They might delay or hinder review though, and so use of English should be a recommendation and not a requirement. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ANNOUNCE: Sugar 0.88 for the XO-1
El Wed, 26-05-2010 a las 12:00 -0300, Daniel Drake escribió: As has been pointed out, there is some kernel code floating around that is working in this direction. However, it's not totally correct and the kernel developers want a more generic system rather than something Geode-specific. And there are efforts going in this direction, but there have been for 1-2 years now, it is slow moving. We need someone like Bernie to pick up the project, hint hint ;) :-) The lazy Bernie would opt for merging the NOPL emulation patch into our custom OLPC kernel so we can do a quick test with Fedora 13. If it works, there will probably be a few more issues to fix, such as the Geode driver. I'm afraid we lack resources to debug both Sugar and Fedora in time for the August release. If someone wants to take ownership of the platform part, I'd be happy to try. The criteria for accepting the distro upgrade is the usual one: no known regressions relative to Fedora 11 + Sugar 0.88. (all bundled activities must work as well as before). -- // 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] [PATCH] Add icons for the sorting options in the Journal
Thanks to Gary C. Martin for the icons. Signed-off-by: Andrés Ambrois andresambr...@gmail.com --- icons/scalable/actions/Makefile.am |3 +++ icons/scalable/actions/view-created.svg | 21 + icons/scalable/actions/view-lastedit.svg | 23 +++ icons/scalable/actions/view-size.svg | 12 4 files changed, 59 insertions(+), 0 deletions(-) create mode 100644 icons/scalable/actions/view-created.svg create mode 100644 icons/scalable/actions/view-lastedit.svg create mode 100644 icons/scalable/actions/view-size.svg diff --git a/icons/scalable/actions/Makefile.am b/icons/scalable/actions/Makefile.am index 42a06a3..a00a2df 100644 --- a/icons/scalable/actions/Makefile.am +++ b/icons/scalable/actions/Makefile.am @@ -94,6 +94,9 @@ icon_DATA = \ view-freeform.svg \ view-fullscreen.svg \ view-list.svg \ + view-size.svg \ + view-lastedit.svg \ + view-created.svg\ view-radial.svg \ view-refresh.svg\ view-return.svg \ diff --git a/icons/scalable/actions/view-created.svg b/icons/scalable/actions/view-created.svg new file mode 100644 index 000..7d3ba09 --- /dev/null +++ b/icons/scalable/actions/view-created.svg @@ -0,0 +1,21 @@ +?xml version=1.0 encoding=UTF-8? +!DOCTYPE svg PUBLIC -//W3C//DTD SVG 1.1//EN http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd; [ + !ENTITY fill_color #00 + !ENTITY stroke_color #FF +] +svg xmlns=http://www.w3.org/2000/svg; width=55 height=55 + defs + mask id=Mask maskUnits=userSpaceOnUse x=0 y=0 width=55 height=55 +rect x=0 y=0 width=55 height=55 fill=#FF stroke=none/ + circle cx=27.5 cy=15 r=1.75 style=fill:#00;;stroke:none/ + circle cx=27.5 cy=40 r=1.75 style=fill:#00;;stroke:none/ + circle cx=15 cy=27.5 r=1.75 style=fill:#00;;stroke:none/ + circle cx=40 cy=27.5 r=1.75 style=fill:#00;;stroke:none/ +line x1=27.5 y1=27.5 x2=34.5 y2=17 stroke=#00 stroke-width=2.5 stroke-linecap=round/ +line x1=27.5 y1=27.5 x2=35 y2=32.5 stroke=#00 stroke-width=2.5 stroke-linecap=round/ + /mask + /defs +circle cx=27.5 cy=27.5 r=17 style=fill:stroke_color;;stroke:stroke_color;;stroke-width:3.5 mask=url(#Mask)/ +!-- +-- +/svg diff --git a/icons/scalable/actions/view-lastedit.svg b/icons/scalable/actions/view-lastedit.svg new file mode 100644 index 000..fe3e077 --- /dev/null +++ b/icons/scalable/actions/view-lastedit.svg @@ -0,0 +1,23 @@ +?xml version=1.0 encoding=UTF-8? +!DOCTYPE svg PUBLIC -//W3C//DTD SVG 1.1//EN http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd; [ + !ENTITY fill_color #00 + !ENTITY stroke_color #FF +] +svg xmlns=http://www.w3.org/2000/svg; width=55 height=55 + defs + mask id=Mask maskUnits=userSpaceOnUse x=0 y=0 width=55 height=55 +rect x=0 y=0 width=55 height=55 fill=#FF stroke=none/ +line x1=19 y1=19 x2=27 y2=19 stroke=#00 stroke-width=2.5/ +line x1=28 y1=19 x2=31 y2=19 stroke=#00 stroke-width=2.5/ +line x1=19 y1=24 x2=21 y2=24 stroke=#00 stroke-width=2.5/ +line x1=22 y1=24 x2=26 y2=24 stroke=#00 stroke-width=2.5/ +line x1=19 y1=29 x2=22 y2=29 stroke=#00 stroke-width=2.5/ +path d=M 24 35 l 2 -6 l 19 -19 l 4 3 l -19 19 z fill=#00 stroke=#00 stroke-width=3/ + /mask + /defs +rect x=15 y=14 width=25 height=27 style=fill:stroke_color;;stroke:stroke_color;;stroke-width:3.5 mask=url(#Mask)/ +path d=M 24 35 l 1 -5 l 4 3 z fill=stroke_color; stroke=none/ +path d=M 24 35 m 2 -6 l 19 -19 l 4 3 l -19 19 z fill=stroke_color; stroke=none/ +!-- +-- +/svg diff --git a/icons/scalable/actions/view-size.svg b/icons/scalable/actions/view-size.svg new file mode 100644 index 000..e87f978 --- /dev/null +++ b/icons/scalable/actions/view-size.svg @@ -0,0 +1,12 @@ +?xml version=1.0 encoding=UTF-8? +!DOCTYPE svg PUBLIC -//W3C//DTD SVG 1.1//EN http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd; [ + !ENTITY fill_color #00 + !ENTITY stroke_color #FF +] +svg xmlns=http://www.w3.org/2000/svg; width=55 height=55 +line x1=12 y1=17.5 x2=43 y2=17.5 stroke=stroke_color; stroke-width=2.5/ +line x1=16 y1=22.5 x2=39 y2=22.5 stroke=stroke_color; stroke-width=2.5/ +line x1=20 y1=27.5 x2=35 y2=27.5 stroke=stroke_color; stroke-width=2.5/ +line x1=23.5 y1=32.5 x2=31.5 y2=32.5 stroke=stroke_color; stroke-width=2.5/ +line
