Re: [Sugar-devel] [PATCH 1/3] Touchpad extension for the frame
I think I addressed all of the issues raised by Marco and Anish:
---
extensions/deviceicon/touchpad.py | 129 +
1 files changed, 129 insertions(+), 0 deletions(-)
create mode 100644 extensions/deviceicon/touchpad.py
diff --git a/extensions/deviceicon/touchpad.py
b/extensions/deviceicon/touchpad.py
new file mode 100644
index 000..a182d9c
--- /dev/null
+++ b/extensions/deviceicon/touchpad.py
@@ -0,0 +1,129 @@
+# Copyright (C) 2010, Walter Bender, Sugar Labs
+#
+# 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 gtk
+import gconf
+import os
+
+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
+
+TOUCHPAD_MODES = ['capacitive', 'resistive']
+STATUS_TEXT = {TOUCHPAD_MODES[0]: _('finger'), TOUCHPAD_MODES[1]: _('stylus')}
+STATUS_ICON = {TOUCHPAD_MODES[0]: 'touchpad-' + TOUCHPAD_MODES[0],
+ TOUCHPAD_MODES[1]: 'touchpad-' + TOUCHPAD_MODES[1]}
+# FLAG_PATH is used to preserve status between boots.
+FLAG_PATH = '/home/olpc/.olpc-pentablet-mode'
+# NODE_PATH is used to communicate with the touchpad device.
+NODE_PATH = '/sys/devices/platform/i8042/serio1/ptmode'
+
+class DeviceView(TrayIcon):
+""" Manage the touchpad mode from the device palette on the Frame. """
+
+FRAME_POSITION_RELATIVE = 500
+
+def __init__(self):
+""" Create the touchpad palette and display it on Frame. """
+icon_name = STATUS_ICON[read_touchpad_mode()]
+
+client = gconf.client_get_default()
+color = XoColor(client.get_string('/desktop/sugar/user/color'))
+TrayIcon.__init__(self, icon_name=icon_name, xo_color=color)
+
+self.set_palette_invoker(FrameWidgetInvoker(self))
+self.connect('button-release-event', self.__button_release_event_cb)
+
+def create_palette(self):
+""" On create, set the current mode """
+self.palette = ResourcePalette(_('My touchpad'), self.icon)
+self.palette.set_group_id('frame')
+return self.palette
+
+def __button_release_event_cb(self, widget, event):
+""" On button release, switch modes """
+self.palette.toggle_mode()
+return True
+
+
+class ResourcePalette(Palette):
+""" Query the current state of the touchpad and update the display. """
+
+def __init__(self, primary_text, icon):
+""" Get the status. """
+Palette.__init__(self, label=primary_text)
+
+self._icon = icon
+
+vbox = gtk.VBox()
+self.set_content(vbox)
+
+self._status_text = gtk.Label()
+vbox.pack_start(self._status_text, padding=style.DEFAULT_PADDING)
+self._status_text.show()
+
+vbox.show()
+
+self._mode = read_touchpad_mode()
+self._update()
+
+def _update(self):
+""" Update the label and icon based on the current mode. """
+self._status_text.set_label(STATUS_TEXT[self._mode])
+self._icon.props.icon_name = STATUS_ICON[self._mode]
+
+def toggle_mode(self):
+""" On mouse click, toggle the mode. """
+self._mode = TOUCHPAD_MODES[1 - TOUCHPAD_MODES.index(self._mode)]
+write_touchpad_mode(self._mode)
+self._update()
+
+
+def setup(tray):
+""" Only appears when the device exisits """
+if os.path.exists(NODE_PATH):
+tray.add_device(DeviceView())
+
+
+def read_touchpad_mode():
+""" Read the touchpad mode from the node path. """
+node_file_handle = open(NODE_PATH, "r")
+text = node_file_handle.read()
+node_file_handle.close()
+
+return TOUCHPAD_MODES[int(text[0])]
+
+
+def write_touchpad_mode(touchpad):
+""" Write the touchpad mode to the node path. """
+touchpad_mode_index = TOUCHPAD_MODES.index(touchpad)
+
+node_file_handle = open(NODE_PATH, "w")
+node_file_handle.write(str(touchpad_mode_index))
+node_file_handle.close()
+
+if touchpad_mode_index == 0:
+if os.path.exists(FLAG_PATH):
+os.remove(FLAG_PATH)
+else:
+flag_file_handle = open(FLAG_PATH, "w")
+flag_file_handle.close()
-walter
On Thu, Jul 8, 2010 at 7:19 PM, Marco Pesenti Gritti wrote:
> On 8 J
Re: [Sugar-devel] [PATCH 1/3] Touchpad extension for the frame
From my recent experience of getting a similar patch reviewed, I have
the following additional feedback :-)
> + vbox.pack_start(self._status_text, padding=10)
The padding shouldn't be hardcoded to a number of pixels, see the
constants in style.py. (maybe padding=style.DEFAULT_PADDING?)
> +def get_touchpad():
> + """ Get the touchpad mode. """
> + _file_handle = open(_NODE_PATH, "r")
> + _text = _file_handle.read()
> + _file_handle.close()
Maybe put this is a try... block?
> + if touchpad == 'capacitive':
> + if path.exists(_FLAG_PATH):
> + remove(_FLAG_PATH)
> + system("echo 0 > %s" % (_NODE_PATH))
> + else:
> + _file_handle = open(_FLAG_PATH, "w")
> + _file_handle.close()
> + system("echo 1 > %s" % (_NODE_PATH))
> + return
Tomeu will nag you about "" vs. '' in the system(...) calls ;)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH 1/3] Touchpad extension for the frame
Marco, It is a real pleasure to have you reengaged. Thanks for the feedback. regards. -walter On Thu, Jul 8, 2010 at 7:26 PM, Marco Pesenti Gritti wrote: > In general, this looks olpc specific right now, but I think it's fine to have > it upstream, we can abstract it more later if we need to support different > hardware. > > It's a while I don't code or review Sugar patches so I might very well be > missing things... And I can't really test the patch right now. > > Thanks! > Marco -- 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] [PATCH 3/3] Touchpad extension for the frame
Should be squashed with patch 2, to keep the tree functional. On 8 Jul 2010, at 17:24, Walter Bender wrote: > --- > icons/scalable/device/Makefile.am |4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > > diff --git a/icons/scalable/device/Makefile.am > b/icons/scalable/device/Makefile.am > index 28818ab..0d3f2fc 100644 > --- a/icons/scalable/device/Makefile.am > +++ b/icons/scalable/device/Makefile.am > @@ -84,7 +84,9 @@ icon_DATA = \ > speaker-muted-000.svg \ > speaker-muted-033.svg \ > speaker-muted-066.svg \ > - speaker-muted-100.svg > + speaker-muted-100.svg \ > +touchpad-capacitive.svg \ > +touchpad-resistive.svg > > EXTRA_DIST = $(icon_DATA) > > -- > 1.7.0.4 > > -- > Walter Bender > Sugar Labs > http://www.sugarlabs.org > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH 1/3] Touchpad extension for the frame
In general, this looks olpc specific right now, but I think it's fine to have it upstream, we can abstract it more later if we need to support different hardware. It's a while I don't code or review Sugar patches so I might very well be missing things... And I can't really test the patch right now. Thanks! Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH 1/3] Touchpad extension for the frame
On 8 Jul 2010, at 17:23, Walter Bender wrote:
> ---
> extensions/deviceicon/touchpad.py | 152 +
> 1 files changed, 152 insertions(+), 0 deletions(-)
> create mode 100644 extensions/deviceicon/touchpad.py
>
> diff --git a/extensions/deviceicon/touchpad.py
> b/extensions/deviceicon/touchpad.py
> new file mode 100644
> index 000..a182d9c
> --- /dev/null
> +++ b/extensions/deviceicon/touchpad.py
> @@ -0,0 +1,152 @@
> +# Copyright (C) 2010, Walter Bender, Sugar Labs
> +#
> +# 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 gtk
> +import gconf
> +from os import system, path, remove
The os import should be in the first block. I wouldn't import the methods,
prepending os. to the actual calls makes it clearer what the methods are doing.
> +from sugar.graphics.tray import TrayIcon
> +from sugar.graphics.xocolor import XoColor
> +from sugar.graphics.palette import Palette
> +from jarabe.frame.frameinvoker import FrameWidgetInvoker
> +
The jarabe import should be in a separate block.
> +_STATUS_TEXT = {'capacitive': _('finger'), 'resistive': _('stylus')}
> +_CAPACITIVE_ICON_NAME = 'touchpad-capacitive'
> +_RESISTIVE_ICON_NAME = 'touchpad-resistive'
> +_FLAG_PATH = '/home/olpc/.olpc-pentablet-mode'
> +_NODE_PATH = '/sys/devices/platform/i8042/serio1/ptmode'
I think we don't need to mark these has private, the plugins code is not
imported by other modules, so private/public doesn't matter.
> +
> +
One less new line :) I'm sure everyone has been missing my nitpicks!
> +class DeviceView(TrayIcon):
> +""" Manage the touchpad mode from the device palette on the Frame """
> +
> +FRAME_POSITION_RELATIVE = 500
> +
> +def __init__(self):
> +""" Create the touchpad palette and display it on Frame """
> +
> +# Only appears when the device exisits
> +if not path.exists(_NODE_PATH):
> +return
> +
Aborting constructions looks wrong, better to move the check to the setup
method.
> +if get_touchpad() == 'resistive':
> +icon_name = _RESISTIVE_ICON_NAME
> +else:
> +icon_name = _CAPACITIVE_ICON_NAME
It would be nice to use a dictionary like you did with the label.
> +
> +client = gconf.client_get_default()
> +color = XoColor(client.get_string('/desktop/sugar/user/color'))
> +TrayIcon.__init__(self, icon_name=icon_name, xo_color=
Splitting the blocks with a new line here would be more readable.
> +self.set_palette_invoker(FrameWidgetInvoker(self))
> +self.connect('button-release-event', self.__button_release_event_cb)
> +self.connect('expose-event', self.__expose_event_cb)
> +
> +def create_palette(self):
> +""" On create, set the current mode """
> +self.palette = ResourcePalette(_('My touchpad'), self.icon)
> +self.palette.set_group_id('frame')
> +return self.palette
> +
> +def __button_release_event_cb(self, widget, event):
> +""" On button release, switch modes """
> +self.palette.toggle_mode()
> +return True
> +
> +def __expose_event_cb(self, *args):
> +pass
>
Leftover? Seems unnecessary to connect the signal since you are just passing
then.
> +
> +class ResourcePalette(Palette):
> +""" Query the current state of the touchpad and update the display """
> +
> +def __init__(self, primary_text, icon):
> +""" Get the status """
> +Palette.__init__(self, label=primary_text)
> +
> +self._icon = icon
> +
> +self.connect('popup', self.__popup_cb)
> +self.connect('popdown', self.__popdown_cb)
> +
> +self.updating = False
> +
> +vbox = gtk.VBox()
> +self.set_content(vbox)
> +
> +self._status_text = gtk.Label()
> +vbox.pack_start(self._status_text, padding=10)
> +self._status_text.show()
> +
> +vbox.show()
> +
> +self._mode = get_touchpad()
> +self.set_mode_graphics()
> +
> +def set_mode_graphics(self):
Looks like this can be marked as private? update would be more appropriate then
set since you are not passing a mode.
> +""" Set the label and icon based on the current mode """
> +self._status_text
Re: [Sugar-devel] Opportunity: migration from Gconf to GSettings
On Thu, Jul 8, 2010 at 4:18 AM, Tomeu Vizoso wrote: > Wonder which backend would be most adequate for Sugar, dconf, gkeyfile, ...? Questions for whomever tackles this migration... Can we still get/set the values from cli, even when the gnome/sugar env is not running? IOWs... - can we set config values when building an image (from olpc-os-builder)? (where sugar/gnome/dbus/etc are not running)... - can we read config values from scripts triggered from cron or udev? (that don't share our envvars) cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Opportunity: migration from Gconf to GSettings
On Thu, Jul 8, 2010 at 9:18 AM, Tomeu Vizoso wrote: > On Thu, Jul 8, 2010 at 10:01, Simon Schampijer wrote: >> Hi, >> >> while drafting the 0.90 schedule [1] I came across the migration from >> Gconf to GSettings in GNOME [2]. This is dependent on introspection, so >> not something for 0.90 but would be nice to have it ready in 0.92. If >> someone wants to work already on it, it would be a valuable and highly >> appreciated task. > > Wonder which backend would be most adequate for Sugar, dconf, gkeyfile, ...? What impact does what gnome upstream uses or what a distribution uses/ Can you mix backends? Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Announce: OLPC software strategy.
Hi Sascha, > I trust the license will allow me to: 1. Build a new (complete, > working) firmware image 2. Install it on my own XO-1.75. > 3. Distribute the image (+ source) to other XO-1.75 users so they > can install it. We expect this to be no problem, just as building your own OFW+EC binary blob and redistributing them right now is no problem. (The encumbered PS/2 code we're talking about is already present in the XO-1 EC build.) > What about the compiler? IIUC currently a commercial compiler is > required. If that continues to be the case (as I expect it to), > would it be possible for OLPC to provide the (probably very few) > users interested in hacking on the EC code access to a machine > having this compiler installed? I.e. does the license OLPC has > for this compiler allow more than one user (on the same machine) > to use it (if necessary sequentially, ensured by using a lock > file) and would OLPC be willing to give users access to such a > machine? Good news here too: we've moved to the free SDCC compiler, so there should be no problem here. I don't know full details, but there have been some incompatibilities seen between SDCC and the EC code in the past, so staying with SDCC is going to be conditional on being able to find a way around those. SDCC is the plan, though. For more questions, I think we should move to the OLPC devel list, and I'll let Richard Smith answer because this is his project. :) - Chris. -- Chris Ball One Laptop Per Child ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design Team meeting (was: Re: UI experiments: pop-up menus and hot corners)
Thanks Sascha, On 8 Jul 2010, at 11:49, Sascha Silbe wrote: > Excerpts from Gary Martin's message of Thu Jul 08 09:13:23 + 2010: > >>> It would be great to hold Design Team meetings regularly (bi-weekly or at >>> least monthly). We have already queued up a lot to talk about again. >> >> Do you have specific items we can try to cover on the mail-list first? Real >> time design meetings are tough to schedule and (in my opinion) are usually >> better focused on trying to move forward a goal or two. > > These are the topics / open issues I've collected from the mailing > list and the bug tracker (see wiki page [1] for links to patches): > > - Journal backup UI (Patch from Martin Abente, Patch from Sascha Silbe) > - Alerts (Patch from Anish Mangal) and notifications > - Uncaught exception handler (#2063) > - How to handle start-up delay due to data store migration (#1546)? > - "Your Journal is empty" shown for unreadable storage media (#1810) > - invalid/unknown colors are shown as owner colors (#1750) > - Erasure of downloaded Activity entries in Journal permanently removes > the code bundle (#1512) > - Drop down menus give no indication of their existence, also are too > slow to load (#1169, Patch from Michael Stone) Oooh ouch, way to overwhelming for a realtime irc meeting, but as least has some over lap with my little reminder list, FWIW: - Start/resume UI work - Journal backup downstream deployment implementations - Touch/tablet UI work - Smolt CP icon for submitting HW profiles #949 - CP icons for HW not present can be hidden (David)? > There are also 23 open tickets [2] filed against the design component in Thanks for the reminder ;) yes I have a few of these tickets open in my browser tabs, usually the more actionable 'artwork wanted' type things that I think I might get to. Again not really focused enough for a meeting agenda, unless it just a generally reminder for interested parties to look through the list if they have free cycles. FWIW2, for me, the next design meeting is focused on the Start/resume design efforts, I'm sure we'll likely cover a some other items at the end of the meeting if folks have time, but I'd hate to see the hopefully productive time deteriorate into what I watched happening at the last dev meeting. Regards, --Gary > Sascha > > [1] http://wiki.sugarlabs.org/go/Design_Team/Meetings > [2] > https://bugs.sugarlabs.org/query?component=design&status=accepted&status=assigned&status=new&status=reopened > -- > 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH 3/3] Touchpad extension for the frame
--- icons/scalable/device/Makefile.am |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/icons/scalable/device/Makefile.am b/icons/scalable/device/Makefile.am index 28818ab..0d3f2fc 100644 --- a/icons/scalable/device/Makefile.am +++ b/icons/scalable/device/Makefile.am @@ -84,7 +84,9 @@ icon_DATA = \ speaker-muted-000.svg \ speaker-muted-033.svg \ speaker-muted-066.svg \ - speaker-muted-100.svg + speaker-muted-100.svg \ +touchpad-capacitive.svg \ +touchpad-resistive.svg EXTRA_DIST = $(icon_DATA) -- 1.7.0.4 -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH 2/3] Touchpad extension for the frame
--- icons/scalable/device/touchpad-capacitive.svg | 18 ++ icons/scalable/device/touchpad-resistive.svg | 21 + 2 files changed, 39 insertions(+), 0 deletions(-) create mode 100644 icons/scalable/device/touchpad-capacitive.svg create mode 100644 icons/scalable/device/touchpad-resistive.svg diff --git a/icons/scalable/device/touchpad-capacitive.svg b/icons/scalable/device/touchpad-capacitive.svg new file mode 100644 index 000..e223b66 --- /dev/null +++ b/icons/scalable/device/touchpad-capacitive.svg @@ -0,0 +1,18 @@ +http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd' [ + + +]>http://www.w3.org/2000/svg"; xmlns:xlink="http://www.w3.org/1999/xlink"; y="0px"> + + + + + diff --git a/icons/scalable/device/touchpad-resistive.svg b/icons/scalable/device/touchpad-resistive.svg new file mode 100644 index 000..3eb8cb4 --- /dev/null +++ b/icons/scalable/device/touchpad-resistive.svg @@ -0,0 +1,21 @@ +http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd' [ + + +]>http://www.w3.org/2000/svg"; xmlns:xlink="http://www.w3.org/1999/xlink"; y="0px"> + + + + -- 1.7.0.4 -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH 1/3] Touchpad extension for the frame
---
extensions/deviceicon/touchpad.py | 152 +
1 files changed, 152 insertions(+), 0 deletions(-)
create mode 100644 extensions/deviceicon/touchpad.py
diff --git a/extensions/deviceicon/touchpad.py
b/extensions/deviceicon/touchpad.py
new file mode 100644
index 000..a182d9c
--- /dev/null
+++ b/extensions/deviceicon/touchpad.py
@@ -0,0 +1,152 @@
+# Copyright (C) 2010, Walter Bender, Sugar Labs
+#
+# 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 gtk
+import gconf
+from os import system, path, remove
+
+from sugar.graphics.tray import TrayIcon
+from sugar.graphics.xocolor import XoColor
+from sugar.graphics.palette import Palette
+from jarabe.frame.frameinvoker import FrameWidgetInvoker
+
+_STATUS_TEXT = {'capacitive': _('finger'), 'resistive': _('stylus')}
+_CAPACITIVE_ICON_NAME = 'touchpad-capacitive'
+_RESISTIVE_ICON_NAME = 'touchpad-resistive'
+_FLAG_PATH = '/home/olpc/.olpc-pentablet-mode'
+_NODE_PATH = '/sys/devices/platform/i8042/serio1/ptmode'
+
+
+class DeviceView(TrayIcon):
+""" Manage the touchpad mode from the device palette on the Frame """
+
+FRAME_POSITION_RELATIVE = 500
+
+def __init__(self):
+""" Create the touchpad palette and display it on Frame """
+
+# Only appears when the device exisits
+if not path.exists(_NODE_PATH):
+return
+
+if get_touchpad() == 'resistive':
+icon_name = _RESISTIVE_ICON_NAME
+else:
+icon_name = _CAPACITIVE_ICON_NAME
+
+client = gconf.client_get_default()
+color = XoColor(client.get_string('/desktop/sugar/user/color'))
+TrayIcon.__init__(self, icon_name=icon_name, xo_color=color)
+self.set_palette_invoker(FrameWidgetInvoker(self))
+self.connect('button-release-event', self.__button_release_event_cb)
+self.connect('expose-event', self.__expose_event_cb)
+
+def create_palette(self):
+""" On create, set the current mode """
+self.palette = ResourcePalette(_('My touchpad'), self.icon)
+self.palette.set_group_id('frame')
+return self.palette
+
+def __button_release_event_cb(self, widget, event):
+""" On button release, switch modes """
+self.palette.toggle_mode()
+return True
+
+def __expose_event_cb(self, *args):
+pass
+
+
+class ResourcePalette(Palette):
+""" Query the current state of the touchpad and update the display """
+
+def __init__(self, primary_text, icon):
+""" Get the status """
+Palette.__init__(self, label=primary_text)
+
+self._icon = icon
+
+self.connect('popup', self.__popup_cb)
+self.connect('popdown', self.__popdown_cb)
+
+self.updating = False
+
+vbox = gtk.VBox()
+self.set_content(vbox)
+
+self._status_text = gtk.Label()
+vbox.pack_start(self._status_text, padding=10)
+self._status_text.show()
+
+vbox.show()
+
+self._mode = get_touchpad()
+self.set_mode_graphics()
+
+def set_mode_graphics(self):
+""" Set the label and icon based on the current mode """
+self._status_text.set_label(_STATUS_TEXT[self._mode])
+if self._mode == 'resistive':
+self._icon.props.icon_name = _RESISTIVE_ICON_NAME
+else:
+self._icon.props.icon_name = _CAPACITIVE_ICON_NAME
+
+def toggle_mode(self):
+""" On mouse click, toggle the mode """
+if self._mode == 'capacitive':
+self._mode = 'resistive'
+else:
+self._mode = 'capacitive'
+
+set_touchpad(self._mode)
+self.set_mode_graphics()
+
+def __popup_cb(self, gobject):
+self.updating = True
+
+def __popdown_cb(self, gobject):
+self.updating = False
+
+
+def setup(tray):
+tray.add_device(DeviceView())
+
+
+def get_touchpad():
+""" Get the touchpad mode. """
+_file_handle = open(_NODE_PATH, "r")
+_text = _file_handle.read()
+_file_handle.close()
+
+if _text[0] == '1':
+return 'resistive'
+else:
+return 'capacitive'
+
+
+def set_touchpad(touchpad):
+""" Set the touchpad mode. """
+if touchpad == 'capacitive':
+if path.exists(_FLAG_PATH):
+remove(_
Re: [Sugar-devel] Design Team meeting (was: Re: UI experiments: pop-up menus and hot corners)
On Thu, Jul 8, 2010 at 9:38 AM, Christian Marc Schmidt < christianm...@gmail.com> wrote: > Sorry, Sascha is right about 15:30 UTC being the correct time on > Saturday. Well, did Christian really mean 10:30 Eastern Daylight Time, EDT, or Eastern Standard Time, EST? Time zone code confusion may be aided by this site, and referencing a well-known city instead of error-inducing codes: http://www.timeanddate.com/worldclock/converted.html?month=7&day=10&year=2010&hour=10&min=30&sec=0&p1=179&p2=0 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-0.84.17
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.84.17.tar.bz2 == News == * doesn't automatically connect to network at startup anymore (on XO-1) #1883 * Remove "Erase" and "Remove favorite" Activity palette entries from Home favorite view #1128 * reorganise home menu #1206 * olpc-mesh support in 0.84 #2015 * Sugar needs to accept None as a layout #1147 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design Team meeting (was: Re: UI experiments: pop-up menus and hot corners)
Sorry, Sascha is right about 15:30 UTC being the correct time on Saturday. I also agree with Gary that bi-weekly can be difficult to coordinate. I'd prefer to continue meeting "on demand" whenever we have a certain number of items to talk through. A little more frequently probably wouldn't hurt, though... Talk to you on Saturday, Christian On Jul 8, 2010, at 5:13 AM, Gary Martin wrote: > Hi Sascha, > > On 8 Jul 2010, at 09:39, Sascha Silbe > wrote: > >> Excerpts from Christian Marc Schmidt's message of Mon Jul 05 >> 14:37:00 + 2010: >> >> I'm moving this discussion to sugar-devel and adjusting the subject >> so >> anybody else interested in joining the meeting has a chance to notice >> this thread. >> >>> We are looking to schedule a design meeting next Saturday (July 10), >>> at 10:30am EST (2:30 UTC/GMT). We'll be reviewing designs for the >>> proposed Start new/Resume functionality in Home view. Please join! >> What's the authoritative time? 10:30am or 02:30 UTC? >> >> sascha.si...@twin:~$ date -d 'July 10 10:30am EST' -u >> Sat Jul 10 15:30:00 UTC 2010 >> sascha.si...@twin:~$ date -d 'July 10 10:30am EST' >> Sat Jul 10 17:30:00 CEST 2010 >> >> I could attend at 15:30 UTC (= 10:30 EST), but not at 02:30 UTC. >> >> It would be great to hold Design Team meetings regularly (bi-weekly >> or at least monthly). We have already queued up a lot to talk about >> again. > > Do you have specific items we can try to cover on the mail-list > first? Real time design meetings are tough to schedule and (in my > opinion) are usually better focused on trying to move forward a goal > or two. > > Regards, > --Gary > >> Sascha >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Design Team meeting (was: Re: UI experiments: pop-up menus and hot corners)
I'd like to add to that list: - Saving web pages from browse/SSBs If there's time, I'd like some designers' opinion on how it should look. On 8 July 2010 11:49, Sascha Silbe wrote: > Excerpts from Gary Martin's message of Thu Jul 08 09:13:23 + 2010: > >> > It would be great to hold Design Team meetings regularly (bi-weekly or at >> > least monthly). We have already queued up a lot to talk about again. >> >> Do you have specific items we can try to cover on the mail-list first? Real >> time design meetings are tough to schedule and (in my opinion) are usually >> better focused on trying to move forward a goal or two. > > These are the topics / open issues I've collected from the mailing > list and the bug tracker (see wiki page [1] for links to patches): > > - Journal backup UI (Patch from Martin Abente, Patch from Sascha Silbe) > - Alerts (Patch from Anish Mangal) and notifications > - Uncaught exception handler (#2063) > - How to handle start-up delay due to data store migration (#1546)? > - "Your Journal is empty" shown for unreadable storage media (#1810) > - invalid/unknown colors are shown as owner colors (#1750) > - Erasure of downloaded Activity entries in Journal permanently removes > the code bundle (#1512) > - Drop down menus give no indication of their existence, also are too > slow to load (#1169, Patch from Michael Stone) > > There are also 23 open tickets [2] filed against the design component in > Trac. > > Sascha > > [1] http://wiki.sugarlabs.org/go/Design_Team/Meetings > [2] > https://bugs.sugarlabs.org/query?component=design&status=accepted&status=assigned&status=new&status=reopened > -- > 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 > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Announce: OLPC software strategy.
On Thu, 2010-07-08 at 11:02 +0200, Tomeu Vizoso wrote: > Congratulations on the excellent work done to date by you all and on > the sound (and well communicated) plan. I couldn't agree more. On top of this, interaction between OLPC, the Fedora community and the Sugar Labs community has been fantastically smooth and productive. (this is just my own perception, of course. As always, suggestions to improve our collaboration processes are very welcome). -- // 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] Design Team meeting (was: Re: UI experiments: pop-up menus and hot corners)
Excerpts from Gary Martin's message of Thu Jul 08 09:13:23 + 2010: > > It would be great to hold Design Team meetings regularly (bi-weekly or at > > least monthly). We have already queued up a lot to talk about again. > > Do you have specific items we can try to cover on the mail-list first? Real > time design meetings are tough to schedule and (in my opinion) are usually > better focused on trying to move forward a goal or two. These are the topics / open issues I've collected from the mailing list and the bug tracker (see wiki page [1] for links to patches): - Journal backup UI (Patch from Martin Abente, Patch from Sascha Silbe) - Alerts (Patch from Anish Mangal) and notifications - Uncaught exception handler (#2063) - How to handle start-up delay due to data store migration (#1546)? - "Your Journal is empty" shown for unreadable storage media (#1810) - invalid/unknown colors are shown as owner colors (#1750) - Erasure of downloaded Activity entries in Journal permanently removes the code bundle (#1512) - Drop down menus give no indication of their existence, also are too slow to load (#1169, Patch from Michael Stone) There are also 23 open tickets [2] filed against the design component in Trac. Sascha [1] http://wiki.sugarlabs.org/go/Design_Team/Meetings [2] https://bugs.sugarlabs.org/query?component=design&status=accepted&status=assigned&status=new&status=reopened -- 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] Design Team meeting (was: Re: UI experiments: pop-up menus and hot corners)
Hi Sascha, On 8 Jul 2010, at 09:39, Sascha Silbe wrote: > Excerpts from Christian Marc Schmidt's message of Mon Jul 05 14:37:00 + > 2010: > > I'm moving this discussion to sugar-devel and adjusting the subject so > anybody else interested in joining the meeting has a chance to notice > this thread. > >> We are looking to schedule a design meeting next Saturday (July 10), >> at 10:30am EST (2:30 UTC/GMT). We'll be reviewing designs for the >> proposed Start new/Resume functionality in Home view. Please join! > What's the authoritative time? 10:30am or 02:30 UTC? > > sascha.si...@twin:~$ date -d 'July 10 10:30am EST' -u > Sat Jul 10 15:30:00 UTC 2010 > sascha.si...@twin:~$ date -d 'July 10 10:30am EST' > Sat Jul 10 17:30:00 CEST 2010 > > I could attend at 15:30 UTC (= 10:30 EST), but not at 02:30 UTC. > > It would be great to hold Design Team meetings regularly (bi-weekly or at > least monthly). We have already queued up a lot to talk about again. Do you have specific items we can try to cover on the mail-list first? Real time design meetings are tough to schedule and (in my opinion) are usually better focused on trying to move forward a goal or two. Regards, --Gary > Sascha > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Announce: OLPC software strategy.
On Thu, Jul 8, 2010 at 00:01, Chris Ball wrote: > Hi, > > Now that the 10.1.1 release for XO-1.5 is out, it's a good time to > talk about OLPC's software strategy for the future. We've got a few > announcements to make: > > XO-1: > = > > OLPC wasn't planning to make a Fedora 11 release of the XO-1 OS, but > a group of volunteers including Steven Parrish, Bernie Innocenti, > Paraguay Educa and Daniel Drake stepped up and produced Fedora 11 XO-1 > builds that follow the OLPC 10.1.1 work. I'm happy to announce that > we're planning on releasing an OLPC-signed version of that work, and > that this release will happen alongside the next XO-1.5 point release > in the coming weeks. So, OLPC release 10.1.2 will be available for > both XO-1 and XO-1.5 at the same time, and will contain Sugar 0.84, > GNOME 2.26 and Fedora 11. We think that offering this fully > interoperable software stack between XO-1 and XO-1.5 laptops will > greatly aid deployments, and we're very thankful to everyone who has > enabled us to be able to turn this XO-1 work into a supported release! > > To prepare for this XO-1 release, we've started working on fixing > some of the remaining bugs in the community F11/XO-1 builds. Paul Fox > recently solved a problem with suspend/resume and wifi in the F11/XO-1 > kernel, which was the largest blocker for a supported release. We'll > continue to work on the remaining bugs, particularly the ones that > OLPC is uniquely positioned to help with. > > The first development builds for this release will be published later > this week. > > XO-1.5: > === > > We'll be continuing to work on XO-1.5 improvements, incorporating > fixes to the "Known Problems" section of the 10.1.1 release notes¹ > into the 10.1.2 release. > > XO-1.75 and beyond: > === > > XO-1.75 software development is underway. Today we're announcing > that we're planning on using Fedora as the base distribution for the > XO-1.75. This wasn't an obvious decision -- ARM is not a release > architecture in Fedora, and so we're committing to help out with that > port. Our reasons for choosing Fedora even though ARM work is needed > were that we don't want to force our deployments to learn a new > distribution and re-write any customizations they've written, we want > to reuse the packaging work that's already been done in Fedora for > OLPC and Sugar packages, and we want to continue our collaboration > with the Fedora community who we're getting to know and work with > well. > > We've started to help with Fedora ARM by adding five new build > machines (lent to OLPC by Marvell; thanks!) to the Fedora ARM koji > build farm, and we have Fedora 12 and Sugar 0.86 running on early 1.75 > development boards. We'd prefer to use Fedora 13 for the XO-1.75, but > it hasn't been built for ARM yet -- if anyone's interested in helping > out with this or other Fedora ARM work, please check out the Fedora > ARM page on the Fedora Wiki². We're also interested in hiring ARM and > Fedora developers to help with this; if you're interested in learning > more, please send an e-mail to jobs-engineer...@laptop.org. > > We'll also be continuing to use Open Firmware on the XO-1.75, and > Mitch Bradley has an ARM port of OFW running on our development boards > already. > > EC-1.75 open source EC code: > > > OLPC is proud to announce that the XO-1.75 embedded controller will > have an open codebase (with a small exception, see below). After much > behind-the-scenes effort, EnE has agreed to provide us with a public > version of the KB3930 datasheet and is allowing our new code to be > made public. > > The code is not available yet due to a few chunks of proprietary code > that need to be purged and some other reformatting. A much more > detailed announcement will be provided once the new code is pushed to > a public repository. The code will be licensed under the GPL with a > special exception for OLPC use. > > The exception is because EnE has not released the low-level details on > the PS/2 interface in the KB3930, so there will be some code that is > not available -- relative to the codebase this is a very small amount > of code. The GPL licensing exception will allow for linking against > this closed code. We're going to investigate ways to move away from > this code in the future. (As far as we're aware, this will make the > XO-1.75 the first laptop with open embedded controller code!) > > Multi-touch Sugar: > == > > We've begun working on modifications to Sugar to enable touchscreen > and multitouch use (the XO-1.75 will have a touchscreen, as will > future OLPC tablets based on its design), and we'll continue to do so. > The first outcome from this work is Sayamindu Dasgupta's port of the > Meego Virtual Keyboard³ to Sugar -- you can see a screencast of it in > action here⁴. > > It's an exciting time for software development at OLPC. Many thanks > for all of your support and efforts!
Re: [Sugar-devel] Announce: OLPC software strategy.
Hi Chris, Well done to the team for all the hard work! > Now that the 10.1.1 release for XO-1.5 is out, it's a good time to > talk about OLPC's software strategy for the future. We've got a few > announcements to make: > > XO-1: > = > > OLPC wasn't planning to make a Fedora 11 release of the XO-1 OS, but > a group of volunteers including Steven Parrish, Bernie Innocenti, > Paraguay Educa and Daniel Drake stepped up and produced Fedora 11 XO-1 > builds that follow the OLPC 10.1.1 work. I'm happy to announce that > we're planning on releasing an OLPC-signed version of that work, and > that this release will happen alongside the next XO-1.5 point release > in the coming weeks. So, OLPC release 10.1.2 will be available for > both XO-1 and XO-1.5 at the same time, and will contain Sugar 0.84, > GNOME 2.26 and Fedora 11. We think that offering this fully > interoperable software stack between XO-1 and XO-1.5 laptops will > greatly aid deployments, and we're very thankful to everyone who has > enabled us to be able to turn this XO-1 work into a supported release! Excellent news! > To prepare for this XO-1 release, we've started working on fixing > some of the remaining bugs in the community F11/XO-1 builds. Paul Fox > recently solved a problem with suspend/resume and wifi in the F11/XO-1 > kernel, which was the largest blocker for a supported release. We'll > continue to work on the remaining bugs, particularly the ones that > OLPC is uniquely positioned to help with. > > The first development builds for this release will be published later > this week. > > XO-1.5: > === > > We'll be continuing to work on XO-1.5 improvements, incorporating > fixes to the "Known Problems" section of the 10.1.1 release notes¹ > into the 10.1.2 release. Now that the major release is out what are the plans for upstreaming the kernel and other changes for both the XO-1.5 as well as the remaining bits for the XO-1? > XO-1.75 and beyond: > === > > XO-1.75 software development is underway. Today we're announcing > that we're planning on using Fedora as the base distribution for the > XO-1.75. This wasn't an obvious decision -- ARM is not a release > architecture in Fedora, and so we're committing to help out with that > port. Our reasons for choosing Fedora even though ARM work is needed > were that we don't want to force our deployments to learn a new > distribution and re-write any customizations they've written, we want > to reuse the packaging work that's already been done in Fedora for > OLPC and Sugar packages, and we want to continue our collaboration > with the Fedora community who we're getting to know and work with > well. > > We've started to help with Fedora ARM by adding five new build > machines (lent to OLPC by Marvell; thanks!) to the Fedora ARM koji > build farm, and we have Fedora 12 and Sugar 0.86 running on early 1.75 > development boards. We'd prefer to use Fedora 13 for the XO-1.75, but > it hasn't been built for ARM yet -- if anyone's interested in helping > out with this or other Fedora ARM work, please check out the Fedora > ARM page on the Fedora Wiki². We're also interested in hiring ARM and > Fedora developers to help with this; if you're interested in learning > more, please send an e-mail to jobs-engineer...@laptop.org. Very interested in helping out, pushing builds etc through koji so let me know what needs attention and I'll help out where I can. > We'll also be continuing to use Open Firmware on the XO-1.75, and > Mitch Bradley has an ARM port of OFW running on our development boards > already. > > EC-1.75 open source EC code: > > > OLPC is proud to announce that the XO-1.75 embedded controller will > have an open codebase (with a small exception, see below). After much > behind-the-scenes effort, EnE has agreed to provide us with a public > version of the KB3930 datasheet and is allowing our new code to be > made public. > > The code is not available yet due to a few chunks of proprietary code > that need to be purged and some other reformatting. A much more > detailed announcement will be provided once the new code is pushed to > a public repository. The code will be licensed under the GPL with a > special exception for OLPC use. > > The exception is because EnE has not released the low-level details on > the PS/2 interface in the KB3930, so there will be some code that is > not available -- relative to the codebase this is a very small amount > of code. The GPL licensing exception will allow for linking against > this closed code. We're going to investigate ways to move away from > this code in the future. (As far as we're aware, this will make the > XO-1.75 the first laptop with open embedded controller code!) > > Multi-touch Sugar: > == > > We've begun working on modifications to Sugar to enable touchscreen > and multitouch use (the XO-1.75 will have a touchscreen, as will > future OLPC tablets based on its
[Sugar-devel] Design Team meeting (was: Re: UI experiments: pop-up menus and hot corners)
Excerpts from Christian Marc Schmidt's message of Mon Jul 05 14:37:00 + 2010: I'm moving this discussion to sugar-devel and adjusting the subject so anybody else interested in joining the meeting has a chance to notice this thread. > We are looking to schedule a design meeting next Saturday (July 10), > at 10:30am EST (2:30 UTC/GMT). We'll be reviewing designs for the > proposed Start new/Resume functionality in Home view. Please join! What's the authoritative time? 10:30am or 02:30 UTC? sascha.si...@twin:~$ date -d 'July 10 10:30am EST' -u Sat Jul 10 15:30:00 UTC 2010 sascha.si...@twin:~$ date -d 'July 10 10:30am EST' Sat Jul 10 17:30:00 CEST 2010 I could attend at 15:30 UTC (= 10:30 EST), but not at 02:30 UTC. It would be great to hold Design Team meetings regularly (bi-weekly or at least monthly). We have already queued up a lot to talk about again. Sascha signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Lint sugar sources
On Mon, Jul 5, 2010 at 14:45, Aleksey Lim wrote: > Hi all, > > I'm using/planing-to-use lint tools in several projects. And since I'm > not using jhbuild which support pylint/pep8.py tools, I created > sugar-lint[1] project. > > There is single command - sugar-lint which will call pylint (should be > installed before) with custom configuration file and pep8.py (comes > with sugar-lint sources). Should we add this to sugar-jhbuild? Regards, Tomeu > [1] http://wiki.sugarlabs.org/go/Activity_Team/Sugar_Lint > > -- > Aleksey > ___ > 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] Opportunity: migration from Gconf to GSettings
On Thu, Jul 8, 2010 at 10:01, Simon Schampijer wrote: > Hi, > > while drafting the 0.90 schedule [1] I came across the migration from > Gconf to GSettings in GNOME [2]. This is dependent on introspection, so > not something for 0.90 but would be nice to have it ready in 0.92. If > someone wants to work already on it, it would be a valuable and highly > appreciated task. Wonder which backend would be most adequate for Sugar, dconf, gkeyfile, ...? Regards, Tomeu > Regards, > Simon > > > [1] http://wiki.sugarlabs.org/go/0.90/Roadmap#Schedule > [2] http://live.gnome.org/GnomeGoals/GSettingsMigration > ___ > 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] Opportunity: migration from Gconf to GSettings
Hi, while drafting the 0.90 schedule [1] I came across the migration from Gconf to GSettings in GNOME [2]. This is dependent on introspection, so not something for 0.90 but would be nice to have it ready in 0.92. If someone wants to work already on it, it would be a valuable and highly appreciated task. Regards, Simon [1] http://wiki.sugarlabs.org/go/0.90/Roadmap#Schedule [2] http://live.gnome.org/GnomeGoals/GSettingsMigration ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] gconf: sugar <-> gnome
On Thu, Jul 8, 2010 at 8:50 AM, Tomeu Vizoso wrote: > On Wed, Jul 7, 2010 at 19:29, Esteban Arias wrote: >> Hi, >> >> Do you think that is better use same keys gconf on sugar and gnome to >> maintain the same configuration? >> >> For example, to set mouse keys on sugar, I should use: >> '/desktop/gnome/accessibility/keyboard/mousekeys_enable' or >> '/desktop/sugar/accessibility/keyboard/mousekeys_enable' ? >> Or, to set mouse theme, I use: >> '/desktop/gnome/peripherals/mouse/cursor_theme' or >> '/desktop/sugar/peripherals/mouse/cursor_theme' ? >> >> I would use /desktop/sugar/ on sugar and /desktop/gnome/ on gnome... because >> are differents ambients. > > Yes, I tend to think the same. In some very specific settings it may > make more sense for changes in Sugar to reflect on GNOME but I doubt > it's worth the trouble. I think for UX related stuff I would use separate ones but but for system related like NetworkManager and proxy settings I would use the gnome one so its the same between environments and just works in both. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] gconf: sugar <-> gnome
On Wed, Jul 7, 2010 at 19:29, Esteban Arias wrote: > Hi, > > Do you think that is better use same keys gconf on sugar and gnome to > maintain the same configuration? > > For example, to set mouse keys on sugar, I should use: > '/desktop/gnome/accessibility/keyboard/mousekeys_enable' or > '/desktop/sugar/accessibility/keyboard/mousekeys_enable' ? > Or, to set mouse theme, I use: > '/desktop/gnome/peripherals/mouse/cursor_theme' or > '/desktop/sugar/peripherals/mouse/cursor_theme' ? > > I would use /desktop/sugar/ on sugar and /desktop/gnome/ on gnome... because > are differents ambients. Yes, I tend to think the same. In some very specific settings it may make more sense for changes in Sugar to reflect on GNOME but I doubt it's worth the trouble. Regards, Tomeu > Esteban. > > ___ > 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: OLPC software strategy.
Excerpts from Chris Ball's message of Wed Jul 07 22:01:26 + 2010: > Now that the 10.1.1 release for XO-1.5 is out, it's a good time to > talk about OLPC's software strategy for the future. We've got a few > announcements to make: [...] Thanks for keeping us posted. > EC-1.75 open source EC code: > > > OLPC is proud to announce that the XO-1.75 embedded controller will > have an open codebase (with a small exception, see below). After much > behind-the-scenes effort, EnE has agreed to provide us with a public > version of the KB3930 datasheet and is allowing our new code to be > made public. Yay! Thanks to everyone who has made this happen. > The exception is because EnE has not released the low-level details on > the PS/2 interface in the KB3930, so there will be some code that is > not available -- relative to the codebase this is a very small amount > of code. The GPL licensing exception will allow for linking against > this closed code. We're going to investigate ways to move away from > this code in the future. (As far as we're aware, this will make the > XO-1.75 the first laptop with open embedded controller code!) I trust the license will allow me to: 1. Build a new (complete, working) firmware image 2. Install it on my own XO-1.75. 3. Distribute the image (+ source) to other XO-1.75 users so they can install it. What about the compiler? IIUC currently a commercial compiler is required. If that continues to be the case (as I expect it to), would it be possible for OLPC to provide the (probably very few) users interested in hacking on the EC code access to a machine having this compiler installed? I.e. does the license OLPC has for this compiler allow more than one user (on the same machine) to use it (if necessary sequentially, ensured by using a lock file) and would OLPC be willing to give users access to such a machine? > We've begun working on modifications to Sugar to enable touchscreen > and multitouch use (the XO-1.75 will have a touchscreen, as will > future OLPC tablets based on its design), and we'll continue to do so. I'll be curious what comes out of it. 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
