Re: [sugar] [Sugar-devel] XO identity shared via Browse
On Thu, Dec 04, 2008 at 11:55:32PM +0100, Ivan Krstić wrote: > On Dec 4, 2008, at 11:34 PM, Robert McQueen wrote: > > I really don't think these kind of comments are productive for anyone. > > How not? You just wrote a long e-mail explaining *why* things are > fucked, not in the least disputing my claim that they are, indeed, > fucked. Because it's hard to distinguish gratuitous/personal attacks from a tough-love "fuck, your shit sucks [let's make it better]" type of email. Usually you get a "screw you for dismissing [specific issues you clearly don't understand], now never hope for help again", response, which I suspect just happened. I would love to see the reponse if someone from sugarlabs were to send an email saying "Bitfrost has a long, colourful history of being fucking ineffective and its implementation has a number of holes so wide you could drive a deployment-full of XOs through it, so I suggest you never say 'what great security you have' until Rainbow reaches the maturity of DCE 20 years ago.". I suspect it'd be massive silence since nobody cared about it.[1] > Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org Martin 1. Though I doubt anyone from sugarlabs would be so rude. pgpdM5VlVq3ba.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] Deleting items from the Journal
In case anyone finds them useful or they annoy someone into doing a
better job, below are some patches that can be used to clean up your
journal, as in:
lsjournal -W -t "Terminal Activity" -u | remove-from-journal --delete
lsjournal -W -t "Page Load Error" -u | remove-from-journal --delete
To apply, this worked for me (on jhbuild, and of course I developed
them on a joyride XO, so it probably works there and on 767):
sudo su -
cd /usr/bin
patch < thismail.txt
Martin
From ea58945e59874a9b1b36c846ea7fbe3fd56a130b Mon Sep 17 00:00:00 2001
From: Martin Dengler <[EMAIL PROTECTED]>
Date: Sun, 26 Oct 2008 20:18:24 +
Subject: [PATCH] add remove-from-journal script
---
remove-from-journal | 49 +
1 files changed, 49 insertions(+), 0 deletions(-)
create mode 100755 remove-from-journal
diff --git a/remove-from-journal b/remove-from-journal
new file mode 100755
index 000..42064b3
--- /dev/null
+++ b/remove-from-journal
@@ -0,0 +1,49 @@
+#!/usr/bin/env python
+#
+#####
+#
+# Copyright (c) 2008 Martin Dengler
+#
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+# THE SOFTWARE.
+#
+#
+import optparse
+import os
+import sys
+
+from sugar.datastore import datastore
+
+# Set up things so that this script can run in a terminal.
+if 'DBUS_SESSION_BUS_ADDRESS' not in os.environ:
+os.environ['DBUS_SESSION_BUS_ADDRESS'] = 'unix:path=/tmp/olpc-session-bus'
+if 'DISPLAY' not in os.environ:
+os.environ['DISPLAY'] = ':0.0'
+
+parser = optparse.OptionParser(usage="%prog [--delete]\n\n"
+ " expects a list of uids on standard input,"
+ " one per line")
+parser.add_option("--delete", action="store_true", default=False,
+ help="DELETE the matches - WARNING WILL LOSE DATA")
+options, args = parser.parse_args()
+
+for uid in sys.stdin:
+uid = uid.strip()
+if options.delete:
+datastore.delete(uid)
+
--
1.5.5.1
From 8d4f44bd94be3d0bc5965e08f26611d3bf2068a9 Mon Sep 17 00:00:00 2001
From: Martin Dengler <[EMAIL PROTECTED]>
Date: Sun, 26 Oct 2008 21:58:33 +
Subject: [PATCH] add --without-files to find only objects lacking files
---
lsjournal |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/lsjournal b/lsjournal
index 7083002..852dc18 100755
--- a/lsjournal
+++ b/lsjournal
@@ -60,6 +60,11 @@ def build_option_parser():
help="show all metadata and properties",
default=False)
+parser.add_option("-W", "--without-files", action="store_true",
+ dest="without_files",
+ help="only return items without a file path",
+ default=False)
+
return parser
if __name__ == "__main__":
@@ -86,7 +91,9 @@ if __name__ == "__main__":
objects, count = datastore.find(query, sorting='-mtime')
for i in range(count):
-if not options.all and not objects[i].file_path:
+if ((options.without_files and objects[i].file_path) or
+(not (options.all or options.without_files)
+ and not objects[i].file_path)):
objects[i].destroy()
continue
if options.debug:
--
1.5.5.1
From e98b49966a7a4c616701e02945e3f74acc4cd671 Mon Sep 17 00:00:00 2001
From: Martin Dengler <[EMAIL PROTECTED]>
Date: Sun, 26 Oct 2008 23:18:07 +
Subject: [PATCH] support -S option to allow -W to ignore files below a certain
size
---
lsjournal | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/lsjournal b/lsjournal
index 852dc18..43723c4 100755
--- a/lsjournal
+++ b/lsjournal
@@ -65,8 +65,15 @@ def build_option_parser():
help="only return items witho
[sugar] [PATCH] Fix frame device ordering logic
--- src/jarabe/frame/devicestray.py |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/jarabe/frame/devicestray.py b/src/jarabe/frame/devicestray.py index 8514efb..47a7bf5 100644 --- a/src/jarabe/frame/devicestray.py +++ b/src/jarabe/frame/devicestray.py @@ -40,12 +40,12 @@ class DevicesTray(tray.HTray): def add_device(self, view): index = 0 +relative_index = getattr(view, "FRAME_POSITION_RELATIVE", -1) for item in self.get_children(): -index = self.get_item_index(item) -view_pos = getattr(view, "FRAME_POSITION_RELATIVE", -1) -item_pos = getattr(item, "FRAME_POSITION_RELATIVE", 0) -if view_pos < item_pos: +current_relative_index = getattr(item, "FRAME_POSITION_RELATIVE", 0) +if current_relative_index >= relative_index: break +index += 1 self.add_item(view, index=index) view.show() -- 1.5.5.1 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Datastore and Nautilus, an amusing ponder
On Wed, Oct 15, 2008 at 07:37:52PM -0400, Benjamin M. Schwartz wrote: > I'm really not sure why I wrote this e-mail. Thanks for writing it. > Maybe it's to say that even our easiest options for interoperability > are actually quite complex, fragile, and dangerous. Worse is Better (I realize, based on TLDs, that I'm probably not preaching to the here). We should a) _ship_ things that b) doesn't suck. We can't just do a) or talk about doing b). Sorry for the platitudes - but I'd say that not only is your assessment correct, it implies that we need to make decisions that are *known* to result in non-ideal situations. This is better than the alternative, which is to be forced to make those types of decisions. > - --Ben Martin pgp9TnDxsBedg.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (very) Little Proposals for 9.1
On Wed, Oct 15, 2008 at 03:06:21PM -0400, Mikus Grinbergs wrote: > I'm surprised at the debate of providing a clock in the Frame. All the bike sheds in your town must be mass-produced :). > http://wiki.laptop.org/go/User:Tdang/XO_Setup#Add_a_Clock_to_Home_View ... > If an User can put in a clock ...make that two; I threw a very ugly patch out on this list yesterday. > mikus Martin pgpkrAnlD5em1.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar Clock
On Tue, Oct 14, 2008 at 08:32:31PM +0100, Martin Dengler wrote:
> PS - we should all stop arguing and just make a clock widget,
> finally.
http://dev.laptop.org/~mdengler/clock/screenshot_clock_01.png
Halfway done...now to stop arguing :)
From 346eea009cb645e176c2106386596dada9aeeed8 Mon Sep 17 00:00:00 2001
From: Martin Dengler <[EMAIL PROTECTED]>
Date: Tue, 14 Oct 2008 22:35:30 +
Subject: [PATCH] add clock frame device
---
model/devices/clock.py| 26
model/devices/devicesmodel.py |6 +++
view/devices/clock.py | 88 +
3 files changed, 120 insertions(+), 0 deletions(-)
create mode 100644 model/devices/clock.py
create mode 100644 view/devices/clock.py
diff --git a/model/devices/clock.py b/model/devices/clock.py
new file mode 100644
index 000..ce32855
--- /dev/null
+++ b/model/devices/clock.py
@@ -0,0 +1,26 @@
+# Copyright (C) 2008 Martin Dengler
+#
+# 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
+
+import gobject
+
+from model.devices import device
+
+class Device(device.Device):
+def __init__(self):
+device.Device.__init__(self)
+
+def get_type(self):
+return 'clock'
diff --git a/model/devices/devicesmodel.py b/model/devices/devicesmodel.py
index 1dd3c45..8f9615d 100644
--- a/model/devices/devicesmodel.py
+++ b/model/devices/devicesmodel.py
@@ -23,6 +23,7 @@ from model.devices import device
from model.devices.network import wireless
from model.devices.network import mesh
from model.devices import battery
+from model.devices import clock
from model.devices import reloadbutton
from model.devices import speaker
from model.devices import wirelessstrength
@@ -63,6 +64,11 @@ class DevicesModel(gobject.GObject):
logging.error("could not initialize reloadbutton device: %s" %
reloadbutton_fail_msg)
+try:
+self.add_device(clock.Device())
+except Exception, clock_fail_msg:
+logging.error("could not initialize clock device: %s" %
+ clock_fail_msg)
try:
self.add_device(wirelessstrength.Device())
diff --git a/view/devices/clock.py b/view/devices/clock.py
new file mode 100644
index 000..6fd71d6
--- /dev/null
+++ b/view/devices/clock.py
@@ -0,0 +1,88 @@
+# Copyright (C) 2008 Martin Dengler
+#
+# 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 cairo
+import gobject
+import gtk, gtk.gdk
+import math
+import pango
+import pangocairo
+import time
+
+from sugar import profile
+from sugar.graphics.toolbutton import ToolButton
+from sugar.graphics.style import Color
+
+class DigitalClock(gtk.Image):
+def __init__(self, *args, **kwargs):
+gtk.Image.__init__(self, *args, **kwargs)
+self.connect_after("expose-event", self.do_expose_event)
+self.timer = gobject.timeout_add(1000, self.__timeout_cb)
+mycolor = profile.get_color()
+self._fill_rgba = Color(mycolor.fill).get_rgba()
+self._stroke_rgba = Color(mycolor.stroke).get_rgba()
+
+def __timeout_cb(self):
+if self.window is not None:
+x, y, w, h = self.allocation
+self.window.invalidate_rect((x, y, x + w, y + h), False)
+return True
+
+def do_expose_event(self, widget, event):
+cr = self.window.cairo_create()
+x, y, w, h = event.area
+redraw_region = gtk.gdk.region_rectangle(self.allocation)
+exposed_region = gtk.gdk.region_rectangle(event.area)
+redraw_region.intersect(exposed_region
Re: [sugar] Sugar Clock
On Tue, Oct 14, 2008 at 07:51:23PM +0200, Tomeu Vizoso wrote: > On Tue, Oct 14, 2008 at 7:40 PM, Benjamin M. Schwartz > <[EMAIL PROTECTED]> wrote: > > [...]the system could easily suspend with the clock displayed [...] [...] > Crazy idea: put in the frame a widget that only updates (and displays) > itself 20 seconds after the mouse has been over it. 1) Or just make showing the frame inhibit suspend. 2) Or just ignore this problem - worse is better. We really don't have this problem (frequent suspends) right now, do we, as all power management is disabled in all shipping builds by default, right? And if we're not talking about a shipping build, why aren't we talking about which build we're having this discussion for? And aren't we being XO-centric? 3) Or just have the clock face, after updating on frame expose(), dissolve after a few seconds - in all but the most ideal power-management future this would be well before any suspend. > Thanks, > > Tomeu Martin PS - we should all stop arguing and just make a clock widget, finally. I hear no arguments about the right frame being out-of-date during suspend (from buddies leaving/joining during suspend). Is this really less of a problem in theory? If in practice it's less of a problem, how much less? The truth is, this is all just worrying about a problem that will never exist in the real world: a kid glancing at their dimmed XO screen after suspending while the kid has exposed the frame and then missing school or something because the clock is out of date. Please :). pgp8s7OH2L7Pr.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] scrolling the journal list view (was Re: alt-tabbing to the Journal)
On Sat, Oct 11, 2008 at 09:20:56PM +0100, Gary C Martin wrote: > On 11 Oct 2008, at 11:34, Tomeu Vizoso wrote: > > On Wed, Oct 8, 2008 at 5:27 PM, Eben Eliason wrote: > >> The main problem here is potential length of the scrolling page. > >> [...] we could introduce temporal section headers. After > >> scrolling far enough back in time, there might be sections for > >> each month, and further back, for each year, etc. > > > > Yes, I like this idea and I think it's pretty much doable. > > [...] the longer the page the smaller the scroll-bar, the more sensitive > it's movement, and the harder it is to navigate in a controlled, > refined manner. We're not preparing kids for the real world: http://www.martindengler.com/tmp/journal2.jpg (also an example of: what 1200x900 px can be used for; what temporal section headers get chosen for me by the real world; and how sometimes I've given up and created temporal sections myself) > --Gary Martin pgpICiR57lOxc.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] sugar and the digital age (was Re: notes from the field - Mongolia)
On Fri, Oct 10, 2008 at 03:13:27AM +0200, Bert Freudenberg wrote: > Am 09.10.2008 um 19:10 schrieb elana langer: > > > Essentially, in the minds of [teachers, parents, gov't officials], > > fluency on windows, being able to do power point presentations and > > surf the web is what being prepared means. Indeed. I think at least some consideration should be given to a filesystem view leaking through to the Journal. And, or even: but, those who believe that power point presentations are an important part of being prepared are often quite convinced by power point presentations or similar superficial attempts, so significant changes to core UI might not be necessary to reassure them. Even an activity to copy files might be able to assuage their fears about the journal, and those are easy enough to make (though see other discussions about how the about-to-be-deployed journal is quite decent at the basic to-and-from-USB file transfers). > Kudos to the Sugar developers for not giving in to the crowd's > pseudo-wisdom. Hear, hear* > - Bert - Martin * From the choir :). pgpu0LhTaguMV.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] notes from the field - Mongolia
On Thu, Oct 09, 2008 at 05:36:10PM -0700, Edward Cherlin wrote: > Martin, Deniz, cool it, the pair of you. No more ad hominem attacks. Relax. As to my "ad-hominem attacks", how is it ad-hominem to say that someone who says something incorrect is out of touch (with the truth/progress/etc.)? Or say that it's annoying me if they call others out of touch? The former is a statement of fact relevant to the propositions at hand, and the latter could at worst be an irrelevant personal opinion, but in that case the correct response is to ignore it, which I note many on the list are doing. > You each owe the other an apology. For disseminating up-to-date, correct information? No. For attempting sarcasm on the internet? Very sorry. Er, whoops, there I go again. > And one to Marco, too. Eh? Marco's great. Why should I apologize to him for that? > The list is not out of touch. I tried to keep it in touch with actions. I doubt many will be impressed by anything else, especially mere assertions (a lady who says she's a lady, and all that). > There are many on the list who are ignorant of conditions on the > ground and of other things through no fault of their own. Yes, but most of them don't go calling the list out of touch. > Now shake hands and come out arguing about facts, needs, and > possibilities. I argued about the facts. And I'm not good at meta-discussions, so perhaps I'm missing some other point of yours. Martin pgp1G8mbY0exq.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] notes from the field - Mongolia
On Thu, Oct 09, 2008 at 08:10:57PM -0400, Deniz Kural wrote: > [this list is out of touch] > Hence, student, or teacher, I need a USB stick. 1. Plug USB stick into XO running build from the last six months 2. Drag files from the Journal to the USB stick icon 3. Drag files from the USB stick's file list to the Journal > Deniz > p.p.s Marco, you're a stuck-up asshole :) And you managed to call people that actually know what the hell they're talking about "out of touch". Thanks for advancing the state of knowledge on the list all the way forward to, oh, 2007. pgpQETFICBErl.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] alt-tabbing to the Journal
On Tue, Oct 07, 2008 at 10:51:50PM -0400, Walter Bender wrote: > > 2) the Journal always appearing below the XO icon > > If only. But only at first boot. The icon below the XO icon is always > whatever activity currently selected in the Activity View. > > The bottom line is that, at least as far as the XO is concerned (and > other machines with limited memory and no swap) the list of activities > to tab through, with or without the Journal, is going to be a short > list, so is it really such a pressing issue? Have you tabbed past the Journal on an XO recently with Browse and Help open (or two other activities)? I have, on joyrides and candidate 8.2.0 builds. The bottom line answer is: 1) Yes, for me (every time I tab past it I hate that it hangs the XO for a second or so while the Journal list view updates with n more odd entries, where n is the number of open activities); and, given I'm not the target audience; or 2) have you ever seen a kid do it? If they were fine with it I'll happily shut up and just patch my own system (and please just close #6251). As with #8337, I am amazed that people would put up with this type of performance, so I either assume I'm some sort os speed freak or nobody's actually using some of this stuff on the hardware that's being deployed. And as far as limited memory and no swap, requests to fix the hardware (more RAM for G1G1/deployments) or the non-Sugar software (compcache, #28) exist, but they don't appear to be fixable...doesn't mean we can't nitpick (this is the internet :)). > I'd love the same passion developed to some of the issues/topics that > impact the learning. I'd love to have the time. I feel bad all I have is enough just to nitpick on stuff like this :(. > How can we make the Journal better, regardless of how we open it and > regardless of whether we consider it an activity or part of Sugar > core? - It can not have n instances of "Clock Activity" and "Terminal Activity" and "[xxx] Activity", where n is the number of times I've Alt-tabbed past the journal - it can have multi-selection - Any/all ideas can be implemented http://sugarlabs.org/go/DevelopmentTeam/0.84/Ideas#Journal ...you know all this, and this sub-thread is rhetorical as far as I'm involved, except for: - We can come to quicker resolution on these small issues that people raise, one way or the other. Having the illusion of having a choice makes people spend time discussing it. #6251 was opened *8* months ago. I'd get over my issues/spam tendencies (by sucking it up, or maintaining my own patch for it as I already do other things) quicker if someone just closed the ticket or otherwise said WONTFIX. Or has someone told me that and I'm too blockheaded to notice :). I think in fact Tomeu may have been trying to do this, so consider this the death throes of the issue, it seems, as there is no support for a change besides the four people that commented on the ticket and are not Eben. As a further thought, for feature/design requests, sometimes it might be nice, after some discussion, to close the ticket and don't do anything more unless there's a patch. Put up or shut up is a fine thing to say to someone capable of making a patch (and under-said by Sugar/OLPC, IMHO), and many of us are able to handle a WONTFIX without making a stink about it forevermore :). > -walter Martin pgpVv8gl4Elvw.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar USB testing
On Tue, Oct 07, 2008 at 07:45:13PM -0700, [EMAIL PROTECTED] wrote: > You bring up a good point. It would be good if the developers used > XO and Sugar. [...] > To get developers eating dog food with the XO you would need the > following: [...] > 2.) An IMAP client Activity and corresponding IMAP server on a school > server. Perhaps UW IMAP http://www.washington.edu/imap/ or cyrus > http://cyrusimap.web.cmu.edu/ . This would permit email access with > a rich user experience while leaving the messages on the server. For text junkies, offlineimap (read gmail too!) + mutt (+ screen, if you want) works great. Is that cheating / not "Sugar"y enough? Martin pgpNFIOUz9T10.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar USB testing
On Tue, Oct 07, 2008 at 10:02:57PM -0400, [EMAIL PROTECTED] wrote: > marco pesenti gritti wrote: > > On Sun, Oct 5, 2008 at 6:37 PM, Walter Bender <[EMAIL PROTECTED]> wrote: > > > CCing the Sugar list. > > and adding devel. > > > > > > > It seems that one of the problems we will be encountering with generic > > > spins is footprint. Even a standard Ubuntu without Sugar was seeming > > > too fat to load from a LiveCD on a Pentium 4 with 256K of DRAM. > > > > I'm planning to dogfood the Fedora LiveUSB and I'll have a look to > > memory usage while doing so. In principle, unless there are relevant > > memory costs given by running on a LiveUSB, I'd expect it to work > > decently. > > i've been curious for a while -- can we have a show of hands for > how many people dogfood the existing XO s/w? I do, but I'm not a developer, and I use compcache to help with the memory pressure (though I typed "lsjournal" a few hours (!) ago and it still hasn't unfrozen). > i _really_ think we need to make the XO base _and_ sugar be a > place that developers are comfortable living in. That'd be cool. > paul Martin PS - my only issue besides the non-inclusion of compcache ( http://dev.laptop.org/ticket/28 ) is that Terminal's backspace doesn't get processed correctly by screen otherwise I'd spend all my time in Sugar. Right now I switch between console/screen and Sugar/Browse/whatever. pgpxtLiHKe4mz.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] alt-tabbing to the Journal
On Tue, Oct 07, 2008 at 11:31:48AM -0400, Eben Eliason wrote: > On Tue, Oct 7, 2008 at 7:43 AM, Martin Dengler <[EMAIL PROTECTED]> wrote: > > On Tue, Oct 07, 2008 at 12:21:23PM +0200, Tomeu Vizoso wrote: > > > have we reached any consensus on [alt-tabbing to the Journal]? > > > > [some pros and cons] > > You missed one of my biggest reservations in the cons: > > 3. The Journal wouldn't appear beneath the XO at boot. Would you disagree that 1) prescribing a special place for the Journal on boot is treating it _very_unlike_ every other activity; and 2) the Journal always appearing below the XO icon is a feature separate enough from the keyboard-, Alt-Tab-, and frame-accessibility of the Journal that we can seriously consider the notion that those features might apply differently to the Journal than they do to every other activity ...? > It's important to me that the Journal be one click (yes, click; not > just keystroke) away when the child boots the laptop. I will not whinge (nor feel the desire to) that that be changed. > The current activity gets positioned here under the XO, so in the > current paradigm this happens implicitly. This is a happy coincidence of getting the behavior you want (Journal always shows under XO man at start) due to another set of directives (the first activity launched shows under and you've dictated that the Journal launches first) rather than a justification for the set of directives. Or, put another way, that's an implementation detail: the goal is that you want the Journal under the XO, not that a) the journal should be the first activity launched and that b) the current activtity should show under the XO so thus you just happen to get the journal there at boot; if you were to change one of a) or b) you would not happily give up the Journal-under-XO-at boot. > Also: > > 4. The zoom level metaphor is specifically meant to convey the idea of > physical spaces. [...] > The Journal, as a "place for storing things" I think there is no disagreement, or you're saying a "physical space" is different than "place for storing things". Otherwise it sounds like the Journal, as a "place [in which, thus a "space",] for storing things", fits quite nicely within the zoom level metaphor. I also convince myself of that by seeing how I react to the intuition that I "zoom" from Neighborhood --> Friends --> Self --> Desk/Activity --> inside the previous level [Desk]. Zooming inside my desk/activity/XO to see the Journal seems unjarring a transition to be making. Martin pgpsDE6bMgJx6.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] alt-tabbing to the Journal
On Tue, Oct 07, 2008 at 08:55:09AM -0400, Walter Bender wrote:
> 1. When? Nobody's cited examples where it's more desirable to use
> Alt-Tab than the dedicated key.
>
> I use Sugar as much on a non-XO as I do on an XO and so I often don't
> have a dedicated key to access the Journal.
I take your point; I wonder if it's sufficiently vitiated by the
(under-published) Alt-Shift-o ("oh", not zero) shortcut - created to
help out emulator / non XO users. My intent (and I suspect the
original author's) was that all XO-specific keys's behavior would have
keyboard shortcuts so they would be usable from a non-XO Sugar.
> the wonderful world of Emacs
Amen.
> But my rule of thumb is that the Journal should be easier to access,
> not harder.
Yes, but how far do you want to go. I guess I think of the Journal as
part of Sugar and not an activity, and get annoyed when it gets in my
way when looking for activities.
> -walter
Martin
pgpxX6WFOSPMZ.pgp
Description: PGP signature
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] alt-tabbing to the Journal
On Tue, Oct 07, 2008 at 12:21:23PM +0200, Tomeu Vizoso wrote:
> have we reached any consensus on [alt-tabbing to the Journal]?
No, based on http://dev.laptop.org/ticket/6251
> Perhaps someone that cares about changing the current behavior could
> do a summary of the arguments on each side?
*Perhaps* there are only two opposing views; I am biased but will
attempt to summarize the pro (removing-from-alt-tab-list) and the
con (keep-it-as-is-now) views:
Pro:
1. One never wants to Alt-Tab to the journal
2. there is a dedicated key for getting to it
3. the journal should be treated more like a zoom level ("lower" than
the home view).
4. Unnecessarily makes itself the active activity when focused, so now
the Activity/F4 key as well as the search key are dedicated to it.
Cons:
1. One sometimes wants to Alt-Tab to the journal
2. The journal is positioned like an activity in the Frame and UI
I personally respond to the cons as follows:
1. When? Nobody's cited examples where it's more desirable to use
Alt-Tab than the dedicated key.
2.
a) Frame positioning can be changed - there are two proposals and one
with a mockup that synchronizes the keyboard layout with the frame
layout:
http://wiki.laptop.org/go/Image:Activity_management_journal_core.jpeg
b) I don't know what's meant by
"positioned like an activity in the . . . UI" - it seems quite
distinct and more like another zoom level to me, and the journal is
never launched like other activities are (neither from Home, Mesh,
Neighborhood zoom levels, nor resumed from itself).
> Thanks,
>
> Tomeu
Martin
pgpIBC83wZUlB.pgp
Description: PGP signature
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] human factors when launching an activity
On Wed, Oct 01, 2008 at 03:06:34PM -0400, Mikus Grinbergs wrote: > [many rhetorical questions] > > > dbus-send --session --print-reply --reply-timeout=2000 \ > > --type=method_call --dest=org.laptop.sugar.DataStore \ > > /org/laptop/sugar/DataStore org.laptop.sugar.DataStore.unmount \ > > string: > > THIS is what I have the greatest amount of difficulty with. I fail > to see the necessity of users having to learn the "internals" of > dbus usage in order to be able to control their systems. If there > is a "knob" that users need to turn, DOCUMENT IT !!! The journal UI lets you unmount one device already. It's documented already. Why is another way of doing it, automatable and suitable for very advanced users doing unusual things (like you), causing you difficulty? > Besides which, I have my removable storage devices mounted __for a > purpose__. [They contain software and data which I reference every > time I use the system.] I have no intention of unmounting them. So I'm puzzled as to why would you single out the launch feedback feature. I now understand that your XO's cpu is busy for reasons that you know about, and you're just noting that one UI feature that depends on being able to run quickly doesn't run so quickly when the cpu can't run it quickly. And that that happens only when you do something that most people don't do. Of course it'd be great if people could do that without such deleterious effects. > mikus Martin pgpNTLJmSHqXW.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] human factors when launching an activity
On Wed, Oct 01, 2008 at 09:52:24AM -0400, Mikus Grinbergs wrote: > Last night did a lot of activity launching (on 766). My overall > impression was that feedback by the system was way too slow. In my experience the feedback is very fast (less than 1s to come up, which is hard to ignore unless you're double-clicking). About two weeks ago I had this same impression as you do now, though, before I noticed that it was because the datastore was busy indexing a few kernel build trees on two usb drives I had plugged in. When I stopped plugging those drives in[1], the problem went away and the activity launching feedback was very acceptable. Are you sure that the machine is otherwise idle when you're experiencing these undesireable delays? Martin 1. Or just forcibly unmounting them from the datastore (but not the actual filesystem, IIRC), by doing something like: dbus-send --session --print-reply --reply-timeout=2000 \ --type=method_call --dest=org.laptop.sugar.DataStore \ /org/laptop/sugar/DataStore org.laptop.sugar.DataStore.unmount \ string: ...for example, ugly little script to tell the datastore to unmount all the plugged in devices: #!/bin/bash datastore_mount_ids=`dbus-send --session --print-reply --reply-timeout=2000 --type=method_call --dest=org.laptop.sugar.DataStore /org/laptop/sugar/DataStore org.laptop.sugar.DataStore.mounts | grep 'string "[0-9a-z]\+-' | cut -d '"' -f 2` for id in $datastore_mount_ids ; do echo -n ds unmount $id... dbus-send --session --print-reply --reply-timeout=2000 --type=method_call --dest=org.laptop.sugar.DataStore /org/laptop/sugar/DataStore org.laptop.sugar.DataStore.unmount string:$id done pgpKpaloLhLid.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame gets in the way when alt-tabbing
On Mon, Sep 22, 2008 at 06:05:34PM -0400, Luke Faraone wrote: > On Mon, Sep 22, 2008 at 16:58, Mikus Grinbergs <[EMAIL PROTECTED]> wrote: > > > [Since there is a key dedicated > > to bringing up Journal when needed, I sometimes patch homemodel.py > > to not even show Journal during alt-tabbing.] > > > > I was thinking about posting this even before I finished reading this. > > +1 on both hide-the-frame and [...] http://dev.laptop.org/ticket/8120 might be of interest > [...] dont-alt-tab-to-journal. Perhaps interested parties could advocate on http://dev.laptop.org/ticket/6251 > -LF Martin pgpSmdmW0mBCG.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Impressions of Sugar's appeal to technical users (was: Supporting desktop applications, extending the EWMH spec)
On Mon, Sep 22, 2008 at 02:52:09PM -0400, Erik Garrison wrote: > On Sun, Sep 21, 2008 at 05:01:41PM -0400, Michael Stone wrote: > > My impression, based on historical conversations with the parties > > involved is that there are a bunch of hackers who feel that we did > > ourselves a disservice by dropping _so much_ backwards compatibility, > > specifically with Unix filesystems and desktops, in exchange for > > cool ideas. The feeling is that had we traded compatibility for features > > less aggressively then there would be many more hackers available to > > help write the features since there would be many more hackers who felt > > it was possible to live within Sugar. > > > > This is just an impression, however. > > For what it's worth, it is also my impression. I have heard similarly > from virtually all technically-oriented parties involved. I have heard > echos of this from less technical users (e.g. teachers who are confused > by the behavior of the journal). As an outlier, it seems, I found it interesting to explore the different views and apps^Wactivities and wasn't put off since I didn't expect a "normal" laptop experience straight away. I get annoyed by most GUIs pretty quickly, but with Sugar/Browse/Read + Terminal I have, doing the standard Internet-kiosk type stuff I find myself doing away from home, few annoyances that aren't generated by non-Sugar limitations (keyboard, distro choices like evince/gnash). I'm being very modest in my GUI expectations, but I've rebuilt kernels (and modules/initrd) a number of times (3hrs with my - undoubtedly slow - SD card) and muck about with gcc and git a lot, so I wouldn't say I exactly fit the profile of a minimally demanding user. I found it interesting to work out how to restore items from the various datastore/ directories into the current journal (thankfully not necessary any more!). > Erik Martin PS - I think these impressions are quite valuable for both historical context and future direction: however people might feel tempted to dismiss criticisms as vague or outdated, they need to be considered when we tout and improve Sugar or the OLPC distro. PPS - I realized in changing the subject that perhaps the "hackers" and "technically-oriented parties" whose impressiosn were mentioned are being assessed as (prospective) activity authors more than "technical users" or sugar hackers. This might be useful to clarify. pgpBYdW2BTFSK.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Finale: consider merging a few fun Sugar patches?
On Thu, Sep 18, 2008 at 04:05:26AM -0400, Michael Stone wrote: > >> On Thu, Sep 18, 2008 at 2:30 AM, Marco Pesenti Gritti > >> <[EMAIL PROTECTED]> wrote: > >>> * At *very* high level the patch sets looks sane. I would be > >>> comfortable with them going in if Scott reviews Martin set, and Martin > >>> reviews Scott set. [...] > I guess these can be first-on-deck for 8.2.1 I'll do my review but Scott need not worry about mine since my patches are already in 0.82.1[1] and 8.2-758[2]. > Michael Martin 1. http://dev.laptop.org/git?p=sugar;a=commit;h=434ab0ce729a670a119f033386190eaf6a8827ca 2. http://mock.laptop.org/gitweb/gitweb.cgi?p=repos;a=commitdiff;h=e0489cd6dec4b910445f489632adb44ba136c1c1 pgpGg4oDHBi8H.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] G1G1v2 Activities
On Wed, Sep 17, 2008 at 05:54:45PM -0400, Greg Smith wrote: > Hi All, > > We need to pick the activities we ship with 8.2 when its manufactured > for G1G1 users. [...] > What do you think are the most important activities to include? > > Please pick up to 10 and put them in order of priority. Going over http://wiki.laptop.org/go/Activities , there are so many cool ones it's frustrating to pick only 10. 1. Browse 2. Write 3. Read 4. Record 5. Pippy 6. eToys 7. TamTamJam 8. Paint 9. Implode 10. x2o I didn't pick Terminal to squeeze in one more and I pretended that the console might be enough (but I don't believe you'd ship without Terminal). > Thanks, > > Greg S Martin pgpKLnMITldC4.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] control panel keeps focus
On Fri, Sep 12, 2008 at 08:52:07AM +0200, Simon Schampijer wrote: > Mikus Grinbergs wrote: > > [...] should the Control panel "take over" > > what the user sees, such that the user would have to complete what > > he was doing with the Control Panel in order for the Control Panel > > _NOT_ to "overlay" any other screen that the use might wish to see ? > > > > mikus > > [...] eben what was your intention here? http://dev.laptop.org/ticket/7642 and http://dev.laptop.org/ticket/7882 seem relevant. > Best, > Simon Martin pgpc3UJoViaXf.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] screenshots hurt
On Fri, Sep 05, 2008 at 11:28:17AM -0400, C. Scott Ananian wrote: > general antagonistic tenor of the thread Sorry if I caused/contributed any part. > * Quantitative measurements. "Switching performance is down to x ms > rather than x ms". Perhaps rl's tests could be run? I don't know of good ways to measure the actualy performance, since in some noddy tests I last did I would see map and expose events in code far enough ahead of the actual rendering to dissuade me from believing they actually allowed useful measurement of the user experience. > * Thorough testing. It is possible to launch an activity and close it > without a screenshot ever being taken. What happens in that case? I did that test with erikg's first patch, and a "no preview available" thumbnail is shown. My testing was not exhaustive but gave me plenty of confidence that at least the obvious/normal case was gravefully handled. > * More moderate solutions. We're currently taking a lot of > screenshots. Can we quantify what the benefits of taking "fewer" > screenshots without making this into an all-or-nothing discussion? I think erikg's latest patch is pretty moderate - it takes screenshots when the user saves the state. If someone can come up with an even more moderate solution, of course, that'd be great. > [other suggestions: > [throttling the screenshot rate] > [improving screenshot-taking performance] > [API for activities to request a screenshot be taken] The disadvantages of the other suggestions - though certainly more moderate - include 1) a bit to a lot more complex; and 2) no patch exists to implement/use them. That being said, the API for activities to take a screenshot of themselves already exists[1], and when combined with your activity updater it'd be pretty trivial for an activity version to be released to take a screenshot of itself more frequently. > UI-centric approach It is a shame that this discussion has taken place when Eben isn't around, as I'm sure it could benefit. As lots of the Sugar guys are busy as well, I'm sure some more opinions will come around soon... > --scott Martin 1. http://dev.laptop.org/git?p=sugar-toolkit;a=blob;f=src/sugar/activity/activity.py;h=73eeea7499dcd4dcd28cea5c55648b8f414654e9;hb=HEAD pgpzkNcFfOjAT.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] screenshots hurt
On Fri, Sep 05, 2008 at 11:47:45AM -0300, Erik Garrison wrote: > The current patchset guarantees that [journal previews] will exist > provided the user intentionally saves their work, or properly closes > the activity. IMO this is the key factor in deciding how much compromise is too much: the compromise being between, on the one hand, a real-time-updated thumbnail of activity if it's currently running; on the other hand, no thumbnail it all. The factors each solution would be judged by include performance, decrease (from the ideal) in usefulness, activity code / API complexity. The two competing compromises, that lie just astride some key boundary in the solution space, seem to me to be: 1) saving (the thumbnail preview, but also I imagine the actual application state as well) just often enough that the user will never be surprised that, when resuming, the state isn't as they last left it; and 2) saving only as often as the user explicity asks to save (and at application shutdown, if possible - currently, this means the app has to be visible) Your patch does #2, I believe. > Can these be implemented and tested quickly? If not perhaps we should > implement this patch and reintroduce the current functionality when > these features are complete. FWIW, I think that the features being sacrificed are not used often enough to justify the loss in performance. > Erik Martin pgpeGLEkAQaiz.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] screenshots hurt
On Thu, Sep 04, 2008 at 01:57:49PM -0400, Greg Smith wrote: > Hi Guys, > > OK I think I get it. > > Isn't the Icon in the journal always the same for any given > activity? Yes. But the screenshot is for the preview in the detail page of a given journal entry. When you get to an XO, click on the icon that looks like a greater-than sign (right-pointing arrowhead thingy), and you'll get taken to the detail page for that journal entry. Towards the middle-left of the page you'll see a rectangular area where the preview will be. > BTW will this improve frame open and close rates? Yes, because less CPU activity is contending with it. I seem to remember a debate/proposal about/to make the frame just appear, not slide in as it does now (I think bemasc was advocating it). Might be worth revisting. > Thanks, > > Greg S Martin pgp0LqaEPHxI3.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] LiveCD LiveUSB
On Tue, Sep 02, 2008 at 02:34:14AM -0400, Ivan Krstić wrote: > On Sep 1, 2008, at 10:25 PM, Sameer Verma wrote: > > We should also put it up via torrent. > > Why? We have plenty enough bandwidth to satisfy demand over plain HTTP. I don't know that HTTP server <-> closest POP bandwidth capacity and/or cost is a reason to discourage torrents; if many seeders are behind a slow link then the total download speed can be faster for a leecher on the same side of that slow link. I expect a low/negative bandwidth advantage of a torrent over HTTP for the people I can imagine downloading a LiveCD. Notwithstanding, is there a reason to discourage it (admin overhead, for example)? > -- > Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org Martin pgpySkWMhzBKR.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Code-review] Please review recent rainbow patches.
On Wed, Aug 27, 2008 at 10:21:23PM -0400, Michael Stone wrote: > I've got a small flurry of rainbow patches (everything from > rainbow-0.7.19..HEAD in http://dev.laptop.org/git/users/mstone/security) > that could use a bit of review. I had a quick look and didn't see anything worth commenting on. Probably this is not the feedback you were looking for, but... > Many thanks, > > Michael Martin pgpozt7nTYLz8.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Removing docstrings
On Wed, Aug 27, 2008 at 02:54:05PM -0400, C. Scott Ananian wrote: > Do folks think it's worth trying out -OO in joyride? FWIW (IANASugarDeveloper), yes. > --scott pgp20biqyETUC.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] how can communications mode be manually controlled ?
On Tue, Aug 26, 2008 at 12:48:02AM -0400, Mikus Grinbergs wrote: > 1) To turn OFF both communication with the mesh and communication > with the AP, use the control panel. Either Network --> Radio or Power --> Extreme Power Management seemed to work for me. > But the control panel only has a checkbox for 'radio' - what if > I want to turn OFF both mesh and a *wired* AP ? What do you mean by "wired AP"? Perhaps with Extreme Power Management you can lose the USB bus, which might do something like you want. > 2) To turn off mesh, click on wireless AP; to turn off wireless AP, > click on mesh (assuming no obstacles caused by bugs). Yes. If by "turn off" you mean "do not use", in particular. > But will the indicated communications mode persist, or will > Network Manager soon switch back (e.g., if there is no AP) ? Whatever you've "click[ed] on" will persist until NM decides it's not usable any more, roughly. > mikus Martin pgpBp7ZQY1WyC.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Landing patches about the network devices UI
[for the interested but impatient: http://dev.laptop.org/~mdengler/2866/2866_screenshot_20.png http://dev.laptop.org/ticket/2866 ] On Mon, Aug 25, 2008 at 02:19:02PM +0200, Marco Pesenti Gritti wrote: > we have a couple of patches that should be ready to be reviewed by > tomorrow, which solves several issues with the UI of network > devices. I've submitted the patches for: > #6944 UI confuses which AP you are connected to > #3993 The color of network icon in Home view becomes white after > restarting Sugar. > #2866 Network Manager GUI doesn't report success or failure ...which (the patches' content) you summarised as: > 1 Adds "IP address" to the mesh & wireless palettes, with associated > changes to their model classes. [...] > 3 Makes both frame icons pulse. [...] > 5 Fix some iconsistency in the icon states by cleaning up the code. ...because of the general agreement with: > * [land 1 and 5] for 8.2.0 (before Friday) This UI now looks like: http://dev.laptop.org/~mdengler/2866/2866_screenshot_20.png Any feedback welcome. (I haven't screenshotted the mesh icon because I'm hoping a new firmware will be out soon and I can test by rolling forward to a new joyride, rather than having to roll back to an old one) > Thanks, > Marco Martin PS: I wish we could risk some regressions as the full UI Eben wanted[1] will not be realized (Eben/Bert have already articulated reasons for wanting that), and I would like to run a patch for that by you / into joyride just in case you may have occasion to change your mind. 1. Something like: http://dev.laptop.org/~mdengler/6995/6995_screenshot_50.png http://dev.laptop.org/~mdengler/6995/6995_screenshot_51.png pgpAvFdVGdDbw.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Landing patches about the network devices UI
On Mon, Aug 25, 2008 at 02:19:02PM +0200, Marco Pesenti Gritti wrote: > we have a couple of patches that should be ready to be reviewed by > tomorrow, which solves several issues with the UI of network devices. [...] > 1 Adds "IP address" to the mesh & wireless palettes, with associated > changes to their model classes. Note this - part of #2866 - currenlty introduces one new string: "IP Address". I'd argue this should be un-translated/localized if this is a problem. What should I do? > Thanks, > Marco Martin pgpb3PXPGH0M3.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Landing patches about the network devices UI
On Mon, Aug 25, 2008 at 03:19:19PM +0200, Morgan Collett wrote: > On Mon, Aug 25, 2008 at 15:13, Walter Bender <[EMAIL PROTECTED]> wrote: > > [in joyride/8.2-756] the mesh icons don't show up on either the > > Neighborhood view or the Frame > > That seems to be a regression in the firmware, with the msh0 interface > not coming up - not a sugar problem... This is #8133: http://dev.laptop.org/ticket/8133 . > Regards > Morgan Martin pgpxOHTSNzZRz.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] commanding what the screen should show
On Sun, Aug 24, 2008 at 02:21:31PM +1200, Martin Langhoff wrote: > On Sun, Aug 24, 2008 at 6:14 AM, Mikus Grinbergs <[EMAIL PROTECTED]> wrote: > > It seems to me that the XO had "stacked" my last keypress (the F3), > > and upon resuming Sugar had "fed in" that stack. > > I've seen this too, and been annoyed by it. My theory is different - X > is catching the /release/ event of the F3 key. Don't forget #7442. Put the focus in a text area before you switch away from X, and then see what gets put in there when you switch back. It's some of the last few keys you've pressed. http://dev.laptop.org/ticket/7442 > m Martin pgpQ7wY27F7Bb.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] New wireless/mesh icon info testers needed (#2866, #6995)
Hi,
I'm looking for joyride testers with 10 or so minutes willing to pull
down a git clone and temporarily use it for their Sugar session to
test these behaviors:
http://dev.laptop.org/~mdengler/2866/2866_screenshot_10.png
http://dev.laptop.org/~mdengler/2866/2866_screenshot_12.png
I'd be very interested in any feedback. If you care to read some
recent design discussions, I'd glance at this:
http://dev.laptop.org/ticket/6995#comment:27
In order to test, you will need to have a recent joyride (anything in
the last few weeks should be fine) and to follow the instructions at
http://dev.laptop.org/~mdengler/2866/test2866.txt :
cd /home/olpc
git-clone git://dev.laptop.org/users/mdengler/sugar xo-sugar-2866
cd /usr/share/sugar/shell
for dir in hardware model view ; do sudo mv $dir ${dir}.orig ; sudo ln -s
/home/olpc/xo-sugar-2866/src/${dir} ; done
To uninstall, just:
cd /usr/share/sugar/shell
for dir in hardware model view ; do sudo rm ${dir} ; sudo mv ${dir}.orig $dir ;
done
Many thanks to garycmartin for being a courageous alpha tester
already. Gary, if you want to test these updates, rewind[1] your git
clone and re-pull.
Thanks,
Martin
PS - this is the bug I'm trying to address:
http://dev.laptop.org/ticket/2866 , and this is bug that this is a big
part of: http://dev.laptop.org/ticket/6995
1.
cd /home/olpc/xo-sugar-2866 # or wherever you put it
git-reset --hard HEAD~10 # 10 back should be enough ;)
git-pull
pgpmLkQTd1Acm.pgp
Description: PGP signature
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] letting the user specify the mesh channel
On Thu, Aug 07, 2008 at 03:45:07PM +0200, Christoph Derndorfer wrote: > The only thing I'm wary about is whether the IP address should be there. As you can imagine it's easy to remove. I'm sure the authorities will opine soon. > It might be useful for devs and some G1G1 people but for children and > teachers in the deployments this gotta be confusing... Indeed. I'm tempted to argue it'd be great if more people using computers were to ask "So, what is an IP address anyway?". I can imagine many counter arguments, but still. > Just my 2 euro-cents, > Christoph Thanks for the feedback. Martin pgp9e5V2V1xEL.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] letting the user specify the mesh channel
On Thu, Aug 07, 2008 at 08:25:15AM -0400, Mikus Grinbergs wrote: > A question for Eben: Though I'm not eben... > Will the user still (now using the Frame) be able to choose to > specifically "mesh" on channel 11 ? Yes. See http://dev.laptop.org/~mdengler/6995/6995_screenshot_45.png for an example of how I currently have it looking. > mikus Martin pgpXKTAEAhnIO.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] New joyride build 2258 (Eben Eliason)
On Thu, Aug 07, 2008 at 02:20:06AM -0400, Mikus Grinbergs wrote: > There is a practical problem with opening the software-updater the > first thing after a build install This isn't going to be done any more, IIUC. > Also, I've encountered difficulties if my XO 'suspends' while I am > trying to download from the internet -- to run software-updater > reliably on my system, would 'suspend' need to be inhibited first? Might be the same http://dev.laptop.org/ticket/7834 > mikus Martin pgplxSiVyZXqe.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] How do I connect to a Jabber server ?
On Sat, Aug 02, 2008 at 10:10:09PM -0400, Mikus Grinbergs wrote: > Eben wrote: > > There has been lots of confusion about the difference between mesh and APs. > > They're really not the same at all, apart from the fact that they both > > depend on the radio. The new design no longer treats the mesh channels as > > objects in the Neighborhood view. Instead, there will be (is? not sure if > > the patch landed yet) a mesh device in the Frame, which you can turn on (and > > off?) at whim. > > I am anxiously waiting to *use* some of these improvements. Sorry for the delay in landing #6995 - there are a number of improvements I keep trying out, delaying the patch. But, this time, it's almost ready. I had one volunteer on IRC who might be able to help me test before I ask for wider testing. > For people in my situation, what I want is to be able to 'turn off' > the XO trying to reach the 'school server' via the mesh (I'm a G1G1 > user, and will *never* have a 'school server' where I live). > Instead, I want my XO to try HARDER, via the AP to which it is > connected, to reach whatever (Jabber) server I've specified. I am in the same situation and would like the same feature, but I don't think things are too possible with the current NM: see http://lists.laptop.org/pipermail/devel/2008-August/017686.html > mikus Martin > p.s. These may be written down somewhere - but I've not been able > to find explanations for "how to move a connection" : It Just Happens - Network Manager notices a connection is down (somehow? probably device- & kernel-specific) and starts looking for new ones. But applications probably won't like this. There was a huge thread on devel@ in Jan/Feb IIRC debating this, but basically I think activities (the underlying APIs they use, mostly) will vary in how well they deal with IPs changing and their network sockets getting closed. > (A) Suppose a kid is communicating with his 'school server' via the > mesh. Then he walks so far away that his radio no longer reaches > the school. If he happens to be within range of an alternate AP, > how would the transfer from 'using mesh addressing for the school' > to 'using internet addressing for the school' be handled? [Does the > kid ever have to do something manually, such as re-starting Sugar ?] ibid. > (B) Suppose a kid is using the Jabber facilities at his school to > contact an "overseas" buddy. Suddenly the communications link > between the school and the internet fails. If the kid happens to be > within range of an alternate AP, does he have to do something > manually (such as entering the name of a non-school Jabber server) > to re-establish Jabber contact to the outside world ? No idea, sorry, but I don't think your question is a conventional one. Jabber servers can be federated but I don't know of any that are, nor if and XS's jabber server is. But I think you're mixing up "connected to a Jabber server / server-cloud" and "connected to an AP". The latter is a pre-requisite for the former but doesn't necessarily imply reachability of the former. So if you change your AP, that may have nothing to do with connectivity to the jabber server by which one was chatting to an overseas buddy. pgp5wEZhCFwdo.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Design Question
On Mon, Aug 04, 2008 at 07:04:46AM -0400, Greg Smith wrote: > Hi Martin et al, > > It was near unanimous to default to the Ring. [...] > There is a bug open now to default to Ring: #7759. Thanks for mentioning the bug. I've updated the bug and pushed bobby's patch to sugar-toolkit git. > Thanks a lot for asking. Thanks very much for starting the discussion and responding/ending it clearly. > Thanks, > > Greg S Martin pgpMbsXMFGjte.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Design Question
On Fri, Jul 18, 2008 at 04:53:31PM -0400, Greg Smith wrote: > Hi All, > > Can I get a quick +1/-1 on this question related to > http://dev.laptop.org/ticket/7331 [...] > Vote for your favorite as "default first exposure to OX" and let's see > if we are close to consensus... What was the outcome? > Thanks, > > Greg S Martin pgpF81YzgLgh5.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] current network differentiation?
On Thu, Jul 31, 2008 at 06:26:52PM -0400, FFM wrote: > On Thu, Jul 31, 2008 at 11:13:23PM +0100, Martin Dengler wrote: > > > [...] turn off the radio [...] > > That'll work as long as there isn't a noticable delay when visiting the > network view (time between > viewing and network survey) Exactly[1]. I believe it could easily be fast enough to detect APs, but I'm not sure about joining a mesh (because I've never joined one and I don't know how it feels vis-a-vis AP scanning - which is fast). I believe (on vague memory) that NM only scans for APs every so often (20s? 40s?), so even what we're showing people now might be a bit inaccurate; in which case, to be sneaky[2], we could just leave all the icons in the MeshBox as-is when we disconnect, and then the user would see them all update one or so second later when the radio and NM came back online. Alternately, some UI could be introduced in the Mesh view (think like the "Journal is empty" or "Journal shows no matching items") to indicate that the radio was coming back online. > -FFM Martin 1. > On Thu, Jul 31, 2008 at 3:37 PM, Martin Dengler wrote: > I then suggested that this would work if the restoration of power > was quick enough that switching to the Neighborhood view could power > back on the radio and update the icons in some acceptable lag. > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar pgpVDTVrE0J2u.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] current network differentiation?
On Thu, Jul 31, 2008 at 05:42:26PM -0400, Eben Eliason wrote: > On Thu, Jul 31, 2008 at 3:37 PM, Martin Dengler <[EMAIL PROTECTED]>wrote: > > > On Thu, Jul 31, 2008 at 03:23:47PM -0400, Eben Eliason wrote: > > > The new design does not make any indication of which > > > network is presently associated in the Neighborhood view; perhaps we can > > > find an alternative method. Thoughts? > > > > Perhaps the currently-associated network's icon can appear below the > > XO icon, as the Journal does initially in the Home view. > > > > Could be tricky, since (hopefully soon) the view will be fixed so that the > current activity is beneath the XO, consistent with the Home view. There > may be other options, though. It could also be made bigger (for a while I kept patching my MeshBox.py to make favorite icons bigger) than the others. Or a 128/128/128 rgb ring could be drawn around it. Well, you asked for ideas :). > > cjb suggested to me on IRC that Disconnect/Turn Off (for > > wireless/mesh, respectively) could just cut power to the radio. I > > then suggested that this would work if the restoration of power was > > quick enough that switching to the Neighborhood view could power back > > on the radio and update the icons in some acceptable lag. > > > Again, I don't think this is really the desired semantic. It's /almost/ > right, and is the traditional means of achieving this, but that also turns > off the ability to be on the mesh, which isn't necessarily what one means by > "disconnect from this AP". They should be independent. I realize this > isn't as crucial right now, since we can't be on both mesh and AP at the > same time, but in the future it's pretty clear that they need to be > orthogonal. I guess if they won't be independent for 8.1.2 it seems like it's exactly the right thing to do - whether I'm on the mesh or the AP, if I want to disconnect from the wireless and connect to the mesh I just hit the mesh channel in the mesh palette, so if I select "disconnect" I don't want to do that and thus have no use for the radio; and if I disconnect from the mesh I definitely don't need an AP (if I did, I would've chosen it). We thought about just doing a NetworkManager sleep, but then, well, again, what is the radio then good for barring drawing 1W of power :)? > > This problem (and it affects "Extreme power mode" too) is > > recorded in #7690. > > > > > The old behavior used to > > > switch into mesh mode, which disassociated with the network itself. > > > > This is much less desirable than powering off the wireless, IMO. > > > I agree. That's why there's no longer a disconnect option. We thought it > was better to remove it until it has a proper semantic, rather than > implement it in a peculiar and not readily understandable way. Again, "Disconnect" and "turn off" the wireless and mesh (respectively) seem to have quite intuitive semantics (to those not familiar with MPP usage): turn off the radio, since I don't want to use what it's providing (wireless or mesh connectivity). > - Eben Martin pgpU69izE0xtJ.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] current network differentiation?
On Thu, Jul 31, 2008 at 03:23:47PM -0400, Eben Eliason wrote: > The new design does not make any indication of which > network is presently associated in the Neighborhood view; perhaps we can > find an alternative method. Thoughts? Perhaps the currently-associated network's icon can appear below the XO icon, as the Journal does initially in the Home view. > i'm also not sure how to disconnect from that network -- there's no > > "disconnect" option in the popup anymore. > > > > Well, that's a "bug", but not really. The problem is that there is no > notion of "disconnect" in network manager at all. cjb suggested to me on IRC that Disconnect/Turn Off (for wireless/mesh, respectively) could just cut power to the radio. I then suggested that this would work if the restoration of power was quick enough that switching to the Neighborhood view could power back on the radio and update the icons in some acceptable lag. I have implemented[1] and tested this behavior (as part, but not a necessary part, of #6995) and I believe it fast enough for further investigation and testing. The only problem is that it's very cumbersome to bring back up the msh0 interface correctly, and would require some code changes in a variety of places in sugar. This problem (and it affects "Extreme power mode" too) is recorded in #7690. > The old behavior used to > switch into mesh mode, which disassociated with the network itself. This is much less desirable than powering off the wireless, IMO. > However, we now have a more direct means of accomplishing this, via turning > the mesh device on or off explicitly. This is spec'd but subject to #7690, IIUC. > - Eben Martin 1. Some example entry points: wlan_radio.py: http://dev.laptop.org/git?p=users/mdengler/sugar;a=blob;f=src/hardware/wlan_radio.py;h=47b70474fe503e90d74c4aecf5ed4cd1992f8412;hb=4a455159e61ac2ce1ed47059dccf5a8ba18ebd80 MeshBox.py changes (last last diff block): http://dev.laptop.org/git?p=users/mdengler/sugar;a=commitdiff;h=4a455159e61ac2ce1ed47059dccf5a8ba18ebd80 pgpmZMGKeb4xv.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Proposal: Activity developers mailing list
On Thu, Jul 31, 2008 at 11:47:56AM +0200, Morgan Collett wrote: > On Thu, Jul 31, 2008 at 04:42, Bastien <[EMAIL PROTECTED]> wrote: > > Any follow-up on the idea of having a precise list of maintainers for > > all Sugar activities? Even just the email address from the git repo > > would be nice. > [...] > * We need to make it easier for new activity developers to get up to > speed without having to wade through information they don't need. > > I am happy to take on making this communication happen but I really > think we need this list. I think this is a good idea too, especially given that you're motivated to do it. > Morgan Martin PS - I'd say +1 but please remember http://kernelslacker.livejournal.com/125203.html pgptTEihPTtdG.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Xephyr rpms
On Thu, Jul 24, 2008 at 06:50:25PM +0200, Marco Pesenti Gritti wrote: > Hello, > > ajax built new Fedora 9 rpms which should contain the fix for Xephyr on > x86_64. Thanks - that's awesome. > Marco Martin pgpXdhVrtlKb3.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar (kid contributions)
On Wed, Jul 23, 2008 at 06:27:59PM -0700, John Gilmore wrote: > [some interesting points] Sorry my meta-comments snuck in - they aren't relevant, and I didn't follow my own advice...I retract them (I'm sure you can tell what parts they were). > => Do any frequent contributors have ONLY an XO? <= As I've been fiddling around with a patch or two, my jhbuild has been broken due to x86_64 Xephyr F9 brokenness that's been recently fixed (thanks dodji, if you're listening, and cjb/marco for pushing), so please count me among those contributors who only have an XO (temporarily). > But the tools needed to be a contributing part of the Sugar community > don't run on the XO. [...] > Merely installing the change without trashing his XO's entire GUI > with a typo or missing Python file is tricky. After restarting X/Sugar so often to test patches for #6995, I've developed an itch for a Sugar-shell-REPL in Pippy, or something similar. Perhaps that's one way for people in the field to tinker. Of course there are diff/code browsing issues still. > John Martin pgpozqXekP4W5.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar (kid contributions)
On Wed, Jul 23, 2008 at 06:27:59PM -0700, John Gilmore wrote: > > > 2) Sugar would run more smoothly on-XO if jhbuild were retired. > > I think this is a good point in the abstract. Do any frequent contributors > > *not* have an XO? > > I approve of retiring jhbuild, and handing out XO's to Sugar > contributors, but you've really got the question backwards: > > => Do any frequent contributors have ONLY an XO? <= Yes, I've taken it on a tangent, as I promised in my boilerplate. Thanks for getting back to the topic. Is the question really best phrased as you did? Are you really asking "should the contributor community only use XOs"? It seems you're asking "how can we turn our XO deployment kids into contributors", which is a great question. I think the way forward is to raise some awareness (as you're doing) and constructively move the discussion forward. > I've seen lots of high flying rhetoric about Sugar being maintainable > and extensible by kids with their XO's, because it's in an easy > interpreted language shipped in source, etc. You have almost 500,000 > units in the field (admittedly in younger kids). Seen any Python > prodigies contributing yet? The sound-bite rhetorical question distracts from your later good points. Especially given the point is educating kids, I'm not so concerned that kids learning english and maths haven't sent sugar patches in yet :). > But the tools needed to be a contributing part of the Sugar community > don't run on the XO. [...] > Merely installing the change without trashing his XO's entire GUI > with a typo or missing Python file is tricky. Indeed! How can we as the community improve the extensibility while letting the core people get on with developing the core (and yes, I know the core has to be extensible, and I think it's good to keep raising the point; but we also need to *do* something about it - any ideas? I would be very interested in working on some, and coming up with some when I'm finished my one or two patches I'm working on now). > If we want the kids who *love* their machines to come to *know* and > *evolve* their machines, there's a lot more work to be done. Indeed. I quote this not for the mindless "me too gnu++ kthx" but to highlight it more - I think it gets lost a bit in your detailed points. > In many ways the unique XO UI and collab setup make the learning > curve steeper, not easier. I don't know this to be true, and I suspect it to be a distracting falsehood. But let's try to address the more fundamental issues (like no diff / diff-like utility / tools) you raised earlier. > John > Sugar is hung up in its own maintenance > machinery. I don't think you (only) mean Sugar here. Very interesting comments, btw. Thanks. Martin pgpNcSDK38Cod.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
meta-comments: 1) I think all this discussion should be interpreted in
the spirit of "how can we do better, and what can we be focused on in
the next year", rather than "this is why things are bad" (because
they're not). I'm not sure a casual reader would understand this.
2) I'll leave more involved people to comment on the main substance; I
have just a few tangential but possibly interesting notes:
On Tue, Jul 22, 2008 at 07:49:23PM -0400, Michael Stone wrote:
> After mild provocation, Marco and Tomeu asked me to publish some of my
> reactions to sugar's architecture, design, and implementation. Here are
> a few initial comments.
>
> 1) Sugar could better hold contributors if it (and its web presence)
> were designed to be extended and to highlight external contributions.
>
>Evidence: Trac and xmonad both have thriving communities of
>contributors based around their plugin architectures and community
>sites like trac-hacks.org.
It's not immediately obvious to me that community building around
developer-targeted software is the same as around Sugar's community
building needs (as Sugar isn't meant to be used primarily/only by
developers).
Notwithstanding, this visualization of python's contributor pattern:
http://www.vimeo.com/1093745
...would seem to caution against getting too despondent about
community contrbutions just yet. For the impatient (but it's kind of
good eye candy.; check it out), it's about two (2) years before any
major contributors appear, four (4) years before the next infusion of
checkins, after five (5) years some significant documentation (and a
documentor) appears, and after about *eight* (8) years there finally are
over three very substantial committers.
>Evidence: Sugar has already attracted new contributors by creating
>three different extension points:
>
> Activities themselves
> Device entries on the Frame
> Control Panel Entries
>
>Evidence: Non-extensible aspects of Sugar like activity launching,
>home view layout, frame contents, and the presence service have
>stagnated.
You're slightly begging the question ("non-extensible aspects" have
"stagnated"). But I think others have pointed out the home view
layout and (less so) frame content progress. I think a better phrase
than "stagnated" is "not progressed as fast", and that this is a
natural and expected outcome of too little development and community
building resources.
> 2) Sugar would run more smoothly on-XO if jhbuild were retired. By
> running at non-XO speeds, jhbuild permits Sugar developers to retain
> faulty assumptions about the environment in which their code will
> run.
I think this is a good point in the abstract. Do any frequent contributors
*not* have an XO? Has anyone considered "marketing" the development
by unsolicited "indefinite loan" XOs being sent to vulnerable ( :) )
developers? Consider positive benefits like:
http://www.artima.com/weblogs/viewpost.jsp?thread=148064
> Regards,
>
> Michael
>
> P.S. - Let me know if you'd like to see more such remarks in the future
> (perhaps on other subsystems?) or if you'd like to see more detailed
> exploration of any of the items noted above.
I think these types of comments are very valuable, but would be (even
more) constructive (because they'd be less general) if they were made
on a subsystem-by-subsystem basis.
Martin
pgpu7qG1tq4hp.pgp
Description: PGP signature
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] External contributions (Re: Remarks on the Work of Sugar)
On Wed, Jul 23, 2008 at 12:03:42PM +0200, Marco Pesenti Gritti wrote: > On Wed, Jul 23, 2008 at 11:33 AM, Simon Schampijer <[EMAIL PROTECTED]> wrote: > > Sure, some guidance is needed. [...] > Tomeu, Simon and Eben has been much more proactive and, what matters > most, more *succesfull* than anyone else in helping out the community > to participate. They deserve credit and instead they are getting > blame. Absolutely - I have lurked on IRC a lot and they are doing a great job when people come in. They do indeed deserve credit. > Guys, keep it up. Getting flames *and* praise is almost a guarantee > that what you are doing is worth something. This is an true and often overlooked point. > Marco Martin pgpcKo3loJMGR.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
On Wed, Jul 23, 2008 at 11:33:38AM +0200, Simon Schampijer wrote: > Martin Dengler wrote: > >On Wed, Jul 23, 2008 at 09:36:27AM +0200, Simon Schampijer wrote: > >>For sugar core - I don't think that 'small fixes' need more than > >>python skills. > > > >I agree. Of course people also need "the knowledge about where to put > >those python skills to work". [...] > Sure, some guidance is needed. I hope we have done a decent job to guide > you to the places to provide your great fixes :) Yes, you (plural) have! Thanks! I didn't mean to imply otherwise. > Thanks! >Simon Martin pgpAL47xubyVs.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
On Wed, Jul 23, 2008 at 09:36:27AM +0200, Simon Schampijer wrote: > Michael Stone wrote: [...] > >Evidence: Non-extensible aspects of Sugar like activity launching, > >home view layout, frame contents, and the presence service have > >stagnated. [...] > For sugar core - I don't think that 'small fixes' need more than > python skills. I agree. Of course people also need "the knowledge about where to put those python skills to work". That's non-trivial in Sugar, but - apart from m_stone's layering comment - I don't think the UI-code makes this more of a problem than it just is, inherently. > Best, > Simon Martin pgpbxDe2lPOqw.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] pulsing icon code move from sugar to sugar-toolkit?
On Mon, Jul 21, 2008 at 11:49:31AM +0200, Marco Pesenti Gritti wrote: > On Mon, Jul 21, 2008 at 7:37 AM, Martin Dengler > <[EMAIL PROTECTED]> wrote: > > On Mon, Jul 21, 2008 at 12:45:16AM +0200, Marco Pesenti Gritti wrote: [...] > >> What user visible feature does it allow to implement? > > > > #6995 ( http://dev.laptop.org/ticket/6995 ) - move mesh icon to the > > frame, and its concomitant "make AP and mesh icons pulse and > > otherwise consistent with Mesh/Neighborhood view's icons" work. > > Yeah, but what if we implement all of that except the pulsing? This is easily doable. > Is it something we can add incrementally in the next release? Yes. > This is also a question for Eben. Understood. > Marco Martin pgplZpslr43Wa.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] pulsing icon code move from sugar to sugar-toolkit?
On Mon, Jul 21, 2008 at 12:45:16AM +0200, Marco Pesenti Gritti wrote: > On Sun, Jul 20, 2008 at 4:34 AM, Martin Dengler > <[EMAIL PROTECTED]> wrote: > > 1) whether anyone thinks this is too invasive to get in to Sucrose > > 0.82 / OLPC 8.2.0; and > > Yeah, it sounds too invasive to me Just to point out: it is a one line code change in icon.py and then moving (and refactoring, but that can be deferred) code from sugar's pulsingicon.py to sugar-toolkit's pulsingicon.py (using from sugar.graphics.pulsingicon import * to keep sugar's shell.view.pulsingicon exported symbols unchanged). > What user visible feature does it allow to implement? #6995 ( http://dev.laptop.org/ticket/6995 ) - move mesh icon to the frame, and its concomitant "make AP and mesh icons pulse and otherwise consistent with Mesh/Neighborhood view's icons" work. > Marco Martin pgpWw6tXLwHbW.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] pulsing icon code move from sugar to sugar-toolkit?
Hi sugar@, As part of fixing #6995, I'd like to propose we move the contents of sugar/view/pulsingicon.py into sugar-toolkit/graphics/pulsingicon.py. The situation I need to handle is that a sugar-toolkit/graphics/tray.TrayIcon needs to pulse, via its sugar-toolkit/graphics/icon.Icon member[1]. A straw-man (that works, but isn't pretty - look for #FIXME's) implementation so you can see the rough design / example as to how to create a pulsing subclass of sugar-toolkit/graphics/icon.Icon: http://dev.laptop.org/git?p=users/mdengler/sugar-toolkit;a=blob;f=src/sugar/graphics/pulsingicon.py;h=db13556a1921105f9c51aae830b45e9e61202311;hb=c6e7336fea471272b3eb59824fc40eeceeabd41b It's tough to tell the icon is pulsing in these screen shots, but these are some examples of the icon on my XO: http://dev.laptop.org/~mdengler/6995/6995_screenshot_10.png http://dev.laptop.org/~mdengler/6995/6995_screenshot_13.png http://dev.laptop.org/~mdengler/6995/6995_screenshot_14.png Any concerns/comments? I'd specifically be interested in: 1) whether anyone thinks this is too invasive to get in to Sucrose 0.82 / OLPC 8.2.0; and 2) whether anyone thinks pulsingicon.PulsingIcon should just become icon.Icon; and 3) whether anyone has a strong feeling as to whether sugar/view/pulsingicon.py should "import * from sugar.graphics.pulsingicon" or just be removed and all associated imports changed; and 4) not only do 2) *but also* icon.Icon.props.base-color and others should become icon.Icon.pulser.props.base-color (would require changing all the sugar code that uses PulsingIcon); and Thanks any time you can give to this proposal. Martin PS. You can see a mixin (multiple/diamond inheritance) approach (which works) in the commit right before the one above, but I'm even less excited about that one because of the gobject.GObject gotchas evident in even the composition-based approach above. 1. diff --git a/src/sugar/graphics/tray.py b/src/sugar/graphics/tray.py index 8296a53..70c3414 100644 --- a/src/sugar/graphics/tray.py +++ b/src/sugar/graphics/tray.py @@ -22,6 +22,7 @@ from sugar.graphics import style from sugar.graphics.palette import ToolInvoker from sugar.graphics.toolbutton import ToolButton from sugar.graphics.icon import Icon +from sugar.graphics.pulsingicon import PulsingIcon _PREVIOUS_PAGE = 0 _NEXT_PAGE = 1 @@ -328,8 +329,8 @@ class _IconWidget(gtk.EventBox): self.set_app_paintable(True) -self._icon = Icon(icon_name=icon_name, xo_color=xo_color, - icon_size=gtk.ICON_SIZE_LARGE_TOOLBAR) +self._icon = PulsingIcon(icon_name=icon_name, - xo_color=xo_color, + - icon_size=gtk.ICON_SIZE_LARGE_TOOLBAR) self.add(self._icon) self._icon.show() PPS: If you've read this far, you deserve some ASCII art -- this is the current hierarchy: ... | |- gtk.Icon | |- sugar.graphics.Icon (sugar-toolkit/graphics/icon.py) | |- sugar.graphics.PulsingIcon(sugar-toolkit/graphics/pulsingicon.py) ... | |- hippo.CanvasBox hippo.CanvasIcon \ / -|- | |- sugar.graphics.CanvasIcon(sugar-toolkit/graphics/icon.py) | |- sugar.shell.view.CanvasPulsingIcon (sugar/view/pulsingicon.py) ...and I'm proposing either this: ... | |- gtk.Icon | |- sugar.graphics.Icon (sugar-toolkit/graphics/icon.py) | |- sugar.graphics.PulsingIcon(sugar-toolkit/graphics/pulsingicon.py) \--- uses by composition: - sugar.graphics.Pulser(sugar-toolkit/graphics/pulsingicon.py) ... | |- hippo.CanvasBox hippo.CanvasIcon \ / -|- | |- sugar.graphics.CanvasIcon(sugar-toolkit/graphics/icon.py) | |- sugar.graphics.CanvasPulsingIcon(sugar-toolkit/graphics/pulsingicon.py) \--- uses by composition: - sugar.graphics.Pulser(sugar-toolkit/graphics/pulsingicon.py) ...or, more radically, just ... | |- gtk.Icon | |- sugar.graphics.Icon (sugar-toolkit/graphics/icon.py) \--- uses by composition: - sugar.graphics.Pulser (sugar-toolkit/graphics/pulsingicon.py) ... | |- hippo.CanvasBox hippo.CanvasIcon \ / -|- | |- sugar.graphics.CanvasIcon (sugar-toolkit/graphics/icon.py) \--- uses by composition: - sugar.graphics.Pulser (sugar-toolkit/graphics/pulsingicon.py) pgpAO64xOO5uA.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Design Question
On Fri, Jul 18, 2008 at 04:53:31PM -0400, Greg Smith wrote: [...] > The new Home View in 8.2.0 will have three available styles. We need to > pick one to default on first upgrade or install. [...] > > http://wiki.laptop.org/go/Image:Home_Ring_View8.2.png +1 > Thanks, > > Greg S Martin pgpcbfn7aWYUD.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Design Question
On Fri, Jul 18, 2008 at 04:58:02PM -0400, Benjamin M. Schwartz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Greg Smith wrote: > | The new Home View in 8.2.0 will have three available styles. > > Really? The home view top bar will show three buttons, for three > different views? This is news to me, though not bad news. I accidentally discovered the fact that if one clicks on the three-blocks/other-than-the-list icon in the Home/Favorites/old-ring view, one gets to choose which layout one wants. I found that after I manually edited ~/.sugar/default/config to say: [Shell] favoriteslayout = ring-layout ...of course, by Sod's law. Perhaps this is what Greg's referring to. > - --Ben > (bemasc) Martin pgpe93BaPcgmS.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] get_icon_name(): add step kwarg
On Mon, Jun 23, 2008 at 02:08:45PM +0100, Martin Dengler wrote: > On Mon, Jun 23, 2008 at 01:33:38PM +0200, Marco Pesenti Gritti wrote: > > r+, please add a \n after the assert. > > Thanks -- amended patch at the end...I am not a commiter to > sugar-toolkit [...] Sorry, forgot to use the right remote/config entry. Pushed. > > Marco > > Martin Martin pgpZKk3BWTRO9.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] get_icon_name(): add step kwarg
On Mon, Jun 23, 2008 at 01:33:38PM +0200, Marco Pesenti Gritti wrote: > r+, please add a \n after the assert. Thanks -- amended patch at the end...I am not a commiter to sugar-toolkit, in case you thought I could push the patch. If someone wants they can pull from my sugar-toolkit repo at somewhere related to http://dev.laptop.org/git?p=users/mdengler/sugar-toolkit;a=summary . > (thanks for drawing attention on this again, and sorry for the delay) Thank *you*. > Marco Martin From 762ad00777e37324b76941ce07b34dec64d54566 Mon Sep 17 00:00:00 2001 From: Martin Dengler <[EMAIL PROTECTED]> Date: Mon, 23 Jun 2008 12:58:46 +0100 Subject: [PATCH] get_icon_name() now takes step kwarg for #7248.1 --- src/sugar/graphics/icon.py |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/sugar/graphics/icon.py b/src/sugar/graphics/icon.py index d22b412..24b5ca5 100644 --- a/src/sugar/graphics/icon.py +++ b/src/sugar/graphics/icon.py @@ -580,8 +580,8 @@ class CanvasIcon(hippo.CanvasBox, hippo.CanvasItem): palette = property(get_palette, set_palette) -def get_icon_state(base_name, perc): -step = 5 +def get_icon_state(base_name, perc, step=5): +assert step > 0, 'get_icon_state(): step must be positive\n' strength = round(perc / step) * step icon_theme = gtk.icon_theme_get_default() -- 1.5.5.1 pgpRxFLTVKYQG.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] get_icon_name(): add step kwarg
At the risk of being annoying, may I draw attantion to this patch again? It's a dependency of one of the patches to #7248 that I'd like to be able to get in for the upcoming Sugar release... On Thu, Jun 12, 2008 at 01:15:03AM +0100, Martin Dengler wrote: > --- > src/sugar/graphics/icon.py |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/sugar/graphics/icon.py b/src/sugar/graphics/icon.py > index d22b412..65f194b 100644 > --- a/src/sugar/graphics/icon.py > +++ b/src/sugar/graphics/icon.py > @@ -580,8 +580,8 @@ class CanvasIcon(hippo.CanvasBox, hippo.CanvasItem): > > palette = property(get_palette, set_palette) > > -def get_icon_state(base_name, perc): > -step = 5 > +def get_icon_state(base_name, perc, step=5): > +assert step > 0, 'get_icon_state(): step must be positive' > strength = round(perc / step) * step > icon_theme = gtk.icon_theme_get_default() > pgpGX4inuMdQ5.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] feature freeze coming
On Thu, Jun 19, 2008 at 01:33:28PM -0400, Eben Eliason wrote: > Basically, I approve in principle everything on this list, and would > like to see it all get in. I've inserted a couple of minor > comments/requests below. > > On Wed, Jun 18, 2008 at 5:18 PM, Martin Dengler > <[EMAIL PROTECTED]> wrote: > > I've ordered these in decreasing order of likelihood of being accepted > > (IMO) for ease of triaging, and then have provided links to the git > > trees (clearly I will mail the ML as usual, if I haven't but might be > > quicker for triage). > > > > Features: > > > > - #2954 - patch Browse and Read for cursor hiding in handheld mode. > > Mature patch, the approach was verbally ok'ed by eben & bemasc and > > hasn't been shouted down by marco/tomeu recently :) > > > > http://dev.laptop.org/git?p=users/mdengler/sugar-toolkit;a=commitdiff;h=bb8f54e9bfad18699386cf814ca2c592ca0d258f > > This actually applies to all python activities, right? I've been > wanting this for a while. Yes, exactly, and it's less code than doing it just in Browse and Read. > > - #7249 - device ordering in the Frame is not fixed. Not submitted > > before but quite trivial to accept/reject the design. > > > > http://dev.laptop.org/git?p=users/mdengler/sugar;a=commitdiff;h=aec9692c7c3d146e512d1c873de0082b09902d7c > > How would this work in conjunction with the future ability to manually > rearrange the device tray? My simple patch will need to be extended to store the tray position/placement as configurable information rather than hardcoded. But it's so little code that even if we throw it away it's 1) obvious what needs to be changed; and 2) trivial to remove. > Do we need/want the modules to declare their position at all > anyway, or should we instead store a list (as would be needed for > manual positioning anyway) and set the defaults indices (simple > integer index) there? This could be a simpler short term solution > until we have a truly modular (a la control panel) device system. That's better, but as I didn't know how the control panel information was stored and "best practices" / "future goals" I thought at least I'd have proposed a straw man that people could drop on the floor or use in the interim. > > - #6995 - Add a mesh device to frame, remove mesh icons from > > Neighbourhood/Mesh view. This might take some time to stabilize as > > it's non-trivial to really test, but eben seems keen on the > > functionality and want it in. No patch yet (but can get a flavor of > > the UI from the commits mentioned below). > > http://dev.laptop.org/git?p=users/mdengler/sugar;a=shortlog;h=mesh-icon > > > > http://dev.laptop.org/git?p=users/mdengler/sugar;a=commitdiff;h=0580693dbc857c2c09a22cc717c69a02c85ec1fb > > > > http://dev.laptop.org/git?p=users/mdengler/sugar;a=commitdiff;h=abe8cb96ad18ee894d5930bed0a4f7079ea9201b > > I know you've been working toward the mockups, which is all I can > really ask for right now. I think that the "connected to a school > mesh portal" string would work better as the secondary text of the > primary palette, instead of a separate section. I'd prefer > simplifying the language: how about "simple mesh", "school mesh", and > "" (no secondary label) for the three states (the third being that > there is no mesh/turned off)? No problem! > Also, make sure that the mesh devices get removed completely from > Neighborhood view! Yup, that's the easy part, done in this earlier commit: http://dev.laptop.org/git?p=users/mdengler/sugar;a=commitdiff;h=b22fd34cd593b0178daef8b6b30180eaef433595 > > - #2651 - Add an option to the journal for duplicating an entry. Old > > patch but without feedback. > > > > https://dev.laptop.org/attachment/ticket/2651/2651-0001-Add-Duplicate-this-entry-to-the-Copy-icon-s-palett.patch > > I like the idea. Let's simplify the language to just "Duplicate > entry" (or even just "Duplicate"?) instead. Cool! > >> Also, please remind to the list any bug fixes already with code > >> waiting to get in after the feature freeze. > > Clearly all the bug fixes should make it in! :) > - Eben Martin pgpslcIlmQJLZ.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] feature freeze coming
On Wed, Jun 18, 2008 at 03:28:19PM +0200, Tomeu Vizoso wrote: > Hi, > > is there any patch I have forgotten and that should get in before > tomorrow feature freeze? I have a number of patches to propose, most of which have already been proposed and none of which have been sent back for review before (obviously that doesn't mean they're perfect but just means I'm not spamming known-bad-design patches). I've ordered these in decreasing order of likelihood of being accepted (IMO) for ease of triaging, and then have provided links to the git trees (clearly I will mail the ML as usual, if I haven't but might be quicker for triage). Features: - #2954 - patch Browse and Read for cursor hiding in handheld mode. Mature patch, the approach was verbally ok'ed by eben & bemasc and hasn't been shouted down by marco/tomeu recently :) http://dev.laptop.org/git?p=users/mdengler/sugar-toolkit;a=commitdiff;h=bb8f54e9bfad18699386cf814ca2c592ca0d258f - #7249 - device ordering in the Frame is not fixed. Not submitted before but quite trivial to accept/reject the design. http://dev.laptop.org/git?p=users/mdengler/sugar;a=commitdiff;h=aec9692c7c3d146e512d1c873de0082b09902d7c - #6995 - Add a mesh device to frame, remove mesh icons from Neighbourhood/Mesh view. This might take some time to stabilize as it's non-trivial to really test, but eben seems keen on the functionality and want it in. No patch yet (but can get a flavor of the UI from the commits mentioned below). http://dev.laptop.org/git?p=users/mdengler/sugar;a=shortlog;h=mesh-icon http://dev.laptop.org/git?p=users/mdengler/sugar;a=commitdiff;h=0580693dbc857c2c09a22cc717c69a02c85ec1fb http://dev.laptop.org/git?p=users/mdengler/sugar;a=commitdiff;h=abe8cb96ad18ee894d5930bed0a4f7079ea9201b - #2651 - Add an option to the journal for duplicating an entry. Old patch but without feedback. https://dev.laptop.org/attachment/ticket/2651/2651-0001-Add-Duplicate-this-entry-to-the-Copy-icon-s-palett.patch > Also, please remind to the list any bug fixes already with code > waiting to get in after the feature freeze. Bugfixes: - #7248.1 - speaker icon doesn't show 33 and 66% levels. patches (sugar & sugar-toolkit) submitted, very trivial http://lists.laptop.org/pipermail/sugar/2008-June/006472.html http://lists.laptop.org/pipermail/sugar/2008-June/006473.html - #7248.2 - speaker icon flips to unmuted from muted most of the time the palette is shown; not submitted, still being debugged, should be very localized and low-risk. - #7248.3 - speaker icon should unmute when volume set to > 0: trivial, patch not submitted but in my d.l.o sugar git tree http://dev.laptop.org/git?p=users/mdengler/sugar;a=commitdiff;h=5f54d8e6375508a88752a7a041caf56a10c9c55b > Thanks, > > Tomeu Martin pgp0uzkl36Yxz.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Communicate the changing of some sugar keyboard shortcuts?
Hi and apologies for the wide distribution of this email... Some Sugar keyboard shortcuts are changing due to trac ticket #4646[1]. They're not in joyride yet but will get there soon (I imagine). You can view the changes and the discussion leading up to them in the [EMAIL PROTECTED] email trail for more background. Two questions: 1. What documentation needs to change? For example, there are keyboard shortcut mentions on lots of wiki pages[3,4], and even a talk page[5] complaining docmentation is out-of-date, but I'm loath to change them before the changes even hit joyride. 2. Any feedback on the changes themselves is welcome (ok, that's not phrased as a question, but...). In case it spurs anyone to answer my question #1, my OTTOMH plan is to edit [3] when these changes go into joyride and create a table per widely-deployed build (for values of "widely-deployed build" that I can link to a sugar-git tag or guess from deployed distro packages) and a "latest" section. Thanks, Martin 1. http://dev.laptop.org/ticket/4646 2. http://www.mail-archive.com/sugar@lists.laptop.org/msg03739.html 3. http://wiki.laptop.org/go/Keyboard_Shortcuts 4. http://wiki.laptop.org/go/Support_FAQ#How_do_I_close_an_Activity_.28program.29.3F 5. http://wiki.laptop.org/go/Talk:Keyboard_Shortcuts pgpZiu70h89pf.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Build streams
On Thu, Jun 12, 2008 at 11:36:51PM -0400, Mikus Grinbergs wrote:
> Finally, finally, Joyride 2024 managed to 'make available to users'
> some of the newer Sugar changes (packaged in a build, as opposed to
> only available in source).
So you want to see new sugar (sucrose?) code on your XO but only if
it's been pushed to an OLPC build? I'd say you need to complain to
SugarLabs/sugar@ to make it easier to get new code to deployed systems
without requiring the downstream packagers (e.g., OLPC, ubuntu, etc.)
to do a whole new distribution.
> I'm interested in how the new Sugar behaves on my XO . . .
If you relax your restriction to using OLPC builds it's pretty easy /
durable (in the short term, in the usual case, YMMV but I've been
doing it) to just symlink a few dirs to a git clone (e.g., mv
/usr/share/sugar/shell /usr/share/sugar/shell.orig && ln -s
/home/olpc/sugar-clone/src /usr/share/sugar/shell && cp
/usr/share/sugar/shell{.orig,}/config.py) to really try to catch the
bleeding edge. But it really is the bleeding edge, and if you are
worried about that not getting into builds enough you should complain
to sugar@, as I mentioned above, I think.
> mikus
Martin
pgpnUpbYdX8v2.pgp
Description: PGP signature
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Home Design: Free Layout View
On Fri, Jun 13, 2008 at 12:52:15AM -0400, Mikus Grinbergs wrote: [...] > What could be done on the Home-view page (once the existing "ring" > gets too crowded) is to *not* show some icons until an "enabling > object" is clicked. By "expanding" only one "enabling object" at a > time, the available space on the Home-view page gets multi-used -- > providing lots of scalability. Since a "ring display of objects" > looks good, clicking on an "enabling object" put into an inner ring > could bring up an adjacent "outer ring segment" showing more icons. This made me think of a hyperbolic tree[1,2] layout with the root node obviously being the XO, the central ring being the activities and each activity allowing navigation to its instances in the journal. > mikus Martin 1. http://en.wikipedia.org/wiki/HyperbolicTree 2. http://www.visual-literacy.org/periodic_table/periodic_table.html pgpNH74MnL4mB.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Home Design: Free Layout View
On Thu, Jun 12, 2008 at 03:08:29PM -0400, Eben Eliason wrote: > [new home view] Eben, I have great respect for you and the people involved. My gut reaction to the new design, however, was just: it's not beautiful. I'd like to repeat clearly: This design is not beautiful. The ring[1] was beautiful, and the redesigned activity circle/ring[2] too, but this design is not beautiful. It lacks a sense of "macro" / unifying design/layout that the previous two had, and it looks like a mess :(. > [the Home view presentation was not a Good Thing; the] main issue of > concern was one of scalability . . . What what?? Creation is (journal-wise) nouns; the ring / activities view is (was) verbs. I've not idea about design metaphor and the application thereof, but this seems a large change (not necessarily bad) for a silly reason: scalability. Silly I say, because: this design is no useful way more scalable. A ring of 50 icons is a better organization than a free-form desktop of 50 icons. Sure, they can be dragged around to make sense of them, but...inherently more scalable (or more beautiful than your last designs) it is not. > After experimenting with a number of layouts, it became clear that a > more traditional freeform view maximizes potential use of the > available space . . . Why is space maximization the most important goal? Clearly a free-form view is *not* going to result in the maximal packing, but a somewhat-overlapping grid/hexagonal view. I find this whole scalability argument not compelling. > . . . retains the XO at the center (which is core to > the zoom metaphor and reflects the philosophy of child ownership of > laptops) . . . Sure! > . . . and also provides, via drag'n'drop, the ability for kids to > further personalize their Home by arranging and categorizing > activities as they see fit. Personalization is good. > While we contend that the notion of > favorites is still a powerful organizational tool, and therefore > propose to keep it in the new designs, this free view scales well > enough to prevent the need for using them if one doesn't wish to. > > Please observe the new design mockups on the wiki at > http://wiki.laptop.org/go/Designs/Activity_Management for further > details. As code freeze is rapidly approaching and these changes are > slated for the August release aside the rest of the redesign, your > feedback is greatly appreciated. Thanks! Feedback/summary of the above: keep the last design with its favorite activity ring, but perhaps stick the shaded ring of the design prior to *that* behind the favorite-ed activities, perhaps. But there are probably a lot of designs more beautiful that this new proposal, so don't use this new proposal (subject to the "PS" section caveats below). > - Eben Martin > PS. While considering the implementation details of the new Home > design, an interesting extension of this idea was proposed: a > modular layout system. It would take as input the coordinates of the > dropped icon (and those of all others on screen as well), and output > coordinates for where the icons should actually be drawn. (We could > also include metadata such as name, tags, etc. to allow sorting, > grouping and such.) > The simplest layout is the identity function, naturally. A slightly > more interesting layout would be the identity function, with some > extra jiggle logic to prevent overlapping icons. Another possibility, > of course, is to compute the angle between the center of the screen > and the coordinate of the dropped icon, compute a radius r based on > the total number of icons, and then draw all of the dropped icons in a > ring of radius r with the newly dropped one at the appropriate > position in the ring. Wait, I've changed my mind - *this* is the way to go. Forget all that stuff I said above ;). > One can imagine many more, and more importantly, the possibility > for an extensible system which allows kids to create their own > custom layouts. This would be *super* cool. It's quite high up the gradient of customizability, but could be a useful amount/degree below the difficulty of having kids implement their own gtk theme. pgpurz4lPA0JF.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame activation
On Wed, Jun 11, 2008 at 04:16:24AM +0100, Gary C Martin wrote: > On 10 Jun 2008, at 11:15, Tomeu Vizoso wrote: > > > do we have any feedback regarding frame activation and the new control > > panel option? [...] > I found warm edges too obtrusive even with a max delay, specifically > scroll bar interaction was the main false activation. I found this as well. > --Gary Martin pgp6kiMiytPEY.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] get_icon_name(): add step kwarg
On Thu, Jun 12, 2008 at 01:15:03AM +0100, Martin Dengler wrote: > [1-line patch to sugar/graphics/icon.py] A more performant approach to get_icon_name(), which I think is called a fair bit, would be to cache the list of available files to avoid exercising the file systme a billion times as the wireles signal changes (ooh, imagine the stat()s when showing the mesh view and there are loads of APs around changing signal strength all the time). A related idea is to change this function to really do what it seems to be meaning to do which is quantize the input range 0-100 into the output range (defined by the number of different icon files). However consider that this would affect icon file names if the current user experience is to be preserved. As the number of files deceases the ratio of files to step size grows and starts to dominate the time cost of calculating the output range. And of course my previous suggestion could reduce this cost to constant time. Martin pgpjll6FKLtdT.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] 7248.1: speaker-icon chosen correctly
speaker icon now chosen correctly; requires patch to sugar-toolkit
---
src/view/devices/speaker.py |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/view/devices/speaker.py b/src/view/devices/speaker.py
index 5db16b5..a7efb26 100644
--- a/src/view/devices/speaker.py
+++ b/src/view/devices/speaker.py
@@ -57,7 +57,7 @@ class DeviceView(TrayIcon):
xo_color = XoColor('%s,%s' % (style.COLOR_WHITE.get_svg(),
style.COLOR_WHITE.get_svg()))
-self.icon.props.icon_name = get_icon_state(name, current_level)
+self.icon.props.icon_name = get_icon_state(name, current_level, step=1)
self.icon.props.xo_color = xo_color
def __speaker_status_changed_cb(self, pspec, param):
--
1.5.3.3
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] get_icon_name(): add step kwarg
--- src/sugar/graphics/icon.py |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/sugar/graphics/icon.py b/src/sugar/graphics/icon.py index d22b412..65f194b 100644 --- a/src/sugar/graphics/icon.py +++ b/src/sugar/graphics/icon.py @@ -580,8 +580,8 @@ class CanvasIcon(hippo.CanvasBox, hippo.CanvasItem): palette = property(get_palette, set_palette) -def get_icon_state(base_name, perc): -step = 5 +def get_icon_state(base_name, perc, step=5): +assert step > 0, 'get_icon_state(): step must be positive' strength = round(perc / step) * step icon_theme = gtk.icon_theme_get_default() -- 1.5.3.3 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH 2/2] return 0, not None, if we can't get the mixer volume
Thanks -- pushed both patches.
On Tue, Jun 10, 2008 at 09:25:43AM +0200, Tomeu Vizoso wrote:
> r+ Thanks!
>
> On Wed, Jun 4, 2008 at 5:25 AM, Martin Dengler <[EMAIL PROTECTED]> wrote:
> > ---
> > src/hardware/hardwaremanager.py |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/src/hardware/hardwaremanager.py
> > b/src/hardware/hardwaremanager.py
> > index 29f5fba..2f92537 100644
> > --- a/src/hardware/hardwaremanager.py
> > +++ b/src/hardware/hardwaremanager.py
> > @@ -60,7 +60,7 @@ class HardwareManager(object):
> > def get_volume(self):
> > if not self._mixer or not self._master:
> > logging.error('Cannot get the volume')
> > -return None
> > +return 0
> >
> > max_volume = self._master.max_volume
> > min_volume = self._master.min_volume
> > --
> > 1.5.5.1
pgpg0e9FiqaLa.pgp
Description: PGP signature
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] fix #4646 - replace/normalize some keyboard shortcuts
Eben transferred this ticket to Sugar saying he's OK with these
changes. Can someone review please?
I can email support@ or sugar@ or other mailing lists (suggestions
welcome) about corrdinating the wiki / other documentation changes
once that's done.
Martin
On Tue, Apr 29, 2008 at 09:45:06PM +0100, Martin Dengler wrote:
> ---
> src/view/keyhandler.py | 25 -
> 1 files changed, 12 insertions(+), 13 deletions(-)
>
> diff --git a/src/view/keyhandler.py b/src/view/keyhandler.py
> index 306bb21..219cc5e 100644
> --- a/src/view/keyhandler.py
> +++ b/src/view/keyhandler.py
> @@ -40,26 +40,25 @@ _actions_table = {
> 'F4' : 'zoom_activity',
> 'F9' : 'brightness_down',
> 'F10': 'brightness_up',
> -'F9' : 'brightness_min',
> -'F10' : 'brightness_max',
> +'F9': 'brightness_min',
> +'F10' : 'brightness_max',
> 'F11': 'volume_down',
> 'F12': 'volume_up',
> -'F11' : 'volume_min',
> -'F12' : 'volume_max',
> +'F11' : 'volume_min',
> +'F12' : 'volume_max',
> '1' : 'screenshot',
> -'f' : 'frame',
> '0x93' : 'frame',
> '0xEB' : 'rotate',
> -'r' : 'rotate',
> -'q' : 'quit_emulator',
> 'Tab' : 'next_window',
> -'n' : 'next_window',
> -'Tab' : 'previous_window',
> -'p' : 'previous_window',
> -'Escape' : 'close_window',
> -'q': 'close_window',
> +'Tab': 'previous_window',
> +'Escape': 'close_window',
> '0xDC' : 'open_search',
> -'s' : 'say_text'
> +# the following are intended for emulator users
> +'f' : 'frame',
> +'q' : 'quit_emulator',
> +'o' : 'open_search',
> +'r' : 'rotate',
> +'s' : 'say_text',
> }
>
> J_DBUS_SERVICE = 'org.laptop.Journal'
pgpWVGbDDPDLf.pgp
Description: PGP signature
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Moving to metacity with composition (was: Preparing for the feature freeze)
On Wed, Jun 04, 2008 at 09:28:40PM +0530, Sayamindu Dasgupta wrote: > I tried your ps_mem.py based tests [...] Cool -- looks like just moving to os16 + metacity saved at least 14 MiB[1] (not counting any python savings) and Xorg grew by 15 MiB. > Cheers, > Sayamindu Martin 1. 2 + 6 + 6 MiB: matchbox - metacity, Terminal, and Journal MiB savings. These are obviously not numbers to rely on, but they're probably a decent in-kind test (as I saw net memory usage grow, and so did you, but the growths are on the same order of magnitude. As it looks like many other things might have got a lot better, this still seems pretty promising to me. pgpjl0gJua3Jr.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] adding a bad device to the frame shouldn't crash sugar
On Wed, Jun 04, 2008 at 11:44:09AM +0200, Tomeu Vizoso wrote:
> Looks good to me. Small comments inline:
>
> > +import logging
> > +logger = logging.getLogger('DevicesTray')
>
> What about moving the import along with the others and declaring the
> logger at the module level as in activitiesring.py?
Sure. I saw that code after I thought of the patch, but figured
someone might want the patch changes to be all in one place in the
file (just so you know why I did it that way). Changed as you
suggested.
> > +logger.warn("Not able to add icon for device [%s], because of "
> > +"an error (%s). Continuing." % (device, message))
>
> May be better to print the __repr__ of the device, with %r instead of
> %s. In some classes, __str__ won't be as good a description of the
> instance as __repr__.
Sure.
> Thanks,
>
> Tomeu
Martin
pgpLiPoXKaVrb.pgp
Description: PGP signature
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH 2/2] return 0, not None, if we can't get the mixer volume
---
src/hardware/hardwaremanager.py |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/hardware/hardwaremanager.py b/src/hardware/hardwaremanager.py
index 29f5fba..2f92537 100644
--- a/src/hardware/hardwaremanager.py
+++ b/src/hardware/hardwaremanager.py
@@ -60,7 +60,7 @@ class HardwareManager(object):
def get_volume(self):
if not self._mixer or not self._master:
logging.error('Cannot get the volume')
-return None
+return 0
max_volume = self._master.max_volume
min_volume = self._master.min_volume
--
1.5.5.1
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH 1/2] set_mute --> set_muted, consistent with get_muted()
---
src/hardware/hardwaremanager.py |5 +++--
src/model/devices/speaker.py|2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/hardware/hardwaremanager.py b/src/hardware/hardwaremanager.py
index 87d79c1..29f5fba 100644
--- a/src/hardware/hardwaremanager.py
+++ b/src/hardware/hardwaremanager.py
@@ -103,10 +103,11 @@ class HardwareManager(object):
last_volumes_read = self._mixer.get_volume(self._master)
read_count += 1
-def set_mute(self, mute):
+def set_muted(self, mute):
if not self._mixer or not self._master:
logging.error('Cannot mute the audio channel')
-self._mixer.set_mute(self._master, mute)
+else:
+self._mixer.set_mute(self._master, mute)
def startup(self):
if env.is_emulator() is False:
diff --git a/src/model/devices/speaker.py b/src/model/devices/speaker.py
index 8526ea3..683849d 100644
--- a/src/model/devices/speaker.py
+++ b/src/model/devices/speaker.py
@@ -40,7 +40,7 @@ class Device(device.Device):
return self._manager.get_muted()
def _set_muted(self, mute):
-self._manager.set_mute(mute)
+self._manager.set_muted(mute)
self.notify('muted')
def get_type(self):
--
1.5.5.1
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH 0/2] speaker icon tidyup
Just some tiny speaker icon tidyups Martin Dengler (2): set_mute --> set_muted, consistent with get_muted() return 0, not None, if we can't get the mixer volume src/hardware/hardwaremanager.py |7 --- src/model/devices/speaker.py|2 +- 2 files changed, 5 insertions(+), 4 deletions(-) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] adding a bad device to the frame shouldn't crash sugar
---
src/view/frame/devicestray.py | 16 +++-
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/src/view/frame/devicestray.py b/src/view/frame/devicestray.py
index 1accdad..1b7f3d1 100644
--- a/src/view/frame/devicestray.py
+++ b/src/view/frame/devicestray.py
@@ -35,11 +35,17 @@ class DevicesTray(HTray):
self.__device_disappeared_cb)
def _add_device(self, device):
-view = deviceview.create(device)
-# TODO: *Tray classes don't allow yet to set the alignment.
-self.add_item(view)
-view.show()
-self._device_icons[device.get_id()] = view
+try:
+view = deviceview.create(device)
+# TODO: *Tray classes don't allow yet to set the alignment.
+self.add_item(view)
+view.show()
+self._device_icons[device.get_id()] = view
+except Exception, message:
+import logging
+logger = logging.getLogger('DevicesTray')
+logger.warn("Not able to add icon for device [%s], because of "
+"an error (%s). Continuing." % (device, message))
def _remove_device(self, device):
self.remove_item(self._device_icons[device.get_id()])
--
1.5.5.1
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Gadget's feature integration in Sugar
On Tue, Jun 03, 2008 at 12:06:44PM +0200, Marco Pesenti Gritti wrote: > On Mon, Jun 2, 2008 at 1:41 PM, Guillaume Desmottes > <[EMAIL PROTECTED]> wrote: > > Hi, > > > > Daf and I are making good progress on Gadget, so that's a good time to > > start to think about its integration in Sugar. > > > > Basically, Gadget is a XMPP server component that should solve our > > current scalability issues and drop the ugly "shared roster" hack. > > I invite you to take a look on the "Use Cases" and "Design Goals" > > sections of http://wiki.laptop.org/go/XMPP_Component_Protocol to have a > > better idea of what Gadget is and which problem it tries to solve. > > [...] > > - As we intent to drop the shared buddy server hack, people won't see > > all the buddies connected on the server anymore. > > They'll see their friends, the result of the active searches and a > > maximum of $N random buddies and $N' random activities. > > > > Should we hardcode the value of this $N? Make it configurable from the > > GUI? From sugar-control-panel (and so stored in a config file)? > > Adapt it according the number of buddies already displayed on the mesh > > view? > > I think it can be calculated depending on the screen and icon sizes. It might be useful to expose this calculated value somewhere (control panel?), because it sounds kind of flaky (nonobvious, nondiscoverable, limiting, non-deterministic) to me to have this limit. If we intend this limit to actually be hit often, perhaps it would make sense to expose it to the user in the mesh view (an icon + textbox right-justified in the toolbox? I'm thinking firefox's search bar, though this should not be used that much...perhaps it should only appear if the activity/buddy search results are limited?)? > Marco Martin pgpqhmZI05bmN.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Moving to metacity with composition (was: Preparing for the feature freeze)
As an aside... On Tue, Jun 03, 2008 at 12:16:27PM +0200, Tomeu Vizoso wrote: > Sayamindu, you say you got OOM problems after activating composition, > can you check where that memory is going? Or might be the X server > crashing instead? Even on my C2 "yum search yummemoryimprovesinf9" causes significant memory pressure[1]. Sugar/Glucose/Sweetness becomes unresponsive, though oom-killer doesn't get involved. I'm surprised that it's even feasible to run yum on a B4 with sugar running. I've been using compcache[2,3] to help with this pressure. > Cheers, > > Tomeu Martin 1. As in, "free" in vmstat goes down to 0, from 40. Yeah, this is imprecise. "cache" is still fine at 80. joyride-1998. That's not downloading any updates, no activities running. 2. http://dev.laptop.org/ticket/28 3. http://www.xades.com/ , "compcache on the XO" pgpaO0VEf9ikT.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Capturing all mouse events
On Sun, Jun 01, 2008 at 09:05:48PM -0400, Benjamin M. Schwartz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Martin Dengler wrote: > | On Fri, May 30, 2008 at 09:38:39PM -0400, Benjamin M. Schwartz wrote: > |> > |> Does anyone know how to capture all mouse events? > | > | In trying to do this with pygtk, we both have run into gtk bug > | #156948[1] - for the record/to close the loop, we tried calling > | add_filter() on gtk.gdk.get_default_root_window()'s returned > | gtk.gdk.Window. This should, in theory, give us all events[2]. But the > | bug prevents the information from being useful, and it's not clear > | that we're really getting all events[3]. > > I've been trying to use the RECORD extension, which provides access to ALL > input events in a simple way. Unfortunately, I can't seem to load the > RECORD extension. I have added the line > > Load "record" > > to my xorg.conf, and my Xorg.0.log now shows a line > > (II) Loading extension RECORD > > but xdpyinfo doesn't show RECORD in its list of loaded extensions. Me too...it was already in xorg.conf, so we must be doing something wrong... -bash-3.2# grep -i record /etc/X11/xorg.conf Load "record" # Mostly a debugging tool -bash-3.2# grep -i record /var/log/Xorg.0.log (II) "record" will be loaded. This was enabled by default and also specified in the config file. (II) LoadModule: "record" (II) Loading /usr/lib/xorg/modules/extensions//librecord.so (II) Module record: vendor="X.Org Foundation" (II) Loading extension RECORD -bash-3.2# xdpyinfo | grep -i record -bash-3.2# > - --Ben Martin pgpysrZI7jfKK.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Capturing all mouse events
On Fri, May 30, 2008 at 09:38:39PM -0400, Benjamin M. Schwartz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Does anyone know how to capture all mouse events?
In trying to do this with pygtk, we both have run into gtk bug
#156948[1] - for the record/to close the loop, we tried calling
add_filter() on gtk.gdk.get_default_root_window()'s returned
gtk.gdk.Window. This should, in theory, give us all events[2]. But the
bug prevents the information from being useful, and it's not clear
that we're really getting all events[3].
> [...] listen to /dev/input/mouse0.
That seems promising. I couldn't find anything useful in pygame.
> - --Ben
Martin
1. http://bugzilla.gnome.org/show_bug.cgi?id=156948
2. this is what metacity uses:
--- metacity-2.23.0/src/ui/ui.c:76
static GdkFilterReturn
filter_func (GdkXEvent *xevent,
GdkEvent *event,
gpointer data)
{
g_return_val_if_fail (ef != NULL, GDK_FILTER_CONTINUE);
if ((* ef->func) (xevent, ef->data))
return GDK_FILTER_REMOVE;
else
return GDK_FILTER_CONTINUE;
}
void
meta_ui_add_event_func (Display *xdisplay,
MetaEventFunc func,
gpointer data)
{
g_return_if_fail (ef == NULL);
ef = g_new (EventFunc, 1);
ef->func = func;
ef->data = data;
gdk_window_add_filter (NULL, filter_func, ef);
}
---
3.
http://markmail.org/message/ns2jcbhzr7br55ur?q=gdk+add_filter&page=1&refer=cj5iiu56mz7shm3s
pgppIKAHQ1yxz.pgp
Description: PGP signature
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Cursor modifications
On Thu, May 29, 2008 at 04:53:03PM -0400, Benjamin M. Schwartz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > In conversation with Eben, the prospect of more informative cursors came > up. We would like to have cursors that, for example, flash white when the > user clicks, and change shape depending on whether the input device is the > pen tablet or glide sensor. Cool idea. > I do not know anywhere near enough about X to make this happen. I hope > you will respond with advice about what to do, or perhaps volunteer if you > understand this area. It certainly doesn't sound like a hard problem. Each gtk.gdk.Window (subclass) can have its own cursor[1]. Can/should X be doing this? Or were you thinking of Sugar - just the shell in Glucose[2] - behaving like this, and encouraging all the Fructose to implement the same behavior (...s that are applicable)? > - --Ben Martin 1. http://www.pygtk.org/docs/pygtk/class-gdkcursor.html 2. http://wiki.sugarlabs.org/go/Taxonomy - first hit for "sugar taxonomy" on google -- excellent. pgpvBA1FKfwrM.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] Fix #6994 - Add speaker device and icon by default
Fix #6994 - Add speaker device and icon by default, as in
http://wiki.laptop.org/go/Designs/Frame#07
---
src/hardware/hardwaremanager.py | 31 +-
src/model/devices/Makefile.am |4 +-
src/model/devices/devicesmodel.py |8 +++
src/model/devices/speaker.py | 59 ++
src/view/devices/Makefile.am |4 +-
src/view/devices/speaker.py | 121 +
6 files changed, 222 insertions(+), 5 deletions(-)
create mode 100644 src/model/devices/speaker.py
create mode 100644 src/view/devices/speaker.py
diff --git a/src/hardware/hardwaremanager.py b/src/hardware/hardwaremanager.py
index 5b9e330..87d79c1 100644
--- a/src/hardware/hardwaremanager.py
+++ b/src/hardware/hardwaremanager.py
@@ -50,6 +50,13 @@ class HardwareManager(object):
if track.flags & gst.interfaces.MIXER_TRACK_MASTER:
self._master = track
+def get_muted(self):
+if not self._mixer or not self._master:
+logging.error('Cannot get the mute status')
+return True
+return self._master.flags & gst.interfaces.MIXER_TRACK_MUTE \
+ == gst.interfaces.MIXER_TRACK_MUTE
+
def get_volume(self):
if not self._mixer or not self._master:
logging.error('Cannot get the volume')
@@ -57,9 +64,19 @@ class HardwareManager(object):
max_volume = self._master.max_volume
min_volume = self._master.min_volume
-volume = self._mixer.get_volume(self._master)[0]
-return volume * 100.0 / (max_volume - min_volume) + min_volume
+volumes = self._mixer.get_volume(self._master)
+
+#sometimes we get a spurious zero from one/more channel(s)
+#TODO: consider removing this when trac #6933 is resolved
+nonzero_volumes = [v for v in volumes if v > 0]
+
+if len(nonzero_volumes) > 0:
+#we could just pick the first nonzero volume, but this converges
+volume = sum(nonzero_volumes) / len(nonzero_volumes)
+return volume * 100.0 / (max_volume - min_volume) + min_volume
+else:
+return 0
def set_volume(self, volume):
if not self._mixer or not self._master:
@@ -76,7 +93,15 @@ class HardwareManager(object):
volume = volume * (max_volume - min_volume) / 100.0 + min_volume
volume_list = [ volume ] * self._master.num_channels
-self._mixer.set_volume(self._master, tuple(volume_list))
+#sometimes alsa sets one/more channels' volume to zero instead
+# of what we asked for, so try a few times
+#TODO: consider removing this loop when trac #6934 is resolved
+last_volumes_read = [0]
+read_count = 0
+while (0 in last_volumes_read) and (read_count < 3):
+self._mixer.set_volume(self._master, tuple(volume_list))
+last_volumes_read = self._mixer.get_volume(self._master)
+read_count += 1
def set_mute(self, mute):
if not self._mixer or not self._master:
diff --git a/src/model/devices/Makefile.am b/src/model/devices/Makefile.am
index 5440eeb..274f1e7 100644
--- a/src/model/devices/Makefile.am
+++ b/src/model/devices/Makefile.am
@@ -3,6 +3,8 @@ SUBDIRS = network
sugardir = $(pkgdatadir)/shell/model/devices
sugar_PYTHON = \
__init__.py \
+ battery.py \
device.py \
devicesmodel.py \
- battery.py
+ speaker.py
+
diff --git a/src/model/devices/devicesmodel.py
b/src/model/devices/devicesmodel.py
index 691e19e..6b405ed 100644
--- a/src/model/devices/devicesmodel.py
+++ b/src/model/devices/devicesmodel.py
@@ -23,6 +23,7 @@ from model.devices import device
from model.devices.network import wireless
from model.devices.network import mesh
from model.devices import battery
+from model.devices import speaker
from hardware import hardwaremanager
from hardware import nmclient
@@ -45,6 +46,13 @@ class DevicesModel(gobject.GObject):
self._observe_hal_manager()
self._observe_network_manager()
+try:
+self.add_device(speaker.Device())
+except Exception, speaker_fail_msg:
+logging.error("could not initialize speaker device: %s" %
+ speaker_fail_msg)
+logging.debug(traceback.format_exc())
+
def _observe_hal_manager(self):
bus = dbus.Bus(dbus.Bus.TYPE_SYSTEM)
proxy = bus.get_object('org.freedesktop.Hal',
diff --git a/src/model/devices/speaker.py b/src/model/devices/speaker.py
new file mode 100644
index 000..8526ea3
--- /dev/null
+++ b/src/model/devices/speaker.py
@@ -0,0 +1,59 @@
+# Copyright (C) 2008 Martin Dengler
+#
+# 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
Re: [sugar] [PATCH] Add speaker device and icon by default
On Wed, May 14, 2008 at 12:14:57PM +0200, Tomeu Vizoso wrote:
> Hi, sorry for the delay.
Same here - was on holiday.
>
> On Tue, May 13, 2008 at 12:43 AM, Martin Dengler
> <[EMAIL PROTECTED]> wrote:
> > +def get_mute(self):
>
> You use 'muted' instead of 'mute' below, which one is more correct?
I prefer 'muted', because 'muted' sounds more like a predicate/boolean
to me and 'mute' sounds more like a verb. (consider 'get_stopped()'
vs. 'get_stop'). Changed get_mute() to get_muted().
> > +if not self._mixer or not self._master:
> > +logging.error('Cannot get the mute status')
> > +return False
>
> Shouldn't we return True if there's no way to get the volume?
I thought we should assume we're not muted if we don't know what the
volume is, but I think I see your point. I don't think the return
value is sensible in this scenario, though, so perhaps we should
raise()? I don't have strong feelings, so I've changed to return
True.
> > diff --git a/src/model/devices/Makefile.am b/src/model/devices/Makefile.am
> > index 5440eeb..3124144 100644
> > --- a/src/model/devices/Makefile.am
> > +++ b/src/model/devices/Makefile.am
> > @@ -5,4 +5,6 @@ sugar_PYTHON = \
> > __init__.py \
> > device.py \
> > devicesmodel.py \
> > - battery.py
> > + battery.py \
> > + speaker.py
>
> Just as a comment, the convention is to sort files alphabetically (it
> was already wrong).
Gotcha - I didn't want to reorder but as I'm changing the battery.py
line anyway I'll reorder it.
> > @@ -54,6 +55,13 @@ class DevicesModel(gobject.GObject):
> >
> > for udi in hal_manager.FindDeviceByCapability('battery'):
> > self.add_device(battery.Device(udi))
> >
> > +try:
> >
> > +self.add_device(speaker.Device())
> > +except Exception, speaker_fail_msg:
> > +logging.error("could not initialize speaker device: %s" %
> > + speaker_fail_msg)
> > +logging.debug(traceback.format_exc())
>
> I would add the speaker device in the constructor, instead of in
> _observe_hal_manager().
It should be in the constructor, I agree. I'm sure I put it there
but...must've slipped a method somehow. Scary. Moved.
> Perhaps we should add try..except blocks to all the add_device calls?
> Not in this patch, though.
Yes, possibly. It's the Device-subclass __init__ and the .py file
import itself that we have to worry about, though, I think (consider
that the logical extension of what you've said would be to just put a
try...except in add_device()). Something to think about in a later
patch, I agree.
> > +def get_type(self):
> > +return 'speaker'
>
> Maybe should be a constant at the module level?
Every Device-subclass implements this method in a similar form. I'm
not a huge fan of this function - __name__ should be enough.
AFAICS, it's just a way of helping deviceview.py with the fact that
model & view implementations are split at a high level
(src/{model,view}/...):
http://dev.laptop.org/git?p=sugar;a=blob;f=src/view/devices/deviceview.py;h=90ebbf55413925f537a9e9e900d3828bb4f28bac;hb=HEAD
.
Assuming you prefer the consistency I'll leave this as-is, but I'm not
at all bothered about changing it.
> > +def do_get_property(self, pspec):
> > +if pspec.name == "level":
> > +return self._get_level()
> > +elif pspec.name == "muted":
> > +return self._get_muted()
>
> See above comment about muted vs mute.
ibid/fixed.
> > +self._adjustment = gtk.Adjustment(
> > +self._model.props.level, 0.0, 101.0, 1, 1, 1)
>
> Not the most common of breaking an arg list, but I don't particularly care.
I don't know much gtk so the Adjustment positional args mean little to
me - I have to look them up each time I care - so far about twice :).
I've looked them up a third time and tried a bit more sensical split.
> Thanks!
Thank you!
> Tomeu
Martin
pgpeYmngRZ2Hb.pgp
Description: PGP signature
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Browse v86 rainbow issue on update 1-706?
On Thu, May 29, 2008 at 03:42:55AM +0100, Gary C Martin wrote: > On 28 May 2008, at 18:55, Martin Dengler wrote: > >Is this rainbow racing with X, or is that in joyride only? > > Sorry, not sure. I'm back on joyride now and Browse seems quite happy > there. I was away from the web earlier and couldn't look up the trac for what I was referring to: http://dev.laptop.org/ticket/6797 (in case it happens again). > --Gary Martin pgp8sCwZdg7ke.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] Add speaker device and icon by default
Add speaker device and icon by default, as in
http://wiki.laptop.org/go/Designs/Frame#07
---
src/hardware/hardwaremanager.py | 31 +-
src/model/devices/Makefile.am |4 +-
src/model/devices/devicesmodel.py |8 +++
src/model/devices/speaker.py | 59 ++
src/view/devices/Makefile.am |4 +-
src/view/devices/speaker.py | 119 +
6 files changed, 220 insertions(+), 5 deletions(-)
create mode 100644 src/model/devices/speaker.py
create mode 100644 src/view/devices/speaker.py
diff --git a/src/hardware/hardwaremanager.py b/src/hardware/hardwaremanager.py
index 5b9e330..284a283 100644
--- a/src/hardware/hardwaremanager.py
+++ b/src/hardware/hardwaremanager.py
@@ -50,6 +50,13 @@ class HardwareManager(object):
if track.flags & gst.interfaces.MIXER_TRACK_MASTER:
self._master = track
+def get_mute(self):
+if not self._mixer or not self._master:
+logging.error('Cannot get the mute status')
+return False
+return self._master.flags & gst.interfaces.MIXER_TRACK_MUTE \
+ == gst.interfaces.MIXER_TRACK_MUTE
+
def get_volume(self):
if not self._mixer or not self._master:
logging.error('Cannot get the volume')
@@ -57,9 +64,19 @@ class HardwareManager(object):
max_volume = self._master.max_volume
min_volume = self._master.min_volume
-volume = self._mixer.get_volume(self._master)[0]
-return volume * 100.0 / (max_volume - min_volume) + min_volume
+volumes = self._mixer.get_volume(self._master)
+
+#sometimes we get a spurious zero from one/more channel(s)
+#TODO: consider removing this when trac #6933 is resolved
+nonzero_volumes = [v for v in volumes if v > 0]
+
+if len(nonzero_volumes) > 0:
+#we could just pick the first nonzero volume, but this converges
+volume = sum(nonzero_volumes) / len(nonzero_volumes)
+return volume * 100.0 / (max_volume - min_volume) + min_volume
+else:
+return 0
def set_volume(self, volume):
if not self._mixer or not self._master:
@@ -76,7 +93,15 @@ class HardwareManager(object):
volume = volume * (max_volume - min_volume) / 100.0 + min_volume
volume_list = [ volume ] * self._master.num_channels
-self._mixer.set_volume(self._master, tuple(volume_list))
+#sometimes alsa sets one/more channels' volume to zero instead
+# of what we asked for, so try a few times
+#TODO: consider removing this loop when trac #6934 is resolved
+last_volumes_read = [0]
+read_count = 0
+while (0 in last_volumes_read) and (read_count < 3):
+self._mixer.set_volume(self._master, tuple(volume_list))
+last_volumes_read = self._mixer.get_volume(self._master)
+read_count += 1
def set_mute(self, mute):
if not self._mixer or not self._master:
diff --git a/src/model/devices/Makefile.am b/src/model/devices/Makefile.am
index 5440eeb..3124144 100644
--- a/src/model/devices/Makefile.am
+++ b/src/model/devices/Makefile.am
@@ -5,4 +5,6 @@ sugar_PYTHON = \
__init__.py \
device.py \
devicesmodel.py \
- battery.py
+ battery.py \
+ speaker.py
+
diff --git a/src/model/devices/devicesmodel.py
b/src/model/devices/devicesmodel.py
index 691e19e..e72a9d4 100644
--- a/src/model/devices/devicesmodel.py
+++ b/src/model/devices/devicesmodel.py
@@ -23,6 +23,7 @@ from model.devices import device
from model.devices.network import wireless
from model.devices.network import mesh
from model.devices import battery
+from model.devices import speaker
from hardware import hardwaremanager
from hardware import nmclient
@@ -54,6 +55,13 @@ class DevicesModel(gobject.GObject):
for udi in hal_manager.FindDeviceByCapability('battery'):
self.add_device(battery.Device(udi))
+try:
+self.add_device(speaker.Device())
+except Exception, speaker_fail_msg:
+logging.error("could not initialize speaker device: %s" %
+ speaker_fail_msg)
+logging.debug(traceback.format_exc())
+
def _observe_network_manager(self):
network_manager = hardwaremanager.get_network_manager()
if not network_manager:
diff --git a/src/model/devices/speaker.py b/src/model/devices/speaker.py
new file mode 100644
index 000..d3b9967
--- /dev/null
+++ b/src/model/devices/speaker.py
@@ -0,0 +1,59 @@
+# Copyright (C) 2008 Martin Dengler
+#
+# 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 vers
Re: [sugar] [PATCH] Add speaker device and icon by default
On Tue, May 06, 2008 at 05:40:30PM +0100, Martin Dengler wrote: > On Tue, May 06, 2008 at 04:39:30PM +0200, Tomeu Vizoso wrote: > > On 5/4/08, Martin Dengler <[EMAIL PROTECTED]> wrote: > > > On Tue, Apr 29, 2008 at 02:12:58PM +0200, Tomeu Vizoso wrote: > > > > I think that Michael has spotted here a wonderful opportunity for > > > > making Sugar more robust, thanks to your patch. > ... > > > I haven't forgotten this thread, just been unable to work on it. After working on it a bit more I think the right thing to do is just the small change Tomeu suggested. I would really like in the future to submit a patch that allows one to place a few files in a devices.d/ subdir - like model.py, view.py, icon.svg, etc. - and then the devicesmodel.py code could try to load each model.py appropriately, and so forth, but right now most of our "devices" really are device brokers (hal-dbus, networkmanager) and such a setup doesn't mesh well with them. Obviously in this patch would be the "do the initialization lazily and safely"-type of code that would make m_stone a lot happier. But in the meantime the two/three lines Tomeu suggested will still make things safer without adding lots of code; I will resubmit the patch and hopefully that will make everyone a bit happier. > > Thanks, > > > > Tomeu > > Martin Martin pgp19PvPR6OJ3.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] f8+ sugar-jhbuild telepathy-gabble problem
On Fri, May 09, 2008 at 12:38:00PM +0200, Guillaume Desmottes wrote: > Le vendredi 09 mai 2008 à 12:34 +0200, Marco Pesenti Gritti a écrit : > > On Fri, May 9, 2008 at 12:07 PM, Guillaume Desmottes > > <[EMAIL PROTECTED]> wrote: > > > > > > Thanks to the help of Frédéric Peters (jhbuild upstream maintainer) I > > > found the reason of this. > > > I pushed a fix to > > > https://dev.laptop.org/git?p=users/guillaume/sugar-jhbuild;a=shortlog;h=fix-fedora8 > > > > > > Waiting review from Marco before merging it to HEAD. > > > > Please push. In general everyone with access to the sugar-jhbuild > > module should feel free to push changes to sysdeps (just ask in the > > case that you are unsure). > > > > pushed. > > Martin: could you retry to build telepathy-gabble with an updated > sugar-jhbuild please? Guillaume/Marco, With the fix you both suggested (I just removed the sysdeps manually) telepathy-gabble builds fine after I removed source/telepathy-gabble*. Before removing that directory it wouldn't build cleanly. Thanks for your help. > G. Martin pgpQ3IYn0QvfJ.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] f8+ sugar-jhbuild telepathy-gabble problem
On Thu, May 08, 2008 at 07:25:14AM -0600, Bob Hampton wrote: > Martin: > > I installed from the .bz2 and it worked fine. Like you, I'm eagerly > awaiting FC9. Thanks Bob. FTR, I had tried installing the F9 rpm but that was too naive. Rebuilding rpms from the F9 srpm worked fine. > Regards, > Bob Martin pgpHru7e5YLuU.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] f8+ sugar-jhbuild telepathy-gabble problem
Hi sugar@, I'm having a problem with sugar-jhbuild that's somewhat new: loudmouth is 1.2.3 on a F8 + updates, but sugar-jhbuild now requires it to be 1.3.2: http://cree.xades.com/~martin/src/xo-sugar-jhbuild/telepathy-gabble.html#configure . In speaking with people on IRC, it appears that telepathy-gabble does now require this version of loudmouth but that F8 should work, so I'm probably just doing something wrong (yes, I've started with a new sugar-jhbuild a number of times, and I was previously able to build everything fine). Does anybody have telepathy-gabble building on F8? I plan on switching to F9 soon to minimize this type of issue (F9/rawhide has the right version of loudmouth, and though installing that rpm worked fine, telepathy-gabble failed to link due to loudmouth <-> glib issue), but it'd be helpful if someone were able to put me right in the meantime. Thanks, Martin pgpz9AHRDcNhK.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add speaker device and icon by default
On Tue, May 06, 2008 at 04:39:30PM +0200, Tomeu Vizoso wrote:
> On 5/4/08, Martin Dengler <[EMAIL PROTECTED]> wrote:
> > On Tue, Apr 29, 2008 at 02:12:58PM +0200, Tomeu Vizoso wrote:
> > > I think that Michael has spotted here a wonderful opportunity for
> > > making Sugar more robust, thanks to your patch.
...
> > I haven't forgotten this thread, just been unable to work on it.
> > After an hour of messing about with some ideas/code today, my current
> > approach is a bit more involved than just a try/except but nothing too
> > dramatic (just a small yak to shave):
> >
> > - refactor sugar/model/devices/device{,smodel}.py to make
> > adding/removing device.Device subclasses safe
> >
> > ... this begs one to do the next step or be left with many many
> > try/excepts and very ugly code (or just one try/except around
> > speaker.py, which kind of doesn't improve matters that much - though
> > it's very simple code and I'm happy to move on to other things if
> > people would accept that :) )
> >
> > - refactor sugar/model/devices/device{,semodel}.py to make discovering
> > device python files safe using metaclasses (see
> > http://blogs.gnome.org/jamesh/2008/02/12/python-metaclasses/ ); I
> > have considered the objections and alternatives including martian,
> > Zope's plugin framework design, and settled on this approach because
> > it's very simple, meets the very simple needs we have, and is very
> > little code
> >
> > ...this requires one to remove the networkmanager- and
> > halmanager-specific logic in devicesmodel.py:
> >
> > - create a new networkmanager model class that will add_device() and
> > remove_device() using the same logic that used to be in
> > devicesmodel.py
> >
> > - create a new halmanager model class in the same way
> >
> > ...and then we only need to:
> >
> > - trivially update battery.py and speaker.py
> >
> > - pretty trivially update network/mesh.py, wired.py, wireless.py;
> > these are only slightly more than trivial because devicesmodel.py
> > used to define some very network-specific variables that (IMO)
> > should be exposed by the networkmanager model (above) instead
> >
> > This explanation is long-winded only because I wanted to allow people
> > to poke holes in the approach, not because it's a lot of work.
>
> If it's not much work, can you provide a patch that gives an idea of
> what you plan to do? No need to be the final patch right now.
>
> Your ideas look interesting but I'm having a bit of difficulty in
> visualizing how you would refactor things.
This is not a patch because I think it's easier to read due to the
volume of refactoring, and it's very very much incomplete and
unpolished (as I said it's an hour's work), but if you look at them in
order you'll get an idea of what I'm trying, hopefully:
http://pastebin.be/11020 - devicesmodel.py - note this is refactored
to be much simpler, and the major *new* feature is simply the
metaclass usage (I still have to make it import everything in the
model.devices subtree, but you see where it's going)
http://pastebin.be/11021 - device.py - again, much simpler now and the
main changes are 1) register with the metaclass; and 2) subclassers
shoudl implement realize() rather than __init__() to do the real work
http://pastebin.be/11022 - battery.py - example of the changes; they
are basically trivial (superclass, move __init__() to realize(), call
super in realize())
http://pastebin.be/11023 - networkmanagermodel.py - this is where a
lot of devicesmodel.py has gone, because this is really a "meta
device" that creates new devices.Device subclasses as NM tells us
about device appearance/disappearance. This is completely in flux and
definitely doesn't work, but at least the comments might show you
where I'm going (this is my bullet point #3 above)
> Thanks,
>
> Tomeu
Martin
pgp6oA04ymjJy.pgp
Description: PGP signature
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add speaker device and icon by default
On Tue, Apr 29, 2008 at 02:12:58PM +0200, Tomeu Vizoso wrote:
> I think that Michael has spotted here a wonderful opportunity for
> making Sugar more robust, thanks to your patch.
>
> What about just making the shell to catch (and log) any exception
> resulting from the initialization of a device? That should amount to
> just add one try..except block.
>
> Devices are thought to be easily added, so its an expected source of
> new bugs. The shell should be able to start when any of them fail.
I haven't forgotten this thread, just been unable to work on it.
After an hour of messing about with some ideas/code today, my current
approach is a bit more involved than just a try/except but nothing too
dramatic (just a small yak to shave):
- refactor sugar/model/devices/device{,smodel}.py to make
adding/removing device.Device subclasses safe
... this begs one to do the next step or be left with many many
try/excepts and very ugly code (or just one try/except around
speaker.py, which kind of doesn't improve matters that much - though
it's very simple code and I'm happy to move on to other things if
people would accept that :) )
- refactor sugar/model/devices/device{,semodel}.py to make discovering
device python files safe using metaclasses (see
http://blogs.gnome.org/jamesh/2008/02/12/python-metaclasses/ ); I
have considered the objections and alternatives including martian,
Zope's plugin framework design, and settled on this approach because
it's very simple, meets the very simple needs we have, and is very
little code
...this requires one to remove the networkmanager- and
halmanager-specific logic in devicesmodel.py:
- create a new networkmanager model class that will add_device() and
remove_device() using the same logic that used to be in
devicesmodel.py
- create a new halmanager model class in the same way
...and then we only need to:
- trivially update battery.py and speaker.py
- pretty trivially update network/mesh.py, wired.py, wireless.py;
these are only slightly more than trivial because devicesmodel.py
used to define some very network-specific variables that (IMO)
should be exposed by the networkmanager model (above) instead
This explanation is long-winded only because I wanted to allow people
to poke holes in the approach, not because it's a lot of work.
> Thanks,
>
> Tomeu
Martin
pgpo4ewaNMhgI.pgp
Description: PGP signature
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [patch] Fullscreen button on Terminal activity
On Fri, May 02, 2008 at 06:36:33AM -0700, Nik Nyby wrote: > Here is a patch that adds a fullscreen button to the terminal, because > the alt-enter shortcut isn't obvious. > > It isn't vim or irssi friendly because pressing escape exits > fullscreen mode. I looked in /usr/share/sugar/shell/view/keyhandler.py > but couldn't find the keybinding for this. That seems undesirable. It looks like the code in question is in sugar-toolkit/sugar/graphics/window.py line 194 (current git). > Nik Martin pgpvj1PLBaHVm.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] make width/text of battery palette look nicer
---
src/view/devices/battery.py |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/view/devices/battery.py b/src/view/devices/battery.py
index a97d014..e4d82d3 100644
--- a/src/view/devices/battery.py
+++ b/src/view/devices/battery.py
@@ -84,6 +84,8 @@ class BatteryPalette(Palette):
self._level = 0
self._progress_bar = gtk.ProgressBar()
+self._progress_bar.set_size_request(
+style.zoom(style.GRID_CELL_SIZE * 4), -1)
self._progress_bar.show()
self._status_label = gtk.Label()
self._status_label.show()
@@ -120,7 +122,6 @@ class BatteryPalette(Palette):
'min': remaining_minpart})
else:
secondary_text = _('Charged')
-status_text = ''
self.props.secondary_text = secondary_text
self._status_label.set_text(status_text)
--
1.5.4.1
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] tweak battery charging (progress) bar
On Tue, Apr 29, 2008 at 06:09:36PM +0200, Marco Pesenti Gritti wrote: > On Tue, Apr 29, 2008 at 5:50 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > > > > On Tue, Apr 29, 2008 at 5:46 PM, Eben Eliason <[EMAIL PROTECTED]> wrote: > > > On Tue, Apr 29, 2008 at 8:56 AM, Martin Dengler > > > > > > <[EMAIL PROTECTED]> wrote: > > > > On Tue, Apr 29, 2008 at 02:03:21PM +0200, Marco Pesenti Gritti wrote: > > > > > On Tue, Apr 29, 2008 at 1:59 PM, Tomeu Vizoso <[EMAIL PROTECTED]> > > wrote: > > > > > > On Sat, Apr 26, 2008 at 2:17 AM, Martin Dengler > > > > > > <[EMAIL PROTECTED]> wrote: > > > > > > > + > > self.set_size_request(style.zoom(style.GRID_CELL_SIZE * 4), -1) > > > > > > > > > > > > Sounds good to me, but I think Marco dislikes set_size_request. > > > > > > > > > > > > Marco, what do you think? > > > > > > > > > > I don't think we should set palette size to a fixed width. The > > whole > > > > > gtk layout logic is dynamic, so that, for example, you can increase > > > > > the font size without screwing up... > > > > > > > > There is indeed little point in having a nice auto-sizing GUI if code > > > > is going to fix assumptions about sizes. > > > > > > > > In case you/anyone can think of something that might be acceptable, I > > > > want to make the motivation clear: 1) many of the palettes in the > > > > mockups at http://wiki.laptop.org/go/Designs/Frame seem to have a > > > > fixed size; and 2) on IRC eben mentioned he liked the palettes a bit > > > > wider (IIRC), and I, after trying it out on my XO, found the same. > > > > > > To make my goal clear: I have no intention of requiring all of the > > > device palettes to be a fixed width. For that matter, I don't care to > > > specify an absolute size for any of them individually. I do, however, > > > want to ensure that the sliders and meters and such within them have > > > enough horizontal space to accurately portray the info they contain. > > > I think that the battery meter should be about twice as wide as it is > > > currently. As such, there must be a way to tell it to be *at least* > > > some width, since below that width it's less readable. This is not a > > > fixed assumption. The palette can naturally expand as necessary to > > > allow room for longer text, etc. > > > > Perhaps setting the request size of the progressbar may be better? > > That should be fine. All done. To belabor the point a bit, I actually did this (set_size_request for the progressbar/hscale) first for both the battery and speaker, and then was slightly annoyed at the differing widths of the two palettes (just because the horizontal padding is different, so the same progressbar/hscale width results in different palette widths) and changed it. Patch coming to do what you want... > Marco Martin pgpS8ujwTscn6.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] fix #4646 - replace/normalize some keyboard shortcuts
---
src/view/keyhandler.py | 25 -
1 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/src/view/keyhandler.py b/src/view/keyhandler.py
index 306bb21..219cc5e 100644
--- a/src/view/keyhandler.py
+++ b/src/view/keyhandler.py
@@ -40,26 +40,25 @@ _actions_table = {
'F4' : 'zoom_activity',
'F9' : 'brightness_down',
'F10': 'brightness_up',
-'F9' : 'brightness_min',
-'F10' : 'brightness_max',
+'F9': 'brightness_min',
+'F10' : 'brightness_max',
'F11': 'volume_down',
'F12': 'volume_up',
-'F11' : 'volume_min',
-'F12' : 'volume_max',
+'F11' : 'volume_min',
+'F12' : 'volume_max',
'1' : 'screenshot',
-'f' : 'frame',
'0x93' : 'frame',
'0xEB' : 'rotate',
-'r' : 'rotate',
-'q' : 'quit_emulator',
'Tab' : 'next_window',
-'n' : 'next_window',
-'Tab' : 'previous_window',
-'p' : 'previous_window',
-'Escape' : 'close_window',
-'q': 'close_window',
+'Tab': 'previous_window',
+'Escape': 'close_window',
'0xDC' : 'open_search',
-'s' : 'say_text'
+# the following are intended for emulator users
+'f' : 'frame',
+'q' : 'quit_emulator',
+'o' : 'open_search',
+'r' : 'rotate',
+'s' : 'say_text',
}
J_DBUS_SERVICE = 'org.laptop.Journal'
--
1.5.4.1
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] fix #4646 - replace/normalize some keyboard shortcuts
---
src/view/keyhandler.py | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/view/keyhandler.py b/src/view/keyhandler.py
index 306bb21..eac4fa6 100644
--- a/src/view/keyhandler.py
+++ b/src/view/keyhandler.py
@@ -46,20 +46,20 @@ _actions_table = {
'F12': 'volume_up',
'F11' : 'volume_min',
'F12' : 'volume_max',
-'1' : 'screenshot',
-'f' : 'frame',
'0x93' : 'frame',
'0xEB' : 'rotate',
-'r' : 'rotate',
-'q' : 'quit_emulator',
'Tab' : 'next_window',
-'n' : 'next_window',
-'Tab' : 'previous_window',
-'p' : 'previous_window',
-'Escape' : 'close_window',
-'q': 'close_window',
+'Tab': 'previous_window',
+'Escape': 'close_window',
'0xDC' : 'open_search',
-'s' : 'say_text'
+'0xDC' : 'screenshot',
+# the following are intended for emulator users
+'1' : 'screenshot',
+'f' : 'frame',
+'q' : 'quit_emulator',
+'o' : 'open_search',
+'r' : 'rotate',
+'s' : 'say_text',
}
J_DBUS_SERVICE = 'org.laptop.Journal'
--
1.5.4.1
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] replace/normalize some keyboard shortcuts
On Tue, Apr 29, 2008 at 12:02:47PM -0400, Mikus Grinbergs wrote: > Eben wrote: > > I'm certainly all for removing alt-n and alt-p. We don't need > > redundant shortcuts here, and alt-tab and alt-shift-tab will work fine > > I disagree with alt-n and alt-p not considered useful. Either can > be done using TWO fingers. Needing three fingers for backwards-tab > navigation is quite awkward for me. FWIW I agree with Eben/others that alt-n/p are too invasive (likely to be used/desired by activity writers) and redundant to justify overcoming the awkwardness that all the other major WMs have decided isn't too much to force on users (the three fingered back-window keyboard shortcut). > [I don't actually care how you set the defaults -- I customize > keyhandler.py on my XO for my own preferences anyway (and if that > makes it more difficult for someone else to use my XO, I'd rather > make things easier for me than avoid customization).] Can you suggest any ideas as to how we might be able to allow you to do this more easily, without having to change keyhandler.py? The naive, straw man would be a ~/.sugar/keybindingsrc (and corresponding /etc/sugar-keybindingsrc) with ini file syntax... I'm interested in making this customization easier. > > In general, I would say that it's silly to use basic shortcuts for > > actions that have a dedicated button on the XO (rotate, frame) > > Whenever I'm at home, I plug an USB keyboard into my XO. It is not > silly for me to assign an unused F-key to 'frame' - again, that is > something that makes using the XO easier for me. This is another good use case justifying customization. > mikus Martin pgphvmHXwbkwR.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
