Re: [sugar] journal object transfer for 8.2
On Mon, Jun 9, 2008 at 11:09 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Mon, Jun 9, 2008 at 10:12 PM, Michael Stone [EMAIL PROTECTED] wrote: So the questions are: is this a feature we should deliver for the 8.2 release? In my opinion, no. Do you think differently? Personally I think we should put it at the very end of the prioritized list of new features: http://wiki.sugarlabs.org/go/ReleaseTeam/Roadmap#New_features If someone find time to work in by the feature freeze (20 June), it will be a nice feature to have. But otherwise let's focus to complete the features which are already scheduled for inclusion and on bugfixes. I really doubt there will be time for this, but would be nice to know if we should start talking about this after 8.2. Specially as changes across the stack may be needed. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH 1/2] set_mute -- set_muted, consistent with get_muted()
r+ Thanks!
On Wed, Jun 4, 2008 at 5:25 AM, Martin Dengler [EMAIL PROTECTED] wrote:
---
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 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
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
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Change tabbing to show a preview by opening the frame
Hi Benjamin, On Thu, Jun 5, 2008 at 12:20 AM, Benjamin Berg [EMAIL PROTECTED] wrote: Hello, Some patches that implement nicer tabbing will follow. With the patches applied, pressing Alt+Tab will show the frame. The activity that will be selected as soon as Alt is released again is shown by popping up its palette. Eben, could you apply these patches to your jhbuild and comment on the user experience? Unfortunately there are a couple of issues with palettes. One issue is that that at first only the primary palette is shown, but after a while the secondary palette will pop up (as the timeout is started automatically). Can you look at how the secondary palette is displayed by the right click? I understand that's what you want, right? Then I am accessing the _update_position function of the Palette directly, to handle disappearing activities properly. You mean to move left the palette when another activity icon disappears? Perhaps the Invoker should be listening for position changes on the observed widget and move the palette accordingly? The third thing I noticed is that there is a race condition in the Palette (which I think is my fault ...). I'll need to have a look at how to fix this. (The reason for the race is the code that delays the popup signal until the window has been mapped. IIRC that was needed so the gab drawing would work properly.) Ok. Before looking in detail at the code, have you considered relying on the window manager to do the tabbing and have the shell to just observe the changes on the tabbing stack? Perhaps wnck can help on that? Although I could find some time this week to look at these patches, I would be happier if Marco could find time do do it, as he knows better about these window manager stuff. I know he's very busy, though... Thanks, Tomeu ___ 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] New startup notification
r+ Thanks! On Sat, Jun 7, 2008 at 2:12 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: Hello, this is heavily based on Eben work. Full patch is attached, splitted up commits here (from Remove pending...): http://dev.laptop.org/git?p=users/marco/sugar;a=summary Not very well tested, I would like to get the big changes in and gradually improve on the base of it. It should be good enough to make the freeze. Eben, I had to increase the animation time to be able to see it, not sure why. Tomeu, I didn't do the iconify things for now, I have some doubts about it and this patch ended up not requiring huge changes to the model, so we can do that in a separate step. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] fix #4646 - replace/normalize some keyboard shortcuts
r+
As there are no code changes, I think that patches like this can get
into the repo just with Eben's approval.
Thanks,
Tomeu
On Mon, Jun 9, 2008 at 8:45 AM, Martin Dengler [EMAIL PROTECTED] wrote:
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',
-'ctrlF9' : 'brightness_min',
-'ctrlF10' : 'brightness_max',
+'altF9': 'brightness_min',
+'altF10' : 'brightness_max',
'F11': 'volume_down',
'F12': 'volume_up',
-'ctrlF11' : 'volume_min',
-'ctrlF12' : 'volume_max',
+'altF11' : 'volume_min',
+'altF12' : 'volume_max',
'alt1' : 'screenshot',
-'altf' : 'frame',
'0x93' : 'frame',
'0xEB' : 'rotate',
-'altr' : 'rotate',
-'altq' : 'quit_emulator',
'altTab' : 'next_window',
-'altn' : 'next_window',
-'ctrlaltTab' : 'previous_window',
-'altp' : 'previous_window',
-'ctrlEscape' : 'close_window',
-'ctrlq': 'close_window',
+'altshiftTab': 'previous_window',
+'altEscape': 'close_window',
'0xDC' : 'open_search',
-'alts' : 'say_text'
+# the following are intended for emulator users
+'altshiftf' : 'frame',
+'altshiftq' : 'quit_emulator',
+'altshifto' : 'open_search',
+'altshiftr' : 'rotate',
+'altshifts' : 'say_text',
}
J_DBUS_SERVICE = 'org.laptop.Journal'
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] journal object transfer for 8.2
On Tue, Jun 10, 2008 at 9:48 AM, Guillaume Desmottes [EMAIL PROTECTED] wrote: Le lundi 09 juin 2008 à 16:12 -0400, Michael Stone a écrit : Tomeu, have heard occasional requests to implement the sending and sharing of journal entries. It's a desirable feature but, from my perspective, it's much lower in immediate priority than work which brings the sugar UI revision into a releasable condition and which polish the existing work by closing several of the 379 tickets assigned to component 'sugar': http://dev.laptop.org/query?status=assignedstatus=newstatus=reopenedcomponent=sugarorder=prioritycol=idcol=summarycol=statuscol=typecol=prioritycol=milestonecol=component So the questions are: is this a feature we should deliver for the 8.2 release? In my opinion, no. Do you think differently? The new (work in progress) Telepathy file transfer specification should be able to nicely implement object transfer. But I doubt we'll have an implementation ready for 8.2. Could be a cool feature for the next release cycle though. Yup, I think we should consider it for the next cycle. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Change tabbing to show a preview by opening the frame
On Tue, Jun 10, 2008 at 9:58 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Although I could find some time this week to look at these patches, I would be happier if Marco could find time do do it, as he knows better about these window manager stuff. I know he's very busy, though... I could do an high level review, and then you guys help me out with the details... Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] not preserving journal
On Sat, Jun 7, 2008 at 10:06 PM, Mikus Grinbergs [EMAIL PROTECTED] wrote: I tend to __mess__ with my XO. As such, I realize I have to take my lumps once in a while. But - the OLPC appears to NOT be safe from people like me. I have two different builds (in /versions) on my XO - a Joyride and an Update.1. From the Update.1, I used 'olpc-update' to install Joyride 2024. It failed boot (sugar did not come up; and if I did not touch any buttons during boot I had no keyboard input, either). So I used the square button to boot into Update.1 -- and my Journal was empty. I've had the Journal cleaned out before, so I did NOT have anything that mattered in there. [I manually save everything important to a permanently-mounted SD card.] But for anyone who depends upon Journal, it would have been a traumatic experience. Yes, we have several tickets about these issues, but nobody to work on them :/ Anyway, note that most of the final users will have backups of their journal before updating, and that they will update once or twice per year, only to well tested images. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Adapt object chooser to new designs. Some refactoring was needed.
On Fri, Jun 6, 2008 at 8:42 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Hi, this patch adapts the object chooser to the mockups linked below. It was needed to refactor the ListView and CollapsedEntry classes in order to separate the common functionality between the journal list view and the one in the object chooser. Ooops. Missing link: http://wiki.laptop.org/go/Designs/Object_Chooser Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Avoid duplicates in the bundle registry
(sorry about the late reply) On Wed, May 28, 2008 at 1:15 PM, Michael Stone [EMAIL PROTECTED] wrote: On Wed, May 28, 2008 at 10:46:45AM +0200, Tomeu Vizoso wrote: On Tue, May 27, 2008 at 6:44 PM, Michael Stone [EMAIL PROTECTED] wrote: On Tue, May 27, 2008 at 09:15:39AM +0200, Tomeu Vizoso wrote: +for bundle in self._bundles: +if new_bundle.get_bundle_id() == bundle.get_bundle_id(): Why are we performing repeated linear search instead of storing bundles in a datastructure with sub-linear containment lookups (e.g. a set or a hashtable)? Because the patch is simpler this way. Why do you think that using a set or a table might be better here? Because my algorithm (store a dict mapping bundle id to biggest version yet seen) makes the same decisions yours does with one hash table lookup instead of O(n) string comparisons? We use dictionaries all around sugar, you can be sure we know what a hash table is. Should we replace all the structures used in Sugar that could be made more efficient? I proposed the patch that was simplest while addressed the users needs. I think that we should only do invasive changes where there's something tangible to win. Anyway, I guess we'll have to wait until some real testing is done for 8.2 in order to reach an agreement on what we should do with bundle management. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Journal able to use open with for activity bundles
(sorry about the big delay)
On Wed, May 28, 2008 at 9:44 PM, Jameson Chema Quinn
[EMAIL PROTECTED] wrote:
On Wed, May 28, 2008 at 12:16 PM, Tomeu Vizoso [EMAIL PROTECTED]
wrote:
Hi,
+if self._jobject.is_activity_bundle():
+menu_item = MenuItem(_('Start'))
+menu_item.connect('activate',
self._resume_menu_item_activate_cb,
+ None)
+palette.menu.append(menu_item)
+menu_item.show()
Why are we adding a Start menu item? How is it different from clicking
on the button?
We add a start menu item in case there is a choice to run or open with; if
there are choices, they should all be listed, even if one is available in a
simpler way (by just clicking). Also note that I plan, in the future, to
make the default behavior (clicking on the button) configurable using
metadata, so that you can have some bundles which are for editing.
Eben, can you comment on this UI change?
Thanks,
Tomeu
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
[sugar] frame activation
Hi, do we have any feedback regarding frame activation and the new control panel option? Is it ok to ship with hot corners on by default and let the users change it if they wish? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame activation
On 10.06.2008, at 12:15, Tomeu Vizoso wrote: Hi, do we have any feedback regarding frame activation and the new control panel option? Is it ok to ship with hot corners on by default and let the users change it if they wish? As much as I hate the mouse activation, I still think this is a sensible default. On the XO we have a Frame key, but on other hw discovering the frame could be a lot harder. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] review: Guillaume's 'activity' branch of Gadget
diff --git a/gadget/component.py b/gadget/component.py
index b5fc702..dd85a03 100644
--- a/gadget/component.py
+++ b/gadget/component.py
@@ -92,8 +92,9 @@ class Room(object):
def __init__(self, own_nick):
self.own_nick = own_nick
self.membership = None
-self.members = {}
+self.members = set()
self.properties = {}
+self.id = None
Would it be possible to just have a Room.activity property and use that to
store members/id?
class GadgetService(component.Service):
debug = False
@@ -333,7 +334,7 @@ class GadgetService(component.Service):
def message(self, stanza):
type = stanza.getAttribute('type', 'normal')
-if type in ('chat', 'groupchat'):
+if type in ('chat'):
return
This doesn't do quite what you want. () doesn't create a tuple, , does, so
this is the same as type in 'chat', which will be true if type is a
substring of chat. Better to just say ==.
if type == 'normal':
@@ -343,12 +344,17 @@ class GadgetService(component.Service):
return
elif (elem.uri == ns.ACTIVITY_PROP and
elem.name == 'properties'):
-self.message_activity_properties(stanza, elem)
+self.message_pre_invite_activity_properties(stanza, elem)
return
elif elem.uri == ns.PUBSUB_EVENT and elem.name == 'event':
self.message_pubsub_notification(stanza, elem)
return
+elif type == 'groupchat':
+for elem in stanza.elements():
+if elem.uri == ns.ACTIVITY_PROP and elem.name ==
'properties':
+self.message_activity_properties(stanza, elem)
You should return here. Perhaps we should dispatch messages more like we
dispatch IQs, i.e. using a dict.
+
# FIXME: handle close query stanza
log.msg('got unhandled message')
@@ -357,7 +363,7 @@ class GadgetService(component.Service):
if elem.uri == ns.MUC_USER and elem.name == 'invite':
self.message_muc_invite(stanza, elem)
-def create_room(self, jid, properties):
+def create_room(self, jid, properties, id):
Hmm, can we put the id before the properties? I think it's more aesthetically
pleasing that way.
if jid in self.mucs:
# We already have a room by this name.
return
@@ -366,9 +372,10 @@ class GadgetService(component.Service):
# join it.
room = Room('inspector')
room.properties = properties
+room.id = id
self.mucs[jid] = room
-def message_activity_properties(self, stanza, properties_elem):
+def message_pre_invite_activity_properties(self, stanza,
properties_elem):
# XXX Restrictions on from address?
try:
@@ -384,7 +391,7 @@ class GadgetService(component.Service):
if not (properties and activity and room_jid):
return
-self.create_room(room_jid, properties)
+self.create_room(room_jid, properties, activity)
Perhaps we should rename 'activity' to 'activity_id' for clarity.
def message_muc_invite(self, stanza, invite):
to = stanza.getAttribute('to')
@@ -502,17 +509,54 @@ class GadgetService(component.Service):
# Presence for our in-room self; we've finished joining the
# room.
room.membership = 'joined'
+
+# activities are created and added to the model when the
+# inspector actually joined the muc.
English nitpicks: Your tenses don't agree here. are created ... joined.
s/joined/join/. If you use a full stop, you should also capitalise the first
letter.
+# If we'll do it before, we won't be able to properly track
+# activity's properties and members.
I don't understand this comment.
+activity = self.model.activity_add(room.id, room_jid,
+room.properties)
+
+# Activity and Room now share the same set() object
+activity.members = room.members
return
+item = xpath_query('/presence/[EMAIL PROTECTED]%s]/item' %
ns.MUC_USER,
+stanza)
+if not item or item[0].getAttribute('jid') is None:
+log.msg(full jid of %s missing. Can't update activity members
+% jid.resource)
English nitpicks: you should capitalise full and have a full stop after
the second sentence.
+return
+
+full_jid = JID(item[0]['jid']).userhost()
Hmm, full_jid seems like a bad name, since it implies a JID with a resource.
Perhaps it should be real_jid or just jid.
+
+activities = self.model.activity_by_room(room_jid)
+
if type is None:
log.msg('room %s has
Re: [sugar] frame activation
do we have any feedback regarding frame activation and the new control panel option? As much as I hate the mouse activation, I still think this is a sensible default. On the XO we have a Frame key, but on other hw discovering the frame could be a lot harder. From using Joyride 2024, the new GUI option seems user-friendly (though the user needs to have the jabber_server_name written down beforehand, so he can type it in). But the old CLI option is still being supported -- and in its current state I find it confusing and inconsistent. The CLI should be friendlier (or be done away with). I myself think frame activation at the corners is an abomination - but as long as the Software Release Notes CLEARLY tell the user: Here is how to get rid of it, I'll accept it being on by default. [ Though using '2000' to mean 'never' seems strange (are floating point numbers being compared ?) ] What I myself do on other hw is to go into 'keyhandler.py', and define a spare F-key to be 'frame'. Then I can activate the frame using my non-XO keyboard. mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] not preserving journal
On Tue, Jun 10, 2008 at 11:06:37AM +0200, Tomeu Vizoso wrote: On Sat, Jun 7, 2008 at 10:06 PM, Mikus Grinbergs [EMAIL PROTECTED] wrote: Yes, we have several tickets about these issues, but nobody to work on them :/ Please cite ticket numbers. Anyway, note that most of the final users will have backups of their journal before updating, Huh? How are they going to have backups? Did someone release backup software without my noticing? Or are you simply betting that it will get done soon? Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] not preserving journal
On Tue, Jun 10, 2008 at 4:19 PM, Michael Stone [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 11:06:37AM +0200, Tomeu Vizoso wrote: On Sat, Jun 7, 2008 at 10:06 PM, Mikus Grinbergs [EMAIL PROTECTED] wrote: Yes, we have several tickets about these issues, but nobody to work on them :/ Please cite ticket numbers. Will try to set some time aside to get those tickets to you. Anyway, note that most of the final users will have backups of their journal before updating, Huh? How are they going to have backups? Did someone release backup software without my noticing? Or are you simply betting that it will get done soon? Are you telling me that kids are going to update to a newer build without having backups? Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] Make the favorite activity icons draggable
Hi,
this patch adds the ability to drag activity icons out from the ring.
Thanks,
Tomeu
From 5b44c112e59ed581001bdcadb962ff7f2bb9f9d7 Mon Sep 17 00:00:00 2001
From: Tomeu Vizoso [EMAIL PROTECTED](none)
Date: Tue, 10 Jun 2008 16:55:37 +0200
Subject: [PATCH] Make the favorite activity icons draggable
---
src/view/home/FriendsBox.py | 12 ++-
src/view/home/HomeBox.py| 15 ++-
src/view/home/HomeWindow.py | 31 +++--
src/view/home/MeshBox.py| 12 ++-
src/view/home/activitieslist.py | 22 ++--
src/view/home/activitiesring.py | 263 ++-
src/view/home/launchbox.py |8 +-
src/view/home/transitionbox.py | 13 ++-
8 files changed, 274 insertions(+), 102 deletions(-)
diff --git a/src/view/home/FriendsBox.py b/src/view/home/FriendsBox.py
index 7c6648a..8c6ddcf 100644
--- a/src/view/home/FriendsBox.py
+++ b/src/view/home/FriendsBox.py
@@ -14,6 +14,7 @@
# 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
import gtk
import hippo
@@ -26,16 +27,19 @@ from model import shellmodel
from view.home.FriendView import FriendView
from view.home.spreadlayout import SpreadLayout
-class FriendsBox(hippo.CanvasBox):
+class FriendsBox(hippo.Canvas):
__gtype_name__ = 'SugarFriendsBox'
def __init__(self):
-hippo.CanvasBox.__init__(self,
- background_color=style.COLOR_WHITE.get_int())
+gobject.GObject.__init__(self)
+
+self._box = hippo.CanvasBox()
+self._box.props.background_color = style.COLOR_WHITE.get_int()
+self.set_root(self._box)
self._friends = {}
self._layout = SpreadLayout()
-self.set_layout(self._layout)
+self._box.set_layout(self._layout)
self._owner_icon = CanvasIcon(icon_name='computer-xo', cache=True,
xo_color=profile.get_color())
diff --git a/src/view/home/HomeBox.py b/src/view/home/HomeBox.py
index fa22a11..429b903 100644
--- a/src/view/home/HomeBox.py
+++ b/src/view/home/HomeBox.py
@@ -18,7 +18,6 @@ from gettext import gettext as _
import gobject
import gtk
-import hippo
from sugar.graphics import style
from sugar.graphics import iconentry
@@ -32,11 +31,11 @@ _LIST_VIEW = 1
_AUTOSEARCH_TIMEOUT = 1000
-class HomeBox(hippo.CanvasBox, hippo.CanvasItem):
+class HomeBox(gtk.VBox):
__gtype_name__ = 'SugarHomeBox'
def __init__(self):
-hippo.CanvasBox.__init__(self)
+gobject.GObject.__init__(self)
self._ring_view = ActivitiesRing()
self._list_view = ActivitiesList()
@@ -45,7 +44,8 @@ class HomeBox(hippo.CanvasBox, hippo.CanvasItem):
self._toolbar = HomeToolbar()
self._toolbar.connect('query-changed', self.__toolbar_query_changed_cb)
self._toolbar.connect('view-changed', self.__toolbar_view_changed_cb)
-self.append(hippo.CanvasWidget(widget=self._toolbar))
+self.pack_start(self._toolbar, expand=False)
+self._toolbar.show()
self._set_view(_RING_VIEW)
@@ -66,13 +66,14 @@ class HomeBox(hippo.CanvasBox, hippo.CanvasItem):
if self._enable_xo_palette:
self._ring_view.enable_xo_palette()
-self.append(self._ring_view, hippo.PACK_EXPAND)
-
+self.add(self._ring_view)
+self._ring_view.show()
elif view == _LIST_VIEW:
if self._ring_view in self.get_children():
self.remove(self._ring_view)
-self.append(self._list_view, hippo.PACK_EXPAND)
+self.add(self._list_view)
+self._list_view.show()
else:
raise ValueError('Invalid view: %r' % view)
diff --git a/src/view/home/HomeWindow.py b/src/view/home/HomeWindow.py
index 9151d46..03a571e 100644
--- a/src/view/home/HomeWindow.py
+++ b/src/view/home/HomeWindow.py
@@ -15,7 +15,6 @@
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
import gtk
-import hippo
from sugar.graphics import style
from sugar.graphics import palettegroup
@@ -44,10 +43,6 @@ class HomeWindow(gtk.Window):
self._active = False
self._level = ShellModel.ZOOM_HOME
-self._canvas = hippo.Canvas()
-self.add(self._canvas)
-self._canvas.show()
-
self.set_default_size(gtk.gdk.screen_width(),
gtk.gdk.screen_height())
@@ -70,8 +65,9 @@ class HomeWindow(gtk.Window):
self.launch_box = LaunchBox()
self._activate_view()
-self._canvas.set_root(self._home_box)
-
+self.add(self._home_box)
+self._home_box.show()
+
self._transition_box.connect('completed',
self._transition_completed_cb)
@@ -122,8 +118,9 @@ class HomeWindow(gtk.Window):
self._deactivate_view()
Re: [sugar] [PATCH] Change tabbing to show a preview by opening the frame
On Tue, 2008-06-10 at 09:58 +0200, Tomeu Vizoso wrote: On Thu, Jun 5, 2008 at 12:20 AM, Benjamin Berg Unfortunately there are a couple of issues with palettes. One issue is that that at first only the primary palette is shown, but after a while the secondary palette will pop up (as the timeout is started automatically). Can you look at how the secondary palette is displayed by the right click? I understand that's what you want, right? Yup, something like that. Though it will need to be handled differently than the right click code. I guess just adding another parameter to popdown will work. Then I am accessing the _update_position function of the Palette directly, to handle disappearing activities properly. You mean to move left the palette when another activity icon disappears? Perhaps the Invoker should be listening for position changes on the observed widget and move the palette accordingly? Yeah, something like that. Though I am not sure what is needed to get it working right now. Before looking in detail at the code, have you considered relying on the window manager to do the tabbing and have the shell to just observe the changes on the tabbing stack? Perhaps wnck can help on that? To say the truth I did not even consider it, as tabbing is already handled by Sugar in the existing code. That said, I just had a quick look, but could not find anything in metacity or libwnck that suggests that leaving tabbing to the window manager is possible. Benjamin signature.asc Description: This is a digitally signed message part ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Refactor invites for 1-1 Chat (#6298)
On Wed, Jun 4, 2008 at 17:25, Guillaume Desmottes [EMAIL PROTECTED] wrote: Le mercredi 04 juin 2008 à 17:08 +0200, Morgan Collett a écrit : The main code to review is at: http://dev.laptop.org/git?p=users/morgan/sugar;a=shortlog;h=6298 (3 most recent patches). As bundle_id is passed to both constructor, you could move it to BaseInvite.__init__ Didn't read code carefully but InviteButton and InvitePalette still contain lot of: if shared: ... else: # private Maybe it would be worth to abstract these 2 classes too if possible? Done, in the patch http://dev.laptop.org/git?p=users/morgan/sugar;a=commitdiff;h=0383581b2789fa7a8d0f8eb99da6068eb67b5500 Sugar Team, please can I have further review: The main code to review is at: http://dev.laptop.org/git?p=users/morgan/sugar;a=shortlog;h=6298 (4 most recent patches). http://dev.laptop.org/git?p=users/morgan/sugar-toolkit;a=shortlog;h=6298 - Guillaume's change, r+ from me - Can I push this to sugar-toolkit? Related changes are at: http://dev.laptop.org/git?p=users/morgan/presence-service;a=shortlog;h=6298 - Guillaume's change, r+ from me - Waiting on the above sugar-toolkit patch approval http://dev.laptop.org/git?p=users/morgan/chat-activity;a=shortlog;h=6298 - r+ from me for all Guillaume's changes Regards Morgan ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame activation
I've played with it a lot. I think that a 1/3 second delay goes a long way to preventing accidental activation, but likely isn't long enough to prevent discovery, especially in a classroom full of kids. If everyone tests it out with a delay in this range and agrees, we could institute a delay between 1/3 and 1/2 second by default and probably provide a better out-of-the-box experience. - Eben On Tue, Jun 10, 2008 at 8:08 AM, Walter Bender [EMAIL PROTECTED] wrote: Bert's point is a good one and a further argument for keeping it configurable. On my XO, the touchpad is flaky but there is a frame key. On my HP, the touchpad is reasonably stable, but I need to remember an undiscoverable keyboard binding. So I would like to have almost opposite behaviors depending upon the hardware. -walter On Tue, Jun 10, 2008 at 6:19 AM, Bert Freudenberg [EMAIL PROTECTED] wrote: On 10.06.2008, at 12:15, Tomeu Vizoso wrote: Hi, do we have any feedback regarding frame activation and the new control panel option? Is it ok to ship with hot corners on by default and let the users change it if they wish? As much as I hate the mouse activation, I still think this is a sensible default. On the XO we have a Frame key, but on other hw discovering the frame could be a lot harder. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame activation
Can we set up an actually experiment with some children? Uruguay, Paraguay, and Peru all agreed to help. This seems like a obvious place to start. -walter On Tue, Jun 10, 2008 at 11:33 AM, Eben Eliason [EMAIL PROTECTED] wrote: I've played with it a lot. I think that a 1/3 second delay goes a long way to preventing accidental activation, but likely isn't long enough to prevent discovery, especially in a classroom full of kids. If everyone tests it out with a delay in this range and agrees, we could institute a delay between 1/3 and 1/2 second by default and probably provide a better out-of-the-box experience. - Eben On Tue, Jun 10, 2008 at 8:08 AM, Walter Bender [EMAIL PROTECTED] wrote: Bert's point is a good one and a further argument for keeping it configurable. On my XO, the touchpad is flaky but there is a frame key. On my HP, the touchpad is reasonably stable, but I need to remember an undiscoverable keyboard binding. So I would like to have almost opposite behaviors depending upon the hardware. -walter On Tue, Jun 10, 2008 at 6:19 AM, Bert Freudenberg [EMAIL PROTECTED] wrote: On 10.06.2008, at 12:15, Tomeu Vizoso wrote: Hi, do we have any feedback regarding frame activation and the new control panel option? Is it ok to ship with hot corners on by default and let the users change it if they wish? As much as I hate the mouse activation, I still think this is a sensible default. On the XO we have a Frame key, but on other hw discovering the frame could be a lot harder. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame activation
On Tue, Jun 10, 2008 at 11:39 AM, Walter Bender [EMAIL PROTECTED] wrote: Can we set up an actually experiment with some children? Uruguay, Paraguay, and Peru all agreed to help. This seems like a obvious place to start. Yes, that would be helpful as well. In order to make that feasible, we need to find a good way to let them install builds for testing purposes. I suspect that Scott might have been considering this use case when he mentioned breaking the builds into development/unstable, testing, QA, and stable. Ideally we'd provide a singed testing build so that the kids don't all need to request dev keys to get us the proper feedback. Can anyone provide insight onto how/when we might be able to do this? - Eben ps I did help Carla get a dev key and install a testing build including the new activity launching feedback and the control panel, so that she had at least one machine for testing these features and the delay on the Frame. -walter On Tue, Jun 10, 2008 at 11:33 AM, Eben Eliason [EMAIL PROTECTED] wrote: I've played with it a lot. I think that a 1/3 second delay goes a long way to preventing accidental activation, but likely isn't long enough to prevent discovery, especially in a classroom full of kids. If everyone tests it out with a delay in this range and agrees, we could institute a delay between 1/3 and 1/2 second by default and probably provide a better out-of-the-box experience. - Eben On Tue, Jun 10, 2008 at 8:08 AM, Walter Bender [EMAIL PROTECTED] wrote: Bert's point is a good one and a further argument for keeping it configurable. On my XO, the touchpad is flaky but there is a frame key. On my HP, the touchpad is reasonably stable, but I need to remember an undiscoverable keyboard binding. So I would like to have almost opposite behaviors depending upon the hardware. -walter On Tue, Jun 10, 2008 at 6:19 AM, Bert Freudenberg [EMAIL PROTECTED] wrote: On 10.06.2008, at 12:15, Tomeu Vizoso wrote: Hi, do we have any feedback regarding frame activation and the new control panel option? Is it ok to ship with hot corners on by default and let the users change it if they wish? As much as I hate the mouse activation, I still think this is a sensible default. On the XO we have a Frame key, but on other hw discovering the frame could be a lot harder. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] wiki navigation
A link was explicitly not provided here because the mockups shown presently are a somewhat pared-down version for short-term implementation for the upcoming release, and without description. I have a more extensive series of designs which I want to make public in the near future for the community to comment on, at which point I'll add the link from Designs to make them more discoverable. - Eben On Tue, Jun 3, 2008 at 12:29 PM, Mikus Grinbergs [EMAIL PROTECTED] wrote: * Improve the object chooser: http://wiki.laptop.org/go/Designs/Object_Chooser Hadn't realized there was a page for this in the wiki. Please, if 'Object_Chooser' is a subtopic of 'Designs, a __link__ to 'Object_Chooser' placed on the 'Designs' page would be useful. mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Adapt object chooser to new designs. Some refactoring was needed.
Tomeu Vizoso wrote: Hi, this patch adapts the object chooser to the mockups linked below. It was needed to refactor the ListView and CollapsedEntry classes in order to separate the common functionality between the journal list view and the one in the object chooser. Thanks, Tomeu Hi Tomeu, looks very nice your code - even fixes a lot of pylint warnings :) One note: *** objectchooser.py: I think we don't have to pass the parent window to ObjectChooser(gtk.Window). This is how we handle it as well for the controlpanel (was a suggestion by marco as well). chooser = ObjectChooser() chooser.set_transient_for(parent) chooser.show() Could not see the code in action yet since I am updating on F-9 currently :/ but the logic looks very good. Best, Simon ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Avoid duplicates in the bundle registry
Let me try to sketch out the plan understand and interpret it from
http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_1. (episode 2 was
more about how to handle the files/bundles or objects/actions distinction,
which is farther off).
1. in the future, object ID will just be a hash of the non-human-readable
signing key for an activity.
1.a) this will not change over minor version changes. It may not change over
major version changes, or, if author intends bugfix releases of the old
version, it may deliberately change. If there is a discontinuity in
authorship (key lost) it must change.
1.a)1)when we have signatures, hash collisions will be assumed to be a
deliberate attack, and will just refuse to install.
b) for right now, we can just use object ID.
2. Within each object ID, there can be any number of versions simultaneously
installed.
2.a) just id/version is not unique, for instance if an activity is under
active development on that machine.
2.a)i) An idea of mine, not discussed yet: we actually could try to enforce
the idea that any two activities which match on {id,version,bool(has valid
signature)} are interchangeable - just silently use the first one seen for
bundles with a valid signature (release versions), and the last one seen for
b. without v.s. (development versions.
2.b)Even if we can get some combination of data (besides just hashing the
whole bundle) that is unique, or if we make a pre-signature approximation
that id/version is unique, there will still be a large potential for
clutter.
3. Which one to use?
3a) Each journal object will have metadata with all identifying data (id,
version, sig?, hash) of the last activity.
3b) For some activity ids, there will be (at most) one starred version.
3c) Journal objects will open by default with {own id, max(starred version,
own version)}, or if that is unavailable starred version, or if that is
unavailable latest version.
3d) Unstarred id's can still be grouped/collapsed in the activity list.
3d) imported objects will open by default with starred or latest version
4. Garbage collection of old installed versions (this patch)
4a) Any versions older than starred version are eligible for GC.
4b) Suggestion (not discussed): Grace period to notice broken features: When
starred version changes, garbage collection on that ID is frozen until the
new starred version has been used at least 3 times.
4c) Suggestion: Suggested updates: First time quitting a version newer than
starred version, ask user if they want to move the star.
4d) Suggestion: when you see a shared activity in the mesh, some UI hint to
show if it is newer/older/same version as your starred/latest version.
(also, see imposing changelogs in the discussion)
...
As an aside, I think that it is a mistake to impose integer versions. I
think that a general n-number versioning system, with a hyphen as a
separator (to avoid the 1.10 problem), but Glucose only understands the
ordering and makes no distinction between major and minor version. This
would support integers, major-minor, major-minor-bugfix, or other similar
systems, without imposing one.
Jameson
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Journal able to use open with for activity bundles
This change fixes a bug: journal is unable to do anything but start a
bundle, even if you have an activity (Develop) which can handle the activity
bundle mime type.
The immediate question is: should start be available only by pressing the
button, or should it also be an option in the pulldown? I think that the
answer is an obvious yes.
The longer term question is: should start always be the default for
bundles, or should it be possible to have a bundle whose default action is
Develop? However, discussion on this larger question should not block
approving the immediate patch.
On Tue, Jun 10, 2008 at 10:02 AM, Eben Eliason [EMAIL PROTECTED]
wrote:
I'm confused, actually. We already have Start as the first option
in the palette for raw activities, and as the action listed on the
button in the detail view. What is the intent for the change being
discussed here?
- Eben
On Tue, Jun 10, 2008 at 5:57 AM, Tomeu Vizoso [EMAIL PROTECTED]
wrote:
(sorry about the big delay)
On Wed, May 28, 2008 at 9:44 PM, Jameson Chema Quinn
[EMAIL PROTECTED] wrote:
On Wed, May 28, 2008 at 12:16 PM, Tomeu Vizoso [EMAIL PROTECTED]
wrote:
Hi,
+if self._jobject.is_activity_bundle():
+menu_item = MenuItem(_('Start'))
+menu_item.connect('activate',
self._resume_menu_item_activate_cb,
+ None)
+palette.menu.append(menu_item)
+menu_item.show()
Why are we adding a Start menu item? How is it different from clicking
on the button?
We add a start menu item in case there is a choice to run or open with;
if
there are choices, they should all be listed, even if one is available
in a
simpler way (by just clicking). Also note that I plan, in the future, to
make the default behavior (clicking on the button) configurable using
metadata, so that you can have some bundles which are for editing.
Eben, can you comment on this UI change?
Thanks,
Tomeu
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Journal able to use open with for activity bundles
On Tue, Jun 10, 2008 at 2:16 PM, Jameson Chema Quinn
[EMAIL PROTECTED] wrote:
This change fixes a bug: journal is unable to do anything but start a
bundle, even if you have an activity (Develop) which can handle the activity
bundle mime type.
Right, this merits the possible addition of a Start as (wording?) type menu.
The immediate question is: should start be available only by pressing the
button, or should it also be an option in the pulldown? I think that the
answer is an obvious yes.
I'm stating that Start is /already/ an option in the pulldown, so
what's the point of argument?
The longer term question is: should start always be the default for
bundles, or should it be possible to have a bundle whose default action is
Develop? However, discussion on this larger question should not block
approving the immediate patch.
Agreed. And I'm not sure what my answer is, yet.
On Tue, Jun 10, 2008 at 10:02 AM, Eben Eliason [EMAIL PROTECTED]
wrote:
I'm confused, actually. We already have Start as the first option
in the palette for raw activities, and as the action listed on the
button in the detail view. What is the intent for the change being
discussed here?
- Eben
On Tue, Jun 10, 2008 at 5:57 AM, Tomeu Vizoso [EMAIL PROTECTED]
wrote:
(sorry about the big delay)
On Wed, May 28, 2008 at 9:44 PM, Jameson Chema Quinn
[EMAIL PROTECTED] wrote:
On Wed, May 28, 2008 at 12:16 PM, Tomeu Vizoso [EMAIL PROTECTED]
wrote:
Hi,
+if self._jobject.is_activity_bundle():
+menu_item = MenuItem(_('Start'))
+menu_item.connect('activate',
self._resume_menu_item_activate_cb,
+ None)
+palette.menu.append(menu_item)
+menu_item.show()
Why are we adding a Start menu item? How is it different from clicking
on the button?
We add a start menu item in case there is a choice to run or open with;
if
there are choices, they should all be listed, even if one is available
in a
simpler way (by just clicking). Also note that I plan, in the future,
to
make the default behavior (clicking on the button) configurable using
metadata, so that you can have some bundles which are for editing.
Eben, can you comment on this UI change?
Thanks,
Tomeu
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] to Browse activity; trac #6250
The following patch resolves trac #6250 (and #6999). I have tested and pushed the patch into the web-activity git repo. From 9e3c4d01dc2b368ef0636cce598dd655446fb883 Mon Sep 17 00:00:00 2001 From: Erik Garrison [EMAIL PROTECTED] Date: Tue, 10 Jun 2008 14:29:17 -0400 Subject: [PATCH] To resolve trac 6250, we disable browser detection of offline mode using xpcom. --- browser.py |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/browser.py b/browser.py index f57bafa..208ff93 100644 --- a/browser.py +++ b/browser.py @@ -83,6 +83,11 @@ class Browser(WebView): @mozilla.org/network/io-service;1] io_service = io_service_class.getService(interfaces.nsIIOService) +# Use xpcom to turn off offline mode detection, which disables +# access to localhost for no good reason. (Trac #6250.) +io_service2 = io_service_class.getService(interfaces.nsIIOService2) +io_service2.manageOfflineStatus = False + cls = components.classes['@mozilla.org/content/style-sheet-service;1'] style_sheet_service = cls.getService(interfaces.nsIStyleSheetService) -- 1.5.4.3 From 9e3c4d01dc2b368ef0636cce598dd655446fb883 Mon Sep 17 00:00:00 2001 From: Erik Garrison [EMAIL PROTECTED] Date: Tue, 10 Jun 2008 14:29:17 -0400 Subject: [PATCH] To resolve trac 6250, we disable browser detection of offline mode using xpcom. --- browser.py |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/browser.py b/browser.py index f57bafa..208ff93 100644 --- a/browser.py +++ b/browser.py @@ -83,6 +83,11 @@ class Browser(WebView): @mozilla.org/network/io-service;1] io_service = io_service_class.getService(interfaces.nsIIOService) +# Use xpcom to turn off offline mode detection, which disables +# access to localhost for no good reason. (Trac #6250.) +io_service2 = io_service_class.getService(interfaces.nsIIOService2) +io_service2.manageOfflineStatus = False + cls = components.classes['@mozilla.org/content/style-sheet-service;1'] style_sheet_service = cls.getService(interfaces.nsIStyleSheetService) -- 1.5.4.3 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame activation
On Tue, Jun 10, 2008 at 8:39 AM, Walter Bender [EMAIL PROTECTED] wrote: Can we set up an actually experiment with some children? Uruguay, Paraguay, and Peru all agreed to help. This seems like a obvious place to start. -walter Thank you, Walter. You are the first I have seen asking such a question. I have been wondering when we would get to asking children how a children's laptop should work. -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ The best way to predict the future is to invent it.--Alan Kay ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Journal able to use open with for activity bundles
On Tue, Jun 10, 2008 at 12:21 PM, Eben Eliason [EMAIL PROTECTED]
wrote:
On Tue, Jun 10, 2008 at 2:16 PM, Jameson Chema Quinn
[EMAIL PROTECTED] wrote:
This change fixes a bug: journal is unable to do anything but start a
bundle, even if you have an activity (Develop) which can handle the
activity
bundle mime type.
Right, this merits the possible addition of a Start as (wording?) type
menu.
The immediate question is: should start be available only by pressing
the
button, or should it also be an option in the pulldown? I think that the
answer is an obvious yes.
I'm stating that Start is /already/ an option in the pulldown, so
what's the point of argument?
This is the details view pulldow. Look at the patch:
-
-if not self._jobject.is_activity_bundle():
-for activity in self._jobject.get_activities():
-menu_item = MenuItem(activity.name)
-menu_item.set_image(Icon(file=activity.icon,
icon_size=gtk.ICON_SIZE_MENU))
-menu_item.connect('activate',
self._resume_menu_item_activate_cb,
- activity.bundle_id)
-palette.menu.append(menu_item)
-menu_item.show()
+
+if self._jobject.is_activity_bundle():
+menu_item = MenuItem(_('Start'))
+menu_item.connect('activate',
self._resume_menu_item_activate_cb,
+ None)
+palette.menu.append(menu_item)
+menu_item.show()
+activities = self._jobject.get_activities()
+for activity in activities:
+menu_item = MenuItem(activity.name)
+menu_item.set_image(Icon(file=activity.icon,
icon_size=gtk.ICON_SIZE_MENU))
+menu_item.connect('activate',
self._resume_menu_item_activate_cb,
+ activity.bundle_id)
+palette.menu.append(menu_item)
+menu_item.show()
Instead of only constructing a pulldown for non-activity-bundles, it does
one for both. It first includes an option to start for activity bundles,
then continues with the normal logic which gives options of all activities
which handle the relevant MIME.
I submit that this should not be controversial, that the controversy here
comes from misunderstanding.
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
[sugar] Fwd: [poppler] [Announce] PyPoppler 0.8.1
I think someone was looking for this some months ago... Marco -- Forwarded message -- From: Gian Mario Tagliaretti [EMAIL PROTECTED] Date: Tue, Jun 10, 2008 at 10:18 PM Subject: [poppler] [Announce] PyPoppler 0.8.1 To: [EMAIL PROTECTED], PyGtk Mail-List [EMAIL PROTECTED], Discussioni generali sul linguaggio Python [EMAIL PROTECTED], [EMAIL PROTECTED] I am pleased to announce version 0.8.1 of the Python bindings for Poppler. It is available at: http://www.gnome.org/~gianmt/pypoppler-0.8.1.tar.gz The above location is temporary, until I will find a nice house for future releases. What's new: === o Fix a compilation failure against poppler 0.8.3 Fixes LP#238653. Patch from Chris Mayo. (Gian Mario) o Add GPL headers. (Gian Mario) Blurb: == Poppler[1] is a PDF rendering library based on the xpdf-3.0 code base. PyPoppler is a wrapper which exposes the poppler API to the python world. It is fairly complete, most of the API are covered. The documentation is actually missing, help wanted :) Like the Poppler library itself, PyPoppler is licensed under the GNU GPL. PyPoppler requires: = o Poppler = 0.8.3 o PyGObject = 2.10.1 (2.11.3 to build the docs) o PyGTK = 2.10.0 o PyCairo = 1.2.0 Bug reports should go to https://launchpad.net/poppler-python [1] http://poppler.freedesktop.org/ cheers -- Gian Mario Tagliaretti ___ poppler mailing list [EMAIL PROTECTED] http://lists.freedesktop.org/mailman/listinfo/poppler ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Journal able to use open with for activity bundles
Actually, I disagree with adding Start separately to the secondary
palette as this will appear redundant beneath the already existing
Start label in the primary palette. The better solution (and I
think, the expected behavior) is to make the primary palette clickable
when the palette is anchored, such that clicking it enacts the action
of the button it is attached to.
Regarding the other options, I think it would be clearer (albeit,
admittedly, slightly more indirect) to place the list of available
activities in a submenu labeled Start with to convey the action that
selecting an activity will take. This would be true of the submenu
regardless of whether or not the entry represents a bundle, leaving us
in a state where the only difference between bundles and instances is
the phrasing used within the menu. Otherwise, they are functionally
identical.
- Eben
On Tue, Jun 10, 2008 at 4:13 PM, Jameson Chema Quinn
[EMAIL PROTECTED] wrote:
On Tue, Jun 10, 2008 at 12:21 PM, Eben Eliason [EMAIL PROTECTED]
wrote:
On Tue, Jun 10, 2008 at 2:16 PM, Jameson Chema Quinn
[EMAIL PROTECTED] wrote:
This change fixes a bug: journal is unable to do anything but start a
bundle, even if you have an activity (Develop) which can handle the
activity
bundle mime type.
Right, this merits the possible addition of a Start as (wording?) type
menu.
The immediate question is: should start be available only by pressing
the
button, or should it also be an option in the pulldown? I think that the
answer is an obvious yes.
I'm stating that Start is /already/ an option in the pulldown, so
what's the point of argument?
This is the details view pulldow. Look at the patch:
-
-if not self._jobject.is_activity_bundle():
-for activity in self._jobject.get_activities():
-menu_item = MenuItem(activity.name)
-menu_item.set_image(Icon(file=activity.icon,
icon_size=gtk.ICON_SIZE_MENU))
-menu_item.connect('activate',
self._resume_menu_item_activate_cb,
- activity.bundle_id)
-palette.menu.append(menu_item)
-menu_item.show()
+
+if self._jobject.is_activity_bundle():
+menu_item = MenuItem(_('Start'))
+menu_item.connect('activate',
self._resume_menu_item_activate_cb,
+ None)
+palette.menu.append(menu_item)
+menu_item.show()
+activities = self._jobject.get_activities()
+for activity in activities:
+menu_item = MenuItem(activity.name)
+menu_item.set_image(Icon(file=activity.icon,
icon_size=gtk.ICON_SIZE_MENU))
+menu_item.connect('activate',
self._resume_menu_item_activate_cb,
+ activity.bundle_id)
+palette.menu.append(menu_item)
+menu_item.show()
Instead of only constructing a pulldown for non-activity-bundles, it does
one for both. It first includes an option to start for activity bundles,
then continues with the normal logic which gives options of all activities
which handle the relevant MIME.
I submit that this should not be controversial, that the controversy here
comes from misunderstanding.
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Journal able to use open with for activity bundles
On Tue, Jun 10, 2008 at 2:30 PM, Eben Eliason [EMAIL PROTECTED] wrote: Actually, I disagree with adding Start separately to the secondary palette as this will appear redundant beneath the already existing Start label in the primary palette. The better solution (and I think, the expected behavior) is to make the primary palette clickable when the palette is anchored, such that clicking it enacts the action of the button it is attached to. I agree that this is how palettes should work (of course, not the issue here). However, I don't understand your opposition to repeating the start option in the submenu. Any journal item already repeats the default option in this list; doing the same for activity bundles is only consistent. If we are going to change this, it is a separate patch. Regarding the other options, I think it would be clearer (albeit, admittedly, slightly more indirect) to place the list of available activities in a submenu labeled Start with to convey the action that selecting an activity will take. This would be true of the submenu regardless of whether or not the entry represents a bundle, leaving us in a state where the only difference between bundles and instances is the phrasing used within the menu. Otherwise, they are functionally identical. This is not a bad idea. Again, if you are serious about this, we should prioritize it and do it, as a separate patch; and I'd be happy to work through the options with you, in a separate thread. Jameson ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Journal able to use open with for activity bundles
On Tue, Jun 10, 2008 at 4:43 PM, Jameson Chema Quinn [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 2:30 PM, Eben Eliason [EMAIL PROTECTED] wrote: Actually, I disagree with adding Start separately to the secondary palette as this will appear redundant beneath the already existing Start label in the primary palette. The better solution (and I think, the expected behavior) is to make the primary palette clickable when the palette is anchored, such that clicking it enacts the action of the button it is attached to. I agree that this is how palettes should work (of course, not the issue here). However, I don't understand your opposition to repeating the start option in the submenu. Any journal item already repeats the default option in this list; doing the same for activity bundles is only consistent. If we are going to change this, it is a separate patch. Could you please clarify exactly what it is you are trying to do, and exactly what parts of the GUI it's affecting? I've taken two stabs at this, and it seems neither are correct. I read the code, but I don't know what context it sits in. The secondary palettes that appear for activity icons (bundle or instance) all contain a Start or Resume option, respectively. The button in the toolbar of the detail view reads either Start or Resume, also as appropriate. None of the secondary palettes anywhere in the system repeat the default action of the button within the secondary palette, as far as I'm aware, as this would be redundant. (It would be even more redundant (in other words, functionally, instead of only visually) if the primary palette were clickable.) Regarding the other options, I think it would be clearer (albeit, admittedly, slightly more indirect) to place the list of available activities in a submenu labeled Start with to convey the action that selecting an activity will take. This would be true of the submenu regardless of whether or not the entry represents a bundle, leaving us in a state where the only difference between bundles and instances is the phrasing used within the menu. Otherwise, they are functionally identical. This is not a bad idea. Again, if you are serious about this, we should prioritize it and do it, as a separate patch; and I'd be happy to work through the options with you, in a separate thread. Indeed. I wasn't suggesting it should happen here, but I wanted to clarify my view of what these buttons and menus should look like, ideally. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Journal able to use open with for activity bundles
Sorry, I am stuck in windows land today, so I cannot confirm anything. I will respond based on how I recall things, and I'm pretty sure, but cannot vouch 100% for what I will say here. On Tue, Jun 10, 2008 at 3:02 PM, Eben Eliason [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 4:43 PM, Jameson Chema Quinn [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 2:30 PM, Eben Eliason [EMAIL PROTECTED] wrote: Actually, I disagree with adding Start separately to the secondary palette as this will appear redundant beneath the already existing Start label in the primary palette. The better solution (and I think, the expected behavior) is to make the primary palette clickable when the palette is anchored, such that clicking it enacts the action of the button it is attached to. I agree that this is how palettes should work (of course, not the issue here). However, I don't understand your opposition to repeating the start option in the submenu. Any journal item already repeats the default option in this list; doing the same for activity bundles is only consistent. If we are going to change this, it is a separate patch. Could you please clarify exactly what it is you are trying to do, and exactly what parts of the GUI it's affecting? I've taken two stabs at this, and it seems neither are correct. I read the code, but I don't know what context it sits in. The secondary palettes that appear for activity icons (bundle or instance) all contain a Start or Resume option, respectively. The button in the toolbar of the detail view reads either Start or Resume, also as appropriate. None of the secondary palettes anywhere in the system repeat the default action of the button within the secondary palette, as far as I'm aware, as this would be redundant. (It would be even more redundant (in other words, functionally, instead of only visually) if the primary palette were clickable.) This patch is for the secondary palette on the start/resume button on the details view. Say you have a picture you made in Paint. You'd have an arrow button in details, primary palette resume (= Paint), secondary palette Paint or TuxPaint. This is not verbally redundant, but is obviously redundant in the sense that one of the options in the secondary palette is equivalent to the simple button push. It is this redundancy that I was copying, as my feelings were that inconsistency would be confusing, and that intuitive accessibility is a higher priority than non-redundancy. If you disagree, I am not really attached to this idea. I just didn't realize it was controversial (and clung to that blind-spot even when it meant assuming you misunderstood). I'd vote for redundancy, but it is a weak vote. (BTW: again, I have no way to test this right now, but I think that the journal list view item palettes are also redundant. Don't the secondary palettes have options for run, copy, delete? And run is the same as just clicking the object's icon? BTBTW: This is actually a place where a nested open with menu makes even more sense, and I could write such a patch if this one clears.) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Journal able to use open with for activity bundles
On Tue, Jun 10, 2008 at 6:01 PM, Jameson Chema Quinn [EMAIL PROTECTED] wrote: Sorry, I am stuck in windows land today, so I cannot confirm anything. I will respond based on how I recall things, and I'm pretty sure, but cannot vouch 100% for what I will say here. On Tue, Jun 10, 2008 at 3:02 PM, Eben Eliason [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 4:43 PM, Jameson Chema Quinn [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 2:30 PM, Eben Eliason [EMAIL PROTECTED] wrote: Actually, I disagree with adding Start separately to the secondary palette as this will appear redundant beneath the already existing Start label in the primary palette. The better solution (and I think, the expected behavior) is to make the primary palette clickable when the palette is anchored, such that clicking it enacts the action of the button it is attached to. I agree that this is how palettes should work (of course, not the issue here). However, I don't understand your opposition to repeating the start option in the submenu. Any journal item already repeats the default option in this list; doing the same for activity bundles is only consistent. If we are going to change this, it is a separate patch. Could you please clarify exactly what it is you are trying to do, and exactly what parts of the GUI it's affecting? I've taken two stabs at this, and it seems neither are correct. I read the code, but I don't know what context it sits in. The secondary palettes that appear for activity icons (bundle or instance) all contain a Start or Resume option, respectively. The button in the toolbar of the detail view reads either Start or Resume, also as appropriate. None of the secondary palettes anywhere in the system repeat the default action of the button within the secondary palette, as far as I'm aware, as this would be redundant. (It would be even more redundant (in other words, functionally, instead of only visually) if the primary palette were clickable.) This patch is for the secondary palette on the start/resume button on the details view. Say you have a picture you made in Paint. You'd have an arrow button in details, primary palette resume (= Paint), secondary palette Paint or TuxPaint. This is not verbally redundant, but is obviously redundant in the sense that one of the options in the secondary palette is equivalent to the simple button push. It is this redundancy that I was copying, as my feelings were that inconsistency would be confusing, and that intuitive accessibility is a higher priority than non-redundancy. If you disagree, I am not really attached to this idea. I just didn't realize it was controversial (and clung to that blind-spot even when it meant assuming you misunderstood). I'd vote for redundancy, but it is a weak vote. I see. Well I think I vote against it in the current implementation, actually, since the redundancy (side by side, no less) could actually be confusing (which one do I want!? what's the difference!?). My first instinct was to think that it might be OK if we used a submenu, to clarify the action more as I mentioned before. After considering this, however, I find that it's actually much clearer /not/ to do that. The reason that Paint is repeated (as per your example) is that the Paint instance can be resumed by Paint, or other supporting activities. Including Paint itself in the list provides clarification of the action by revealing the name of the default activity, which otherwise wasn't revealed. We could take a hint from Apple and append (default) to the first in the list, with a separator, to make this more evident. On the other hand, an activity bundle (not an instance) can be started, or resumed by another supporting activity. Opening the bundle as an object with another activity is actually a very different action from starting a new instance of it. The former creates a new version of the bundle in the same thread. The latter creates a new instance/entry in the Journal in it's own brand new thread. I think we should do without the redundant Start option in the menu. I think this is still consistent with the other entries: You either create a new instance of the activity, or you open the bundle (as an object) with some other activity. You don't in general open the bundle (as an object) with itself (eg. you start a new painting...you don't open the paint bundle in Paint). The exception to the rule is an activity like Develop, which can indeed open itself. However, that will be handled naturally by the system, since Develop claims to handle the bundle type already. This is still very different from saying Start, which would create an /emtpy/ develop project; it would instead open up to reveal the source code /for/ Develop. Make sense? - Eben (BTW: again, I have no way to test this right now, but I think that the journal list view item palettes are also redundant. Don't the secondary
Re: [sugar] [PATCH] Journal able to use open with for activity bundles
On Tue, Jun 10, 2008 at 4:28 PM, Eben Eliason [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 6:01 PM, Jameson Chema Quinn [EMAIL PROTECTED] wrote: Sorry, I am stuck in windows land today, so I cannot confirm anything. I will respond based on how I recall things, and I'm pretty sure, but cannot vouch 100% for what I will say here. On Tue, Jun 10, 2008 at 3:02 PM, Eben Eliason [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 4:43 PM, Jameson Chema Quinn [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 2:30 PM, Eben Eliason [EMAIL PROTECTED] wrote: Actually, I disagree with adding Start separately to the secondary palette as this will appear redundant beneath the already existing Start label in the primary palette. The better solution (and I think, the expected behavior) is to make the primary palette clickable when the palette is anchored, such that clicking it enacts the action of the button it is attached to. I agree that this is how palettes should work (of course, not the issue here). However, I don't understand your opposition to repeating the start option in the submenu. Any journal item already repeats the default option in this list; doing the same for activity bundles is only consistent. If we are going to change this, it is a separate patch. Could you please clarify exactly what it is you are trying to do, and exactly what parts of the GUI it's affecting? I've taken two stabs at this, and it seems neither are correct. I read the code, but I don't know what context it sits in. The secondary palettes that appear for activity icons (bundle or instance) all contain a Start or Resume option, respectively. The button in the toolbar of the detail view reads either Start or Resume, also as appropriate. None of the secondary palettes anywhere in the system repeat the default action of the button within the secondary palette, as far as I'm aware, as this would be redundant. (It would be even more redundant (in other words, functionally, instead of only visually) if the primary palette were clickable.) This patch is for the secondary palette on the start/resume button on the details view. Say you have a picture you made in Paint. You'd have an arrow button in details, primary palette resume (= Paint), secondary palette Paint or TuxPaint. This is not verbally redundant, but is obviously redundant in the sense that one of the options in the secondary palette is equivalent to the simple button push. It is this redundancy that I was copying, as my feelings were that inconsistency would be confusing, and that intuitive accessibility is a higher priority than non-redundancy. If you disagree, I am not really attached to this idea. I just didn't realize it was controversial (and clung to that blind-spot even when it meant assuming you misunderstood). I'd vote for redundancy, but it is a weak vote. I see. Well I think I vote against it in the current implementation, actually, since the redundancy (side by side, no less) could actually be confusing (which one do I want!? what's the difference!?). My first instinct was to think that it might be OK if we used a submenu, to clarify the action more as I mentioned before. After considering this, however, I find that it's actually much clearer /not/ to do that. The reason that Paint is repeated (as per your example) is that the Paint instance can be resumed by Paint, or other supporting activities. Including Paint itself in the list provides clarification of the action by revealing the name of the default activity, which otherwise wasn't revealed. We could take a hint from Apple and append (default) to the first in the list, with a separator, to make this more evident. On the other hand, an activity bundle (not an instance) can be started, or resumed by another supporting activity. Opening the bundle as an object with another activity is actually a very different action from starting a new instance of it. The former creates a new version of the bundle in the same thread. The latter creates a new instance/entry in the Journal in it's own brand new thread. I think we should do without the redundant Start option in the menu. I think this is still consistent with the other entries: You either create a new instance of the activity, or you open the bundle (as an object) with some other activity. You don't in general open the bundle (as an object) with itself (eg. you start a new painting...you don't open the paint bundle in Paint). The exception to the rule is an activity like Develop, which can indeed open itself. However, that will be handled naturally by the system, since Develop claims to handle the bundle type already. This is still very different from saying Start, which would create an /emtpy/ develop project; it would instead open up to reveal the source code /for/
Re: [sugar] [PATCH] Journal able to use open with for activity bundles
On Tue, Jun 10, 2008 at 7:20 PM, Jameson Chema Quinn [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 4:28 PM, Eben Eliason [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 6:01 PM, Jameson Chema Quinn [EMAIL PROTECTED] wrote: Sorry, I am stuck in windows land today, so I cannot confirm anything. I will respond based on how I recall things, and I'm pretty sure, but cannot vouch 100% for what I will say here. On Tue, Jun 10, 2008 at 3:02 PM, Eben Eliason [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 4:43 PM, Jameson Chema Quinn [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 2:30 PM, Eben Eliason [EMAIL PROTECTED] wrote: Actually, I disagree with adding Start separately to the secondary palette as this will appear redundant beneath the already existing Start label in the primary palette. The better solution (and I think, the expected behavior) is to make the primary palette clickable when the palette is anchored, such that clicking it enacts the action of the button it is attached to. I agree that this is how palettes should work (of course, not the issue here). However, I don't understand your opposition to repeating the start option in the submenu. Any journal item already repeats the default option in this list; doing the same for activity bundles is only consistent. If we are going to change this, it is a separate patch. Could you please clarify exactly what it is you are trying to do, and exactly what parts of the GUI it's affecting? I've taken two stabs at this, and it seems neither are correct. I read the code, but I don't know what context it sits in. The secondary palettes that appear for activity icons (bundle or instance) all contain a Start or Resume option, respectively. The button in the toolbar of the detail view reads either Start or Resume, also as appropriate. None of the secondary palettes anywhere in the system repeat the default action of the button within the secondary palette, as far as I'm aware, as this would be redundant. (It would be even more redundant (in other words, functionally, instead of only visually) if the primary palette were clickable.) This patch is for the secondary palette on the start/resume button on the details view. Say you have a picture you made in Paint. You'd have an arrow button in details, primary palette resume (= Paint), secondary palette Paint or TuxPaint. This is not verbally redundant, but is obviously redundant in the sense that one of the options in the secondary palette is equivalent to the simple button push. It is this redundancy that I was copying, as my feelings were that inconsistency would be confusing, and that intuitive accessibility is a higher priority than non-redundancy. If you disagree, I am not really attached to this idea. I just didn't realize it was controversial (and clung to that blind-spot even when it meant assuming you misunderstood). I'd vote for redundancy, but it is a weak vote. I see. Well I think I vote against it in the current implementation, actually, since the redundancy (side by side, no less) could actually be confusing (which one do I want!? what's the difference!?). My first instinct was to think that it might be OK if we used a submenu, to clarify the action more as I mentioned before. After considering this, however, I find that it's actually much clearer /not/ to do that. The reason that Paint is repeated (as per your example) is that the Paint instance can be resumed by Paint, or other supporting activities. Including Paint itself in the list provides clarification of the action by revealing the name of the default activity, which otherwise wasn't revealed. We could take a hint from Apple and append (default) to the first in the list, with a separator, to make this more evident. On the other hand, an activity bundle (not an instance) can be started, or resumed by another supporting activity. Opening the bundle as an object with another activity is actually a very different action from starting a new instance of it. The former creates a new version of the bundle in the same thread. The latter creates a new instance/entry in the Journal in it's own brand new thread. I think we should do without the redundant Start option in the menu. I think this is still consistent with the other entries: You either create a new instance of the activity, or you open the bundle (as an object) with some other activity. You don't in general open the bundle (as an object) with itself (eg. you start a new painting...you don't open the paint bundle in Paint). The exception to the rule is an activity like Develop, which can indeed open itself. However, that will be handled naturally by the system, since Develop claims to handle the bundle type already. This is still very different from saying Start, which
Re: [sugar] frame activation
On 10 Jun 2008, at 11:15, Tomeu Vizoso wrote: do we have any feedback regarding frame activation and the new control panel option? Is it ok to ship with hot corners on by default and let the users change it if they wish? Have settled for about 500ms for the corners. I found warm edges too obtrusive even with a max delay, specifically scroll bar interaction was the main false activation. I could see me enabling specific warm edges (top being most useful). OT: Also trying to keep in the back of my mind a possible future UI metaphor where the whole input may be touch screen based, but as a well known tech put it recently, most existing UI's with a touch input layer added are like lipstick on a pig. It'll need to be an extensive redesign at that stage (sorry Eben). I guess Apple with their UI fork have more than a clue for us here. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
