Re: [Sugar-devel] Datastore index corruption!

[Bernie Innocenti]

On Thu, 2010-07-29 at 15:50 +1000, James Cameron wrote:
> On Thu, Jul 29, 2010 at 01:39:45AM -0400, Bernie Innocenti wrote:
> > On Thu, 2010-07-29 at 15:15 +1000, James Cameron wrote:
> > > Ugh.  So Write has terminated before data is saved?  That's bad.  Should
> > > it not wait for data to be fully saved?
> > 
> > I believe data was saved, but the metadata index was not flushed to disk
> > by the datastore process.
> 
> Isn't that functionally identical to not saving data?

The effect is slightly different from not saving the data at all: it
uses up space in the filesystem :-)

Seriously, if you could force an index rebuild, you'd get to see the
hidden data.

-- 
   // 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] Datastore index corruption!

[Gary Martin]

On 29 Jul 2010, at 00:21, Bernie Innocenti  wrote:

> (also filed as http://bugs.sugarlabs.org/ticket/2132, but let's keep the
> discussion on the mailing-list, please).
> 
> Today we figured out one of the possibly many ways in which the index of
> the datastore can get corrupted in Sugar. 
> 
> Here's an almost infallible recipe to reproduce it:
> 
> 1. open Write
> 2. type something
> 3. close Write
> 4. wait a few seconds
> 5. kill -9 the datastore process
> 6. restart sugar (ctrl-alt-del)
> 
> Your saved entry is gone. It still takes up space on disk, but it's no
> longer visible until you rebuild the index.
> 
> Step 5 is just an artificial way to reproduce the problem. Other equally
> effective ways to trigger this data loss issue in the real-world include
> running out of battery, holding the power button for 4 seconds, and
> triggering the kernel out-of-memory killer.
> 
> I'm sure the datastore could definitely work harder to prevent this type
> of data loss, by flushing the index immediately after an activity
> creates a new entry.
> 
> Meanwhile, we're working on a work-around that will hopefully fix all
> problems of this sort: a "Rescan" or "Reindex" item on the Journal
> palette.

Unsurprisingly, a massive -1 from me, but you knew that was coming already! ;)

> I can already hear a big objection coming: this sort of geeky stuff has
> no place in the Sugar UI. True, but I see no alternative until we'll
> have a 100% reliable datastore that can fix itself in all cases of
> corruption.

Never going to happen, keep dreaming if you want, but it will only get better, 
never perfect. 

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

Re: [Sugar-devel] Datastore index corruption!

[James Cameron]

On Thu, Jul 29, 2010 at 01:39:45AM -0400, Bernie Innocenti wrote:
> On Thu, 2010-07-29 at 15:15 +1000, James Cameron wrote:
> > Ugh.  So Write has terminated before data is saved?  That's bad.  Should
> > it not wait for data to be fully saved?
> 
> I believe data was saved, but the metadata index was not flushed to disk
> by the datastore process.

Isn't that functionally identical to not saving data?

-- 
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] Datastore index corruption!

[Bernie Innocenti]

On Thu, 2010-07-29 at 15:15 +1000, James Cameron wrote:
> Ugh.  So Write has terminated before data is saved?  That's bad.  Should
> it not wait for data to be fully saved?

I believe data was saved, but the metadata index was not flushed to disk
by the datastore process.

-- 
   // 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] Datastore index corruption!

[James Cameron]

On Wed, Jul 28, 2010 at 07:21:12PM -0400, Bernie Innocenti wrote:
> 1. open Write
> 2. type something
> 3. close Write
> 4. wait a few seconds
> 5. kill -9 the datastore process
> 6. restart sugar (ctrl-alt-del)
> 
> Your saved entry is gone. It still takes up space on disk, but it's no
> longer visible until you rebuild the index.

Ugh.  So Write has terminated before data is saved?  That's bad.  Should
it not wait for data to be fully saved?

-- 
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] Changing bundle_id and version scheme for Etoys

[C. Scott Ananian]

On Wed, Jul 28, 2010 at 12:06 PM, Bernie Innocenti  wrote:
> There's no reason to have both a filename and a dbus-like name for the
> same thing. The former must already be unique on both distribution sites
> and in the Activities directory.

I claim we should be using the dbus-like name for "both distribution
sites and in the Activities directory".
  --scott

-- 
                         ( http://cscott.net/ )
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Datastore index corruption!

[Bernie Innocenti]

(also filed as http://bugs.sugarlabs.org/ticket/2132, but let's keep the
discussion on the mailing-list, please).

Today we figured out one of the possibly many ways in which the index of
the datastore can get corrupted in Sugar. 

Here's an almost infallible recipe to reproduce it:

1. open Write
2. type something
3. close Write
4. wait a few seconds
5. kill -9 the datastore process
6. restart sugar (ctrl-alt-del)

Your saved entry is gone. It still takes up space on disk, but it's no
longer visible until you rebuild the index.

Step 5 is just an artificial way to reproduce the problem. Other equally
effective ways to trigger this data loss issue in the real-world include
running out of battery, holding the power button for 4 seconds, and
triggering the kernel out-of-memory killer.

I'm sure the datastore could definitely work harder to prevent this type
of data loss, by flushing the index immediately after an activity
creates a new entry.

Meanwhile, we're working on a work-around that will hopefully fix all
problems of this sort: a "Rescan" or "Reindex" item on the Journal
palette.

I can already hear a big objection coming: this sort of geeky stuff has
no place in the Sugar UI. True, but I see no alternative until we'll
have a 100% reliable datastore that can fix itself in all cases of
corruption.

-- 
   // 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] Changing bundle_id and version scheme for Etoys

[Bernie Innocenti]

On Tue, 2010-07-27 at 19:57 -0400, C. Scott Ananian wrote:

> > A good surrogate could be that no two activities with the same name can
> > be uploaded to ASLO.
> 
> Translated name?  English name?  No Spanish name may conflict with a
> Portuguese or English name?  Seems a bit strange to me.

Filesystem name. Which is often the same of the English name, but not
always (Oficina -> Paint).

There's no reason to have both a filename and a dbus-like name for the
same thing. The former must already be unique on both distribution sites
and in the Activities directory.

-- 
   // 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] Audacity under Sugar

[Sean Linton]

Dear All,

I am working on a conference presentation on ICT enabled networking
for indigenous music foundations. I have been working on some ideas
with David Leeming who as supplied me with an XO machine while I try
to work some things out on it.

We are looking at the potential for using Audacity as a tool to help
enable and create content for community radio stations. The idea being
that the XO can be used to record audio an then send low latency audio
code to the radio hub as oggs or mp3s.

I have installed audacity using

yum install audacity

It is no problem for me to run "audacity' from the command line,
however I am aware that OLPC developers are trying to keep the sugar
gui.

I have been also trying to find the lame libraries to enble the mp3
export function, but have limited success adjusting the
/etc/yum.repos.d or /etc/yum.conf files. I think I need to access the
ubuntu multiverse? I have no problem working in .ogg format but I am
not sure if everyone feels that way?

I would be interested in using the 'sugarize' script that you wrote to
give audacity 'activity' status, with icon, and journal compatability.

Would you be able to discuss with me how to sugarize audacity, or walk
me through your script? Audacity has options for saving files; the
"save" function creates a file that only audacity can read (aup).
Mp3/Wav/Au/Ogg require "export". Perhaps the *aup file would be useful
for journal use, eg. by chmod -x ( asigning it executble status have
it run audacity from journal?  )

I have also been looking at introducing new insruments to the
tamtam suites, ethnic instruments based on the local instruments of
the XO distributions, eg Panpipes on Tamtam for computers in the
Solomon Islands? Can you suggest a way to implement this?


Sincerely

Sean Linton
Ph D Student
Otago University
Music Department
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Changing bundle_id and version scheme for Etoys

[Bert Freudenberg]

On 27.07.2010, at 18:57, Bernie Innocenti wrote:

> On Tue, 2010-07-27 at 18:21 -0400, C. Scott Ananian wrote:
> 
>> This is a nicely decentralized mechanism for choosing identifiers
>> which are guaranteed by construction never to conflict.
> 
> It is indeed a simple and nice scheme, but why is such uniqueness a
> desiderable feature

I thought because the laptops are connected, and this scheme ensures that a 
local and a remote activity use the same id.

- Bert -


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Journal and Updating Software Process

[Frederick Grose]

On Wed, Jul 28, 2010 at 12:14 PM, Frederick Grose  wrote:

> On Wed, Jul 28, 2010 at 10:02 AM, Daniel Castelo <
> dcast...@plan.ceibal.edu.uy> wrote:
>
>> On Tue, Jul 27, 2010 at 11:51 PM, Frederick Grose wrote:
>>
>
{...}

 See https://bugs.sugarlabs.org/ticket/1512
>>>
>>
>> Great. Thanks!
>> The trac ticket suggest a new behavour:
>>
>> "The download event record, as a system event, might have a 'hide event'
>> option or not be erasable. The code bundle behind the event should, perhaps,
>> only be erased from the Home list view (installed-Activity-code-bundle
>> management), while system or Activity events and their associated object
>> instances are managed from the Journal of Activity event instances."
>>
>> Which is the next step that I should follow to solve this issue? I suppose
>> that is to discuss in this email list which could be the best solution.
>>
>
> As noted, the problem of inadvertent deletion of updated or newly added
> Activity bundles may occur in the Journal or in the Home list view (through
> the erase action in an extended palette).  The most comprehensive solution
> might involve grouping of Journal items [1], but that won't be quick.
>
> A quicker solution may be to recognize the Journal entry type or kind in
> the Journal (if that is sufficient) and hide or remove the 'erase' entry
> action from the palette in the Journal.  This would force intentional
> erasure to occur in the Home list view, where the intent may be clearer.
>
> Alternatively, erasure from the Journal could be disabled for these entries
> unless they were in a filtered, Journal view (by their kind, a kind which
> currently is not available in the filter list).
>
>   --Fred
>
> [1] This discussion thread,
> http://lists.sugarlabs.org/archive/sugar-devel/2010-July/025615.html, and
> this wiki page, http://wiki.sugarlabs.org/go/Talk:Features/Content_support,
> describes a Journal group design for supporting Activity and content
> grouping.
>

>From http://bugs.sugarlabs.org/ticket/1512#comment:4 :

Replying to FGrose:
"This behavior in the Journal is inconsistent with other 'installed'
Activities, which are erased (un-installed) with a warning dialog from the
Home list view."


I agree with this. In the practice it gets very confusing for everyone,
mostly because there is no warning at all.

I really do not share the idea of bounding the installed activity with the
bundle that it was used for "installing". In the practice (again) the
current behavior just produces an unnecessary storage space waste (mostly
because there could be many bundles in the journal for the same activity).


The solution I found for this issue is jut not to delete de installed
version. Please see the attachment.
(here:)
>From dcafb30f3e96eaf0beaa41277d49f1bf8f0c3587 Mon Sep 17 00:00:00 2001
From: Martin Abente 
Date: Wed, 28 Jul 2010 17:53:30 -0400
Subject: [PATCH] Journal xobundle removal wont remove installed one
Organization: Paraguay Educa

Journal Xo bundles removal also removes the installed activity. There
are many scenarios where this behavior is it not desired. Therefore it
needs to be changed.
---
 src/jarabe/journal/palettes.py |5 -
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/src/jarabe/journal/palettes.py b/src/jarabe/journal/palettes.py
index 0e7702d..7c3e5ff 100644
Index: src/jarabe/journal/palettes.py
===
--- a/src/jarabe/journal/palettes.py
+++ b/src/jarabe/journal/palettes.py
@@ -128,11 +128,6 @@
 self._temp_file_path = None

 def __erase_activate_cb(self, menu_item):
-registry = bundleregistry.get_registry()
-
-bundle = misc.get_bundle(self._metadata)
-if bundle is not None and registry.is_installed(bundle):
-registry.uninstall(bundle)
 model.delete(self._metadata['uid'])

 def __detail_activate_cb(self, menu_item):

This is probably the simplest fix.

The bundle installation event records were kept in the Journal  as a record
of learner events, but as we've experienced, they provide little, lasting
value and were wired with destructive behavior.

(When we implement Journal grouping or multi Journals, they could presumably
have counterpart entries in the 'System' Journal filter, even after they
were scrubbed from 'My' Journal.)

   --Fred

post script:
We need to be careful with confusing terminology with Activities, bundles,
and events.
The code names, here, provide some guidance: (Journal) item metadata and
(Activity) bundle.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Displaying the current status of system resources (such as memory, cpu)

[Martin Abente]

On Thu, 29 Jul 2010 01:47:48 +0530, Anish Mangal
 wrote:
> The current implementation of the indicator that the paraguay builds
> use has static 'computer' icon for the frame. The palette menu
> displays the memory and cpu 'free' status by means of dynamically
> updating text-labels and progress bars.
> 
> 1. Would it be worthwhile to have the frame icon dynamically updated
> as well, displaying icons such as the ones given below:
> http://people.sugarlabs.org/anish/computer-happy.svg
> http://people.sugarlabs.org/anish/computer-normal.svg
> http://people.sugarlabs.org/anish/computer-sad.svg
> 
> The idea is to make the students aware of the system-load in
> response to their actions. Such an expressive means might be both
> intuitive and easy to interpret.
>

+1 Thats is what I think it should do, even when bars and percentages are
very useful, expressive icons can be far more effective to communicate the
overall status. 
 
> 2. Should the progress bars' 'filled' portion correspond to resources'
> 'in-use' or 'free' percentage. Currently, a 100% free CPU would mean a
> full progress bar in the palette menu. This will probably need to
> change since it is the opposite to how the journal space is
> represented in its corresponding progress bar.
> 

I agree with you, there should be some coherence with the bar usage, I
think anything will be ok always is coherent regardless from how we use the
bar.

> --
> Anish Mangal
> an...@sugarlabs.org
> 
> On Thu, Jun 17, 2010 at 2:41 PM, Martin Dengler
>  wrote:
>> On Wed, Jun 16, 2010 at 09:17:37AM +1000, fors...@ozonline.com.au
wrote:
>>> > Furthermore, what all system parameters should be made available
>>> > through such a means (such as free memory, and cpu load)?
>>> > Suggestions and opinions welcome!
>>>
>>> Time and date would be good.
>>
>> We've been there:
>>
>>
http://wiki.laptop.org/go/User:MartinDengler#Add_a_clock_.28to_the_frame.29
>> http://lists.sugarlabs.org/archive/sugar-devel/2009-May/014270.html
>>
>>> Tony
>>
>> Martin
>>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Displaying the current status of system resources (such as memory, cpu)

[Anish Mangal]

The current implementation of the indicator that the paraguay builds
use has static 'computer' icon for the frame. The palette menu
displays the memory and cpu 'free' status by means of dynamically
updating text-labels and progress bars.

1. Would it be worthwhile to have the frame icon dynamically updated
as well, displaying icons such as the ones given below:
http://people.sugarlabs.org/anish/computer-happy.svg
http://people.sugarlabs.org/anish/computer-normal.svg
http://people.sugarlabs.org/anish/computer-sad.svg

The idea is to make the students aware of the system-load in
response to their actions. Such an expressive means might be both
intuitive and easy to interpret.

2. Should the progress bars' 'filled' portion correspond to resources'
'in-use' or 'free' percentage. Currently, a 100% free CPU would mean a
full progress bar in the palette menu. This will probably need to
change since it is the opposite to how the journal space is
represented in its corresponding progress bar.

--
Anish Mangal
an...@sugarlabs.org

On Thu, Jun 17, 2010 at 2:41 PM, Martin Dengler
 wrote:
> On Wed, Jun 16, 2010 at 09:17:37AM +1000, fors...@ozonline.com.au wrote:
>> > Furthermore, what all system parameters should be made available
>> > through such a means (such as free memory, and cpu load)?
>> > Suggestions and opinions welcome!
>>
>> Time and date would be good.
>
> We've been there:
>
> http://wiki.laptop.org/go/User:MartinDengler#Add_a_clock_.28to_the_frame.29
> http://lists.sugarlabs.org/archive/sugar-devel/2009-May/014270.html
>
>> Tony
>
> Martin
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [PATCH] Add icons for memory and cpu resource indicator

[anishmangal2002]

This patch adds the following for svg icons for the memory and cpu
usage indicator frame icon.

computer-happy
computer-normal
computer-sad
computer-error

Signed-off-by: anishmangal2002 
---
 icons/scalable/device/Makefile.am |4 
 icons/scalable/device/computer-error.svg  |   11 +++
 icons/scalable/device/computer-happy.svg  |   13 +
 icons/scalable/device/computer-normal.svg |   11 +++
 icons/scalable/device/computer-sad.svg|   12 
 5 files changed, 51 insertions(+), 0 deletions(-)
 create mode 100644 icons/scalable/device/computer-error.svg
 create mode 100644 icons/scalable/device/computer-happy.svg
 create mode 100644 icons/scalable/device/computer-normal.svg
 create mode 100644 icons/scalable/device/computer-sad.svg

diff --git a/icons/scalable/device/Makefile.am 
b/icons/scalable/device/Makefile.am
index 28818ab..4ab0a56 100644
--- a/icons/scalable/device/Makefile.am
+++ b/icons/scalable/device/Makefile.am
@@ -38,6 +38,10 @@ icon_DATA =  \
battery-charging-100.svg\
camera-external.svg \
camera.svg  \
+   computer-error.svg  \
+   computer-happy.svg  \
+   computer-normal.svg \
+   computer-sad.svg\
computer.svg\
computer-xo.svg \
drive.svg   \
diff --git a/icons/scalable/device/computer-error.svg 
b/icons/scalable/device/computer-error.svg
new file mode 100644
index 000..ca280d3
--- /dev/null
+++ b/icons/scalable/device/computer-error.svg
@@ -0,0 +1,11 @@
+
+http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd' [
+   
+   
+]>
+http://www.w3.org/2000/svg"; 
xmlns:svg="http://www.w3.org/2000/svg";>
+   
+   
+
\ No newline at end of file
diff --git a/icons/scalable/device/computer-happy.svg 
b/icons/scalable/device/computer-happy.svg
new file mode 100644
index 000..4f23ce1
--- /dev/null
+++ b/icons/scalable/device/computer-happy.svg
@@ -0,0 +1,13 @@
+
+http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd' [
+   
+   
+]>
+http://www.w3.org/2000/svg"; 
xmlns:svg="http://www.w3.org/2000/svg";>
+   
+   
+
+
diff --git a/icons/scalable/device/computer-normal.svg 
b/icons/scalable/device/computer-normal.svg
new file mode 100644
index 000..144e123
--- /dev/null
+++ b/icons/scalable/device/computer-normal.svg
@@ -0,0 +1,11 @@
+
+http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd' [
+   
+   
+]>
+http://www.w3.org/2000/svg"; 
xmlns:svg="http://www.w3.org/2000/svg";>
+   
+   
+
\ No newline at end of file
diff --git a/icons/scalable/device/computer-sad.svg 
b/icons/scalable/device/computer-sad.svg
new file mode 100644
index 000..41ab01e
--- /dev/null
+++ b/icons/scalable/device/computer-sad.svg
@@ -0,0 +1,12 @@
+
+http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd' [
+   
+   
+]>
+http://www.w3.org/2000/svg"; 
xmlns:svg="http://www.w3.org/2000/svg";>
+   
+   
+
-- 
1.7.1

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [PATCH] Add cpu and memory resource indicator to frame

[anishmangal2002]

This patch adds an icon to the frame, whose palette
menu displays the memory and cpu resources. For computing
free memory, the code reads the /proc/meminfo file (thanks
quozl) and for computing cpu usage, the code reads the
/proc/stat file.

The frame icon is updated after every 5 seconds if required.
Similarly, the palette menu entries are updated after every
5 seconds as well.

Signed-off-by: anishmangal2002 
---
 extensions/deviceicon/Makefile.am  |3 +-
 extensions/deviceicon/resources.py |  206 
 2 files changed, 208 insertions(+), 1 deletions(-)
 create mode 100644 extensions/deviceicon/resources.py

diff --git a/extensions/deviceicon/Makefile.am 
b/extensions/deviceicon/Makefile.am
index 8a2e765..038c059 100644
--- a/extensions/deviceicon/Makefile.am
+++ b/extensions/deviceicon/Makefile.am
@@ -5,4 +5,5 @@ sugar_PYTHON =  \
battery.py  \
network.py  \
speaker.py  \
-   volume.py
+   volume.py   \
+   resources.py
diff --git a/extensions/deviceicon/resources.py 
b/extensions/deviceicon/resources.py
new file mode 100644
index 000..331459d
--- /dev/null
+++ b/extensions/deviceicon/resources.py
@@ -0,0 +1,206 @@
+# Copyright (C) Anish Mangal 
+#
+# 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 2 of the License, or
+# (at your option) any later version.
+#
+# 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, write to the Free Software
+# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+
+from gettext import gettext as _
+import logging
+import os
+
+import gobject
+import gtk
+import gconf
+
+from sugar.graphics.tray import TrayIcon
+from sugar.graphics.xocolor import XoColor
+from sugar.graphics.palette import Palette
+from sugar.graphics import style
+
+_SYSTEM_MOODS = ['-sad', '-normal', '-happy']
+_ICON_NAME = 'computer'
+
+class DeviceView(TrayIcon):
+
+FRAME_POSITION_RELATIVE = 500
+
+def __init__(self):
+client = gconf.client_get_default()
+self._color = XoColor(client.get_string('/desktop/sugar/user/color'))
+TrayIcon.__init__(self, icon_name=_ICON_NAME, xo_color=self._color)
+self.create_palette()
+
+def create_palette(self):
+logging.debug('palette created')
+self.palette = ResourcePalette(_('System resources'))
+self.palette.set_group_id('frame')
+self.palette.add_timer()
+self.palette.connect('system-mood-changed',
+self._system_mood_changed_cb)
+return self.palette
+
+def _system_mood_changed_cb(self, gobject, mood):
+self.icon.props.icon_name = _ICON_NAME + mood
+
+class ResourcePalette(Palette):
+__gsignals__ = {
+'system-mood-changed': (gobject.SIGNAL_RUN_FIRST,
+   gobject.TYPE_NONE,
+   ([str]))
+}
+
+def __init__(self, primary_text):
+Palette.__init__(self, label=primary_text)
+
+self.vbox = gtk.VBox()
+self.set_content(self.vbox)
+
+self._cpu_text = gtk.Label()
+self.vbox.pack_start(self._cpu_text, padding=style.DEFAULT_PADDING)
+self._cpu_bar = gtk.ProgressBar()
+self._cpu_bar.set_size_request(
+style.zoom(style.GRID_CELL_SIZE * 4), -1)
+self.vbox.pack_start(self._cpu_bar, padding=style.DEFAULT_PADDING)
+
+self._memory_text = gtk.Label()
+self.vbox.pack_start(self._memory_text, padding=style.DEFAULT_PADDING)
+self._memory_bar = gtk.ProgressBar()
+self._memory_bar.set_size_request(
+style.zoom(style.GRID_CELL_SIZE * 4), -1)
+self.vbox.pack_start(self._memory_bar, padding=style.DEFAULT_PADDING)
+
+try:
+self._cpu_times = self._get_cpu_times_list()
+except IOError:
+logging.exception('An error ocurred while attempting to '
+'read /proc/stat')
+self._stop_computing_statistics()
+
+self.vbox.show()
+self._cpu_text.show()
+self._cpu_bar.show()
+self._memory_text.show()
+self._memory_bar.show()
+
+def add_timer(self):
+self._timer = gobject.timeout_add(5000, self.__timer_cb)
+
+def _get_cpu_times_list(self):
+"""Return various cpu times as read from /proc/stat
+
+This method returns the following cpu times measured
+in jiffies (1/100 of a second for x86 systems)
+as an ordered list of numbers - [user, nice,
+system, idle, iowait] where,
+
+user: norm

Re: [Sugar-devel] [PATCH] Add cpu and memory resource indicator to frame

[Anish Mangal]

Sorry! I thought the attachments would remain as is. I'll git send-email this.


On Thu, Jul 29, 2010 at 1:09 AM, Anish Mangal  wrote:
> Thank you for reviewing this patch. However, after receiving feedback
> from Py. I've modified some of its functionality. The two patches
> attached implement that functionality. I've updated the parallel
> thread "[DESIGN] Displaying the current status of system resources
> (such as memory, cpu)" to augment further discussion on this.
>
> --
> Anish
>
> On Sat, Jul 10, 2010 at 3:09 PM, Marco Pesenti Gritti  
> wrote:
>> On 10 Jul 2010, at 08:43, Anish Mangal  wrote:
 diff --git a/extensions/deviceicon/resources.py 
 b/extensions/deviceicon/resources.py
 new file mode 100644
 index 000..7503bef
 --- /dev/null
 +++ b/extensions/deviceicon/resources.py
 @@ -0,0 +1,188 @@
 +# Copyright (C) Anish Mangal 
 +#
 +# 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 2 of the License, or
 +# (at your option) any later version.
 +#
 +# 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, write to the Free Software
 +# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  
 USA
 +
 +from gettext import gettext as _
 +import logging
 +import os
 +
 +import gobject
 +import gtk
 +import gconf
 +
 +from sugar.graphics.tray import TrayIcon
 +from sugar.graphics.xocolor import XoColor
 +from sugar.graphics.palette import Palette
 +from sugar.graphics import style
 +
 +from jarabe.frame.frameinvoker import FrameWidgetInvoker
 +
 +class DeviceView(TrayIcon):
 +
 +    FRAME_POSITION_RELATIVE = 500
 +
 +    def __init__(self):
 +        client = gconf.client_get_default()
 +        color = XoColor(client.get_string('/desktop/sugar/user/color'))
 +        TrayIcon.__init__(self, icon_name='computer', xo_color=color)
 +        self.set_palette_invoker(FrameWidgetInvoker(self))
 +
 +    def create_palette(self):
 +        palette = ResourcePalette(_('System resources'))
 +        palette.set_group_id('frame')
 +        return palette
 +
 +class ResourcePalette(Palette):
 +
 +    def __init__(self, primary_text):
 +        Palette.__init__(self, label=primary_text)
 +
 +        self._popup_cb_id = self.connect('popup', self._popup_cb)
 +        self._popdown_cb_id = self.connect('popdown', self._popdown_cb)
 +
 +        self.vbox = gtk.VBox()
 +        self.set_content(self.vbox)
 +
 +        self._cpu_text = gtk.Label()
 +        self.vbox.pack_start(self._cpu_text, 
 padding=style.DEFAULT_PADDING)
 +        self._cpu_text.show()
 +
 +        self._cpu_bar = gtk.ProgressBar()
 +        self._cpu_bar.set_size_request(
 +            style.zoom(style.GRID_CELL_SIZE * 4), -1)
 +        self.vbox.pack_start(self._cpu_bar, padding=style.DEFAULT_PADDING)
 +        self._cpu_bar.show()
 +
 +        self._memory_text = gtk.Label()
 +        self.vbox.pack_start(self._memory_text, 
 padding=style.DEFAULT_PADDING)
 +        self._memory_text.show()
 +
 +        self._memory_bar = gtk.ProgressBar()
 +        self._memory_bar.set_size_request(
 +            style.zoom(style.GRID_CELL_SIZE * 4), -1)
 +        self.vbox.pack_start(self._memory_bar, 
 padding=style.DEFAULT_PADDING)
 +        self._memory_bar.show()
 +
 +        self.vbox.show()
 +
 +        try:
 +            self._cpu_times = self._get_cpu_times_list()
 +        except Exception:
 +            logging.exception('An error ocurred while attempting to '
 +                'read /proc/stat')
>>
>> Which exceptions do you expect to happen and in which situations? Catch all 
>> exceptions are generally a bad idea.
>>
>>
 +            self._remove_callbacks()
 +
 +    def _get_cpu_times_list(self):
 +        """Return various cpu times as read from /proc/stat
 +
 +        This method returns the following cpu times measured
 +        in jiffies (1/100 of a second for x86 systems)
 +        as an ordered list of numbers - [user, nice,
 +        system, idle, iowait] where,
 +
 +        user: normal processes executing in user mode
 +        nice: niced processes executing in user mode
 +        system: processes executing in kernel mode
 +        idle: twiddling thumb

Re: [Sugar-devel] [PATCH] Add cpu and memory resource indicator to frame

[Anish Mangal]

Thank you for reviewing this patch. However, after receiving feedback
from Py. I've modified some of its functionality. The two patches
attached implement that functionality. I've updated the parallel
thread "[DESIGN] Displaying the current status of system resources
(such as memory, cpu)" to augment further discussion on this.

--
Anish

On Sat, Jul 10, 2010 at 3:09 PM, Marco Pesenti Gritti  wrote:
> On 10 Jul 2010, at 08:43, Anish Mangal  wrote:
>>> diff --git a/extensions/deviceicon/resources.py 
>>> b/extensions/deviceicon/resources.py
>>> new file mode 100644
>>> index 000..7503bef
>>> --- /dev/null
>>> +++ b/extensions/deviceicon/resources.py
>>> @@ -0,0 +1,188 @@
>>> +# Copyright (C) Anish Mangal 
>>> +#
>>> +# 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 2 of the License, or
>>> +# (at your option) any later version.
>>> +#
>>> +# 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, write to the Free Software
>>> +# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  
>>> USA
>>> +
>>> +from gettext import gettext as _
>>> +import logging
>>> +import os
>>> +
>>> +import gobject
>>> +import gtk
>>> +import gconf
>>> +
>>> +from sugar.graphics.tray import TrayIcon
>>> +from sugar.graphics.xocolor import XoColor
>>> +from sugar.graphics.palette import Palette
>>> +from sugar.graphics import style
>>> +
>>> +from jarabe.frame.frameinvoker import FrameWidgetInvoker
>>> +
>>> +class DeviceView(TrayIcon):
>>> +
>>> +    FRAME_POSITION_RELATIVE = 500
>>> +
>>> +    def __init__(self):
>>> +        client = gconf.client_get_default()
>>> +        color = XoColor(client.get_string('/desktop/sugar/user/color'))
>>> +        TrayIcon.__init__(self, icon_name='computer', xo_color=color)
>>> +        self.set_palette_invoker(FrameWidgetInvoker(self))
>>> +
>>> +    def create_palette(self):
>>> +        palette = ResourcePalette(_('System resources'))
>>> +        palette.set_group_id('frame')
>>> +        return palette
>>> +
>>> +class ResourcePalette(Palette):
>>> +
>>> +    def __init__(self, primary_text):
>>> +        Palette.__init__(self, label=primary_text)
>>> +
>>> +        self._popup_cb_id = self.connect('popup', self._popup_cb)
>>> +        self._popdown_cb_id = self.connect('popdown', self._popdown_cb)
>>> +
>>> +        self.vbox = gtk.VBox()
>>> +        self.set_content(self.vbox)
>>> +
>>> +        self._cpu_text = gtk.Label()
>>> +        self.vbox.pack_start(self._cpu_text, padding=style.DEFAULT_PADDING)
>>> +        self._cpu_text.show()
>>> +
>>> +        self._cpu_bar = gtk.ProgressBar()
>>> +        self._cpu_bar.set_size_request(
>>> +            style.zoom(style.GRID_CELL_SIZE * 4), -1)
>>> +        self.vbox.pack_start(self._cpu_bar, padding=style.DEFAULT_PADDING)
>>> +        self._cpu_bar.show()
>>> +
>>> +        self._memory_text = gtk.Label()
>>> +        self.vbox.pack_start(self._memory_text, 
>>> padding=style.DEFAULT_PADDING)
>>> +        self._memory_text.show()
>>> +
>>> +        self._memory_bar = gtk.ProgressBar()
>>> +        self._memory_bar.set_size_request(
>>> +            style.zoom(style.GRID_CELL_SIZE * 4), -1)
>>> +        self.vbox.pack_start(self._memory_bar, 
>>> padding=style.DEFAULT_PADDING)
>>> +        self._memory_bar.show()
>>> +
>>> +        self.vbox.show()
>>> +
>>> +        try:
>>> +            self._cpu_times = self._get_cpu_times_list()
>>> +        except Exception:
>>> +            logging.exception('An error ocurred while attempting to '
>>> +                'read /proc/stat')
>
> Which exceptions do you expect to happen and in which situations? Catch all 
> exceptions are generally a bad idea.
>
>
>>> +            self._remove_callbacks()
>>> +
>>> +    def _get_cpu_times_list(self):
>>> +        """Return various cpu times as read from /proc/stat
>>> +
>>> +        This method returns the following cpu times measured
>>> +        in jiffies (1/100 of a second for x86 systems)
>>> +        as an ordered list of numbers - [user, nice,
>>> +        system, idle, iowait] where,
>>> +
>>> +        user: normal processes executing in user mode
>>> +        nice: niced processes executing in user mode
>>> +        system: processes executing in kernel mode
>>> +        idle: twiddling thumbs
>>> +        iowait: waiting for I/O to complete
>>> +
>>> +        Note: For systems having 2 or more CPU's, the above
>>> +        numbers would be the cumulative sum of these times
>>> +        for all CPU's present in the system.
>>> +
>>> +        """
>>> +        retu

Re: [Sugar-devel] [RELEASE] sugar-0.84.19

[Jonas Smedegaard]

On Wed, Jul 28, 2010 at 12:18:59PM -0400, d...@laptop.org wrote:

== Source ==

http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.84.19.tar.bz2


Great.


Please remember to tag the release and push that tag.

Apparently it is missing currently.


Regards,

  - Jonas

--
  * Jonas Smedegaard - idealist & Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [RELEASE] sugar-0.84.19

[dsd]

== Source ==

http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.84.19.tar.bz2

== News ==

* logging cleanup failure prevents session start #1720
* add journal and frame key bindings (F5/F6)

== Test cases ==

#1720

Fill disk or change ownership of .sugar/default/logs to prevent write by
user, then start session. Expected result: session will start. Current
result: session fails to start, stderr of sugar-session process shows an
IOError exception.


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Journal and Updating Software Process

[Frederick Grose]

On Wed, Jul 28, 2010 at 10:02 AM, Daniel Castelo <
dcast...@plan.ceibal.edu.uy> wrote:

> On Tue, Jul 27, 2010 at 11:51 PM, Frederick Grose wrote:
>
>> On Tue, Jul 27, 2010 at 9:37 PM, James Cameron  wrote:
>>
>>> On Tue, Jul 27, 2010 at 06:37:18PM -0300, Daniel Castelo wrote:
>>> > * The activities are updated
>>>
>>> With "Software update" or manually using Browse?
>>>
>>> > * The user delete the journal entry with the activity bundle
>>> > downloaded for this updating process.
>>> >
>>> > The result of this is that the activity is deleted from sugar
>>>
>>> I've seen this on Sugar 0.84 if the activity was updated using Browse,
>>> but not if the activity was updated using "Software update".
>>>
>>> > This behavour is normal? Should I reported this as a bug?
>>>
>>> If you think it is a bug, then check for it in bugs.sugarlabs.org
>>
>>
>> See https://bugs.sugarlabs.org/ticket/1512
>>
>
> Great. Thanks!
> The trac ticket suggest a new behavour:
>
> "The download event record, as a system event, might have a 'hide event'
> option or not be erasable. The code bundle behind the event should, perhaps,
> only be erased from the Home list view (installed-Activity-code-bundle
> management), while system or Activity events and their associated object
> instances are managed from the Journal of Activity event instances."
>
> Which is the next step that I should follow to solve this issue? I suposse
> that is to discuss in this email list which could be the best solution.
>

As noted, the problem of inadvertent deletion of updated or newly added
Activity bundles may occur in the Journal or in the Home list view (through
the erase action in an extended palette).  The most comprehensive solution
might involve grouping of Journal items [1], but that won't be quick.

A quicker solution may be to recognize the Journal entry type or kind in the
Journal (if that is sufficient) and hide or remove the 'erase' entry action
from the palette in the Journal.  This would force intentional erasure to
occur in the Home list view, where the intent may be clearer.

Alternatively, erasure from the Journal could be disabled for these entries
unless they were in a filtered, Journal view (by their kind, a kind which
currently is not available in the filter list).

  --Fred

[1] This discussion thread,
http://lists.sugarlabs.org/archive/sugar-devel/2010-July/025615.html, and
this wiki page, http://wiki.sugarlabs.org/go/Talk:Features/Content_support,
describes a Journal group design for supporting Activity and content
grouping.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Evince browser plugin

[Lucian Branescu]

Thanks. Rebasing to 2.28 shouldn't be that hard, but 2.30 has had
major API changes, so it would have to be ported.

For now we've left Browse PDF support for later since we're having a
lot of trouble getting anything working in the first place
(pywebkitgtk issues, no libsoup python binding, etc.)

On 28 July 2010 00:29, Marco Pesenti Gritti  wrote:
> Hi Lucian,
>
> sorry for the long delay, here is the git repository with the evince
> browser plugin.
>
> http://git.sugarlabs.org/projects/evince-browser-plugin
>
> The changes are on the plugin branch. It builds and seems to work fine
> for me in Lucid. Unfortunately it's still based on 2.25... I haven't
> tried rebasing to master, so I'm not sure how much work that would
> involve.
>
> Marco
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] touchpad section for Sugar Control Panel

[Sascha Silbe]

Excerpts from Paul Fox's message of Wed Jul 28 16:01:22 +0200 2010:
> sascha wrote:
>  > Even your latest patch still contains code that is specific to OLPC builds 
> and will break on other systems.
>  > Of course it's perfectly fine for you to say you only care about OLPC 
> builds for XO-1 (because the number of XO-1s running non-OLPC builds is 
> minimal, especially if you don't count developers). But in that case your 
> patch should be included in the OLPC builds, not in Sugar mainline.
> 
> can you remind me of the specific issue(s) here?
I can remember two issues (there might be others as well):
- hardcoded, absolute path (/home/olpc/whatever)
- reliance on code that is shipped in olpc-utils

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] Journal and Updating Software Process

[Daniel Castelo]

On Tue, Jul 27, 2010 at 11:51 PM, Frederick Grose  wrote:

> On Tue, Jul 27, 2010 at 9:37 PM, James Cameron  wrote:
>
>> On Tue, Jul 27, 2010 at 06:37:18PM -0300, Daniel Castelo wrote:
>> > * The activities are updated
>>
>> With "Software update" or manually using Browse?
>>
>> > * The user delete the journal entry with the activity bundle
>> > downloaded for this updating process.
>> >
>> > The result of this is that the activity is deleted from sugar
>>
>> I've seen this on Sugar 0.84 if the activity was updated using Browse,
>> but not if the activity was updated using "Software update".
>>
>> > This behavour is normal? Should I reported this as a bug?
>>
>> If you think it is a bug, then check for it in bugs.sugarlabs.org
>
>
> See https://bugs.sugarlabs.org/ticket/1512
>

Great. Thanks!
The trac ticket suggest a new behavour:

"The download event record, as a system event, might have a 'hide event'
option or not be erasable. The code bundle behind the event should, perhaps,
only be erased from the Home list view (installed-Activity-code-bundle
management), while system or Activity events and their associated object
instances are managed from the Journal of Activity event instances."

Which is the next step that I should follow to solve this issue? I suposse
that is to discuss in this email list which could be the best solution.


>  
>
>> or
>> report it there.  I'm not sure what the behaviour should be.  I'd be
>> happy to see it fixed though, so that a user would have to both remove
>> the download and remove the activity.
>>
>> --
>> James Cameron
>
>


-- 
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

Re: [Sugar-devel] [PATCH] touchpad section for Sugar Control Panel

[Paul Fox]

sascha wrote:
 > 
 > Excerpts from Walter Bender's message of Tue Jul 27 00:01:01 +0200 2010:
 > 
 > > Not sure what else I can do. I've incorporated all of the suggestion
 > > from Marco et al. Just awaiting final review.
 > Even your latest patch still contains code that is specific to OLPC builds 
 > and will break on other systems.
 > Of course it's perfectly fine for you to say you only care about OLPC builds 
 > for XO-1 (because the number of XO-1s running non-OLPC builds is minimal, 
 > especially if you don't count developers). But in that case your patch 
 > should be included in the OLPC builds, not in Sugar mainline.

can you remind me of the specific issue(s) here?

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH] touchpad section for Sugar Control Panel

[Sascha Silbe]

Excerpts from Walter Bender's message of Wed Jul 28 13:31:36 +0200 2010:

> > Even your latest patch still contains code that is specific to OLPC builds 
> > and will break on other systems.
> I understand that it is specific to OLPC, since it is for supporting
> hardware that is only found on the OLPC.
You're mixing terms that are related, but differ in their exact meaning. This 
seems to confuse you:

> But this is the first I have heard that it will break on other systems. Is my 
> test in setup somehow
> inadequate?

This is a feature specific to XO-1 *hardware*. You have written it in a way 
that makes it work only when running a specific *distribution* that has been 
developed by OLPC (upper-case I guess). This distribution (derived from Fedora) 
has no name of it's own, so people just talk about "OLPC builds" to refer to it.
If somebody - like me - runs a non-OLPC distribution on their XO-1, your patch 
will break. I haven't checked whether it would just render the feature unusable 
or break unrelated parts (e.g. the keyboard selection is known to make Sugar 
fail to start up at all on armel [1]).

> > Of course it's perfectly fine for you to say you only care about OLPC 
> > builds for XO-1 (because the number of XO-1s running non-OLPC builds is 
> > minimal, especially if you don't count developers). But in that case your 
> > patch should be included in the OLPC builds, not in Sugar mainline.
> To include this in OLPC builds and not Sugar in general is a
> reasonable argument. The only counter argument I could make would be
> that some portion of the OLPC users are relying on builds that are not
> provided directly by OLPC.
There are two options:

1. They indeed use a different distribution. In that case your patch wouldn't 
work for them in the first place.
2. They are running a derivative of the OLPC distribution. In that case they 
should be able to pick up Sugar packages with your patch from OLPC.

Sascha

[1] https://bugs.sugarlabs.org/ticket/1672


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] touchpad section for Sugar Control Panel

[Walter Bender]

On Wed, Jul 28, 2010 at 3:48 AM, Sascha Silbe
 wrote:
> Excerpts from Walter Bender's message of Tue Jul 27 00:01:01 +0200 2010:
>
>> Not sure what else I can do. I've incorporated all of the suggestion
>> from Marco et al. Just awaiting final review.
> Even your latest patch still contains code that is specific to OLPC builds 
> and will break on other systems.

I understand that it is specific to OLPC, since it is for supporting
hardware that is only found on the OLPC. But this is the first I have
heard that it will break on other systems. Is my test in setup somehow
inadequate?

> Of course it's perfectly fine for you to say you only care about OLPC builds 
> for XO-1 (because the number of XO-1s running non-OLPC builds is minimal, 
> especially if you don't count developers). But in that case your patch should 
> be included in the OLPC builds, not in Sugar mainline.

To include this in OLPC builds and not Sugar in general is a
reasonable argument. The only counter argument I could make would be
that some portion of the OLPC users are relying on builds that are not
provided directly by OLPC. As long as there is a way to pull these
bits in for them, it matters not to me whom provides them.

thanks.

-walter

>
> Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
>
> ___
> 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] Changing bundle_id and version scheme for Etoys

[Lucian Branescu]

On 27 July 2010 23:57, Bernie Innocenti  wrote:
> On Tue, 2010-07-27 at 18:21 -0400, C. Scott Ananian wrote:
>
>> This is a nicely decentralized mechanism for choosing identifiers
>> which are guaranteed by construction never to conflict.
>
> It is indeed a simple and nice scheme, but why is such uniqueness a
> desiderable feature when developers can--and in fact *do*--often
> distribute forks of existing activities?
>
> Lucian has just created a fork of Browse and ParaguayEduca has a fork of
> XoIRC and VncLauncher on its wiki. In all cases, the bundle_id was
> intentionally left unmodified to ensure upgrades would work.

Actually, after careful consideration I've rebranded Browse-webkit to Surf.

> (if the bundle_id were instead changed, funny things would happen when a
> user tries to install both bundles on the same machine).
>
>
>> If sugarlabs is willing to maintain a mechanism for ensuring
>> uniqueness, feel free to prepend org.sugarlabs to whatever activities
>> you have "registered".
>
> A good surrogate could be that no two activities with the same name can
> be uploaded to ASLO.
>
> Without a fancy scheme for signed bundles, nothing forbids people from
> distributing bundles with conflicting names from other sites, regardless
> of what uniqueness scheme gets chosen.
>
>
>> > For all other purposes, the bundle_id is just a string which could
>> > contain anything. The bundle_id "org.tuxpaint.sugar-is-lame" worked
>> > flawlessly for all this time.
>>
>> Yes, this identifier is childish, but conforms precisely to the rules
>> outlined above, which ensure its uniqueness.
>
> It's not actually conforming, it has hyphens! ;-)
>
> --
>   // 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] touchpad section for Sugar Control Panel

[Sascha Silbe]

Excerpts from Walter Bender's message of Tue Jul 27 00:01:01 +0200 2010:

> Not sure what else I can do. I've incorporated all of the suggestion
> from Marco et al. Just awaiting final review.
Even your latest patch still contains code that is specific to OLPC builds and 
will break on other systems.
Of course it's perfectly fine for you to say you only care about OLPC builds 
for XO-1 (because the number of XO-1s running non-OLPC builds is minimal, 
especially if you don't count developers). But in that case your patch should 
be included in the OLPC builds, not in Sugar mainline.

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