[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] Preparing for the feature freeze
So I was probably wrong to bring up the Record bug in this thread. However, the Browse bugs seem to be related to unsupported features in the browser--e.g., the need for some daughter windows to appear. Feature or bug--not obvious. -walter On Tue, Jun 3, 2008 at 1:29 PM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > On Tue, Jun 3, 2008 at 7:20 PM, Erik Garrison <[EMAIL PROTECTED]> wrote: >> On Tue, Jun 03, 2008 at 11:03:44AM +0200, Marco Pesenti Gritti wrote: >>> The feature (and strings) freeze is approaching very quickly. We have >>> 17 days left. Can we make a quick list of things that we need to get >>> in by the 20 June? >>> >> >> This is a feature freeze, not a bugfix/patch freeze, correct? > > Correct. > > 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] control panel review
Hi Tomeu,
thanks very much for your detailed review - it was very useful! I am fine with
most
of your comments and changed the code accordingly. I made inline comments for
the
items.
So I would re-base my changes on latest HEAD now and push if you are ok?
Thanks,
Simon
Tomeu Vizoso wrote:
> Hi,
>
> yesterday had a bunch of hours in the train, so decided to give a look
> to Simon's work on the control panel. I think he has done a great work
> and would love to see it ASAP on the builds.
>
> Please take in account that most of the comments are style nitpicks of
> me that other people may not share.
>
> cmd.py
>
> '''Print the help to the screen'''
> s/the/
>
> print _('To apply your changes you have to restart sugar.\n' +
> 'Hit ctrl+alt+erase on the keyboard to trigger a restart.')
> Should we tell to close first the activities so no data is lost?
Hmmm not sure I would like to handle this with session-management which we will
have seen i hope.
> names = os.listdir(os.path.join(config.shell_path, '/'.join(subpath)))
> s/names/file_names
>
> modules = []
> for name in names:
> s/name/file_name
>
> if name.endswith('.py') and name != '__init__.py':
> tmp = name.strip('.py')
> s/tmp/module_name
>
> mod = __import__('.'.join(subpath) + '.' +
> s/mod/module
>
Done.
> except getopt.GetoptError:
> cmd_help()
> sys.exit(2)
>
> if not opts:
> cmd_help()
> sys.exit()
> Why exit(2) and exit()? Shouldn't be the same exit code?
Made it the same exit code. From the docs it says: "Unix programs generally use
2
for command line syntax errors and 1 for all other kind of errors." So 2 as
status
error code makes sense here.
> for opt, key in opts:
> s/opt/options, etc
Done.
> for module in modules:
> method = getattr(module, 'set_' + key, None)
> if method:
> print method.__doc__
> sys.exit()
> print _("sugar-control-panel: key=%s not an available option"
> % key)
> What if different modules have the same method?
Do we really have this issue? I think/hope we don't have more than one module
which
has for example the method set_color.
> if note == 'RESTART':
> Would be better a numeric constant?
Done.
> print _("sugar-control-panel: %s"
> % detail)
> May be easier to read in a single line?
yup done.
> gui.py
>
> _ = lambda msg: gettext.dgettext('sugar', msg)
> This is only needed in sugar-toolkit. In sugar it is already set.
Done.
> def _update_accept_focus(self):
> self.window.set_accept_focus(True)
> Do we need this method?
No we don't need it - removed.
> self._table.attach(gridwidget, column, column+1, row, row+1)
> Should be spaces around the + operator.
>
> if column == 5:
> Should 5 be a constant? _MAX_COLUMNS?
yes.
> if query in key or query in key.upper() \
> or query in key.capitalize():
> What about just if query.lower() in key.lower(): ?
+1
> class_pointer = self._options[option]['view']
> Not sure what class_pointer is, maybe view_constructor would be a better name?
named it view_class
> {'optionname': {'view', 'model', 'button', 'keywords', 'icon'} }
> In python, would be {'optionname': ['view', 'model', 'button',
> 'keywords', 'icon'] }
It is a dictionary options with the keys 'optionname' which has the keys 'view',
'model'...
>
> subpath = ['controlpanel', 'view']
> names = os.listdir(os.path.join(config.shell_path,
> '/'.join(subpath)))
> for name in names:
> What about:
> modules_path = os.path.join(config.shell_path, 'controlpanel', 'view')
> for file_name in os.listdir(modules_path):
I use the subpath in another call again so I left it like that.
> class_pointer = getattr(mod, tmp[0].capitalize()
> + tmp[1:], None)
> Can we depend on this algorithm to determine the name of the class inside the
> module? Isn't any other option clearer and more safe?
I made the class-name another constant and added logging for failures.
> if tmp in self._options:
> This means we cannot have one section just with command line support?
Oh we can have one section just with command line support. You do so by
providing
only the module and not the view class.
> def __accept_clicked_cb(self, widget, data=None):
> data=None is not needed.
+1
> alert.add_button(gtk.RESPONSE_CANCEL, _('Cancel'), cancel_icon)
> Would make sense to display the string 'Cancel changes' instead? At first I
> thought it meant 'Cancel restart'.
Sounds good.
> def __select_option_cb(self, button, event, option=None):
> Can option be ever None?
Yup took that out.
> def __st
Re: [sugar] Preparing for the feature freeze
Guillaume Desmottes wrote:
> Search queries will return a {Buddy,Activity}View object. This object
> will have a Get{Buddies,Activities} method to retrieve the result of the
> search, a "Changed" (or Added/Removed) signal to track changes and a
> Closed method when user is not interested anymore by the result of the
> search.
>
> Does it make sense to you? Suggestions are welcome.
> I'll update http://wiki.laptop.org/go/Presence_Service_D-Bus_API with my
> changes.
>
I would suggest not returning objects on any of the dbus calls; this
makes it harder to go through and debug the code both in the presence
service and telepathy. We should try to keep it as simple as possible
wrt the messages that are exchanged between the presence service and
telepathy. The presence service currently offers a nice abstraction of
how telepathy works, but this abstraction is hindered by the fact the
the presence service returns telepathy objects.
p.
--
Polychronis Ypodimatopoulos
Graduate student
Viral Communications
MIT Media Lab
Tel: +1 (617) 459-6058
http://www.mit.edu/~ypod/
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
It is proving hard for me to get consensus on the new bundle format, but I hope that I can do so soon enough to get some forward-compatibility patches in. Right now, I think that that would be: allow tar as well as zip bundles (though zip bundles would remain the norm for now) allow multiple installed versions of a bundle (activity registry by hash, version, and key/thread/bundle id) metadata to associate journal entries with correct version of bundle. (The signature stuff may or may not be ready to include in this list, but is not as urgent for forward-compatibility purposes.) On Tue, Jun 3, 2008 at 11:29 AM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > On Tue, Jun 3, 2008 at 7:20 PM, Erik Garrison <[EMAIL PROTECTED]> > wrote: > > On Tue, Jun 03, 2008 at 11:03:44AM +0200, Marco Pesenti Gritti wrote: > >> The feature (and strings) freeze is approaching very quickly. We have > >> 17 days left. Can we make a quick list of things that we need to get > >> in by the 20 June? > >> > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] wiki navigation
> * 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
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 7:20 PM, Erik Garrison <[EMAIL PROTECTED]> wrote: > On Tue, Jun 03, 2008 at 11:03:44AM +0200, Marco Pesenti Gritti wrote: >> The feature (and strings) freeze is approaching very quickly. We have >> 17 days left. Can we make a quick list of things that we need to get >> in by the 20 June? >> > > This is a feature freeze, not a bugfix/patch freeze, correct? Correct. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 03, 2008 at 11:03:44AM +0200, Marco Pesenti Gritti wrote: > The feature (and strings) freeze is approaching very quickly. We have > 17 days left. Can we make a quick list of things that we need to get > in by the 20 June? > This is a feature freeze, not a bugfix/patch freeze, correct? Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 03, 2008 at 01:53:37PM +0200, Tomeu Vizoso wrote: > On Tue, Jun 3, 2008 at 1:50 PM, Walter Bender <[EMAIL PROTECTED]> wrote: > > Alas, two more open bugs that should be considered by someone: > > > > (1) Record has been broken in Joyride for quite some time: ever since > > the introduction of compositing? (#6850) I am looking into this. > > Joyride has no composite enabled, so this seems to be something different. > According to xdpyinfo the Composite extension is enabled on joyride 1998. So if this is different it is different in a way that xdpyinfo does not know. On 1998 I get the following messages to the virtual terminal (I assume they are delivered via printk): cafe1000-ccic :00:0c.2: Frame overrun on 1, frames lost ... <59 printk messages suppressed> ... Any ideas? Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Software Status Meeting Tomorrow @ 1600 EDT, 2000 UTC in #olpc-meeting on freenode
On Tue, Jun 3, 2008 at 6:09 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > Martin Langhoff, our esteemed school-server architect asked us if we > could wake him up at 6:00 AM (in NZ) instead of 4:00 (AM). Can we > oblige? > > Please note the new times: > > 4:00 PM EST, 2000 UTC. > > I expect that we'll spend the bulk of our time discussing work toward > 8.2.0, a.k.a. the August Release. I'll try to make it but I'm not sure I'll manage to :( 10 pm is not best for me... Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] sugar on olpc3-16
Hi, for those people who need to work on something closer than f7 to what will ship in august (performance, xulrunner, X, etc), Blaketh gave this tip on #sugar: unmadindu, you can also copy the olpc-blah from /etc/pam.d/ on a working f7 laptop to the f9 laptop, then olpc-dm will work. http://pilgrim.laptop.org/~pilgrim/olpc/streams/olpc3/build16/devel_jffs2/ Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Software Status Meeting Tomorrow @ 1600 EDT, 2000 UTC in #olpc-meeting on freenode
Martin Langhoff, our esteemed school-server architect asked us if we could wake him up at 6:00 AM (in NZ) instead of 4:00 (AM). Can we oblige? Please note the new times: 4:00 PM EST, 2000 UTC. I expect that we'll spend the bulk of our time discussing work toward 8.2.0, a.k.a. the August Release. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Browse: Make the object chooser transient on the activity window
r+ Tomeu Vizoso wrote: > > > > ___ > 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] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 10:47 AM, Eben Eliason <[EMAIL PROTECTED]> wrote: > On a more interesting note, it would be really fantastic to store some > additional metadata in addition to the URL for future use. (See > wiki.laptop.org/go/Browse). For instance, it would be nice to, map Sorry. More specifically, see: wiki.laptop.org/go/Browse#Screenshots - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 5:20 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > On Tue, Jun 3, 2008 at 11:03 AM, Marco Pesenti Gritti > <[EMAIL PROTECTED]> wrote: >> The feature (and strings) freeze is approaching very quickly. We have >> 17 days left. Can we make a quick list of things that we need to get >> in by the 20 June? >> >> Let me start it. Priorities goes from 0 to 5. >> >> * Control panel (almost ready) - priority 5 >> * New startup notification (has patch, has consensus?, needs to clean >> it up) - priority 4 >> * Session. Can either create a sugar-session based on gnome-session or >> come up with something minimal. I tend to prefer the first option at >> the moment even if it will provide us some unneeded features. - >> priority 4 >> * Browser bookmarks and autocompletion. - priority 3 > > I agree with all that. Do we have clear what needs to be done in the > last item? Eben, do you know? Well, we can introduce this in a relatively straightforward manner that has almost no additional UI up front. Anytime a bookmark is created in a session (by anyone in it, not just me), we would need to log this into a database stored in the "shared" space for all Browse instances. We should also log all pages visited (the history) here as well. The only additional UI in the short term would be a special palette of sorts attached to the URL entry which provides autocompletion suggestions in all Browse instances. On a more interesting note, it would be really fantastic to store some additional metadata in addition to the URL for future use. (See wiki.laptop.org/go/Browse). For instance, it would be nice to, map the page titles, in some probabilistic fashion, to their URLs so that kids can type in "One laptop" and get suggestions for "laptop.org/..." (I'm not sure how feasible this is, but the thought is to keep the autocompletion in sync with the idea of representing pages by their titles, instead of their URLs, most of the time). The design also calls for some basic info like: timestamp of the bookmark/page visit; type of visit (entered URL manually, followed a link, performed a search, etc); preview thumbnail; bookmarker's identity; etc. All of these pieces of info will later be used for creating a rich memory-based bookmark/history browser. (And, as you can see, even ties into the mockups of the URL completion palette.) > * In-page search in Browse. This should probably be implemented within an Edit toolbar (which should be added...copy/paste are also good to have here). I replied to a message on the lists, which included a patch from a volunteer, regarding some additional changes to browse. The changes offered were fairly sane, and worth adding, and my enhancements to them I feel would provide some really nice benefits at relatively low cost as well. Could one of you familiar with Browse locate and look over those patches and my suggested modifications? (It was titled "Patch to make browse annoy me less".) - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] Browse: Make the object chooser transient on the activity window
From c6cbdc383e40eb82c7b0edf87d23e0f908ec5a52 Mon Sep 17 00:00:00 2001 From: Tomeu Vizoso <[EMAIL PROTECTED]> Date: Tue, 3 Jun 2008 16:27:05 +0200 Subject: [PATCH] Make the object chooser transient on the activity window. --- filepicker.py | 14 +++--- webactivity.py |2 ++ 2 files changed, 13 insertions(+), 3 deletions(-) diff --git a/filepicker.py b/filepicker.py index 0b7cb59..fe9fec5 100644 --- a/filepicker.py +++ b/filepicker.py @@ -29,6 +29,7 @@ from xpcom.server.factory import Factory from sugar.graphics.objectchooser import ObjectChooser _temp_files_to_clean = [] +_browser_window = None def cleanup_temp_files(): for temp_file in _temp_files_to_clean: @@ -55,20 +56,23 @@ class FilePicker: def init(self, parent, title, mode): self._title = title self._file = None + """ +Would be nice to get the window xid with something like this, but +couldn't find how. + cls = components.classes['@mozilla.org/embedcomp/window-watcher;1'] window_watcher = cls.getService(interfaces.nsIWindowWatcher) chrome = window_watcher.getChromeForWindow(parent) self._parent = chrome.web_view.get_toplevel() """ -self._parent = None +self._parent = _browser_window if mode != interfaces.nsIFilePicker.modeOpen: raise xpcom.COMException(NS_ERROR_NOT_IMPLEMENTED) def show(self): -chooser = ObjectChooser(self._title, self._parent, -gtk.DIALOG_MODAL | gtk.DIALOG_DESTROY_WITH_PARENT) +chooser = ObjectChooser(parent=self._parent) try: result = chooser.run() if result == gtk.RESPONSE_ACCEPT: @@ -145,3 +149,7 @@ components.registrar.registerFactory(FilePicker.cid, '@mozilla.org/filepicker;1', Factory(FilePicker)) +def init(main_window): +global _browser_window +_browser_window = main_window.get_toplevel() + diff --git a/webactivity.py b/webactivity.py index c057735..4b4544a 100755 --- a/webactivity.py +++ b/webactivity.py @@ -70,6 +70,7 @@ from viewtoolbar import ViewToolbar import downloadmanager import sessionhistory import progresslistener +import filepicker _LIBRARY_PATH = '/usr/share/library-common/index.html' @@ -98,6 +99,7 @@ class WebActivity(activity.Activity): downloadmanager.init(self._browser, self, temp_path) sessionhistory.init(self._browser) progresslistener.init(self._browser) +filepicker.init(self) toolbox = activity.ActivityToolbox(self) -- 1.5.2.5 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 6:29 AM, Guillaume Desmottes <[EMAIL PROTECTED]> wrote: > Le mardi 03 juin 2008 à 12:11 +0200, Marco Pesenti Gritti a écrit : >> On Tue, Jun 3, 2008 at 11:59 AM, Morgan Collett >> What happens if we land only the backend without the search features? >> Do we only see a random number of buddies? > > Yes, if sugar request these buddies (shouldn't be more complicated than > a D-Bus method call on PS). > > I think that's a good idea to focus on random queries for now as it > doesn't require new UI and sugar changes should be pretty simple. > > That's not a new feature from user pov but could allow us to deploy a > public jabber server without the shared roster hack and see how it > scales. > > >> How does it work from the UI code perspective? We set a filter and >> buddies which doesn't match the search disappear (as if they have had >> left)? > > Don't know. I'm not a GUI expert, we are open to any suggestion. > The vision for the neighborhood has always been to have a more dynamic, animated environment. Up front we were told /not/ to expect to have scaling, but that translation of sprites from point A to point B should be doable. The neighborhood view will, quite literally, come to life when we add that, and it's also a crucial element of the scalability/filter UI. The answer to the above question, of course, is that they "disappear" because otherwise we're not doing ourselves any benefit regarding the display of information. The full answer is that non-matching objects should slide off-screen, while new matches slide on, maintaining a spacial relationship as though the were all in a plane which extends well beyond the screen boundaries. Without this, the spacial metaphors will be lost, and it won't be clear what's happening when searches are entered and cleared. If we can add some more smarts to the layout, we might not even need some "limit" on the number of items we show; if instead we can manage to create a layout in polar coordinates where r corresponds to the relevance of the object with respect to the search (degree of match) and theta is used to give us some wiggle room for preventing collisions, then we might treat it as a single large space, with or without scrolling capabilities. I'd leave this exercise to future experimentation, of course. The previous concept is what I've had in mind. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 4:14 PM, Eben Eliason <[EMAIL PROTECTED]> wrote: > On Tue, Jun 3, 2008 at 5:26 AM, Marco Pesenti Gritti <[EMAIL PROTECTED]> > wrote: >> On Tue, Jun 3, 2008 at 11:20 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: >>> * Improve the object chooser: >>> http://wiki.laptop.org/go/Designs/Object_Chooser >> >> Priority 3. > > I think this is much higher on the list. My understanding is that the > current version is non-functional, due to the recent Journal > enhancements. This makes this a regression, and something that needs > to be fixed regardless of the design enhancements. > > Priority 5. Unless the functional enhancements are somewhat coped with the fixes, I'd say this should stay priority 3 as a feature. But should obviously be a blocker bug for post feature freeze. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 5:26 AM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > On Tue, Jun 3, 2008 at 11:20 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: >> * Improve the object chooser: >> http://wiki.laptop.org/go/Designs/Object_Chooser > > Priority 3. I think this is much higher on the list. My understanding is that the current version is non-functional, due to the recent Journal enhancements. This makes this a regression, and something that needs to be fixed regardless of the design enhancements. Priority 5. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] Fixing timestamp issue on wnck.Window.activate()
Hello all, I noticed that all calls to wnck.Window.activate() are passed "1" as a timestamp, along with the following comment in sugar/src/view/ActivityHost.py # wnck.Window.activate() expects a timestamp, but we don't # always have one, and libwnck will complain if we pass "0", # and matchbox doesn't look at the timestamp anyway. So we # just always pass "1". It looks like metacity actually looks at the timestamp, and it was the cause behind the activity switching not working (as mentioned in my earlier mail). libwnck/test-wnck.c suggests that gtk_get_current_event_time () should be used to send the timestamp, with the following comment /* This should only be called in reaction to user button * presses or key presses (I hope), so * gtk_get_current_event_time() should be okay here. */ I have attached the patch with this mail. Ok to commit this ? Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] sugar_wnck_activate_timestamp.patch Description: Binary data ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Gadget's feature integration in Sugar
On Tue, Jun 3, 2008 at 1:52 PM, Martin Dengler <[EMAIL PROTECTED]> wrote: > > 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?)? This is up to Eben, but a preference doesn't make a lot of sense to me here, as long as we have a fixed size view. You can only fit a certain number of items in it, assuming it's correctly calculated I see no reason for the user to want to tweak it. Unfortunately I'm now thinking that we might not be able to calculate a limit, because it depends on the number of activities, buddies and buddies per activity and hence it keeps changing. Another possible approach is to set an arbitrary (configurable?) limit of buddies/activities related to network scalability and make the mesh view scrollable (a la google maps). Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
Le mardi 03 juin 2008 à 12:34 +0200, Marco Pesenti Gritti a écrit :
> > For now I'm focusing on PS API. If someone wants to work on the GUI side
> > when they are done that would be great.
>
> What kind of API are you planning for the PS? Trying to understand how
> much work it will be to hook it up into the UI.
Probably something similar than the Gabble one. See
http://people.collabora.co.uk/~cassidy/spec-olpc-gadget.html#org.laptop.Telepathy.Gadget
Search queries will return a {Buddy,Activity}View object. This object
will have a Get{Buddies,Activities} method to retrieve the result of the
search, a "Changed" (or Added/Removed) signal to track changes and a
Closed method when user is not interested anymore by the result of the
search.
Does it make sense to you? Suggestions are welcome.
I'll update http://wiki.laptop.org/go/Presence_Service_D-Bus_API with my
changes.
G.
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
It is definitely tied to something that is different between the Joyride and the update.1 streams. It still works in 703... -walter On Tue, Jun 3, 2008 at 7:53 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > On Tue, Jun 3, 2008 at 1:50 PM, Walter Bender <[EMAIL PROTECTED]> wrote: >> Alas, two more open bugs that should be considered by someone: >> >> (1) Record has been broken in Joyride for quite some time: ever since >> the introduction of compositing? (#6850) > > Joyride has no composite enabled, so this seems to be something different. > > Tomeu > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 1:50 PM, Walter Bender <[EMAIL PROTECTED]> wrote: > Alas, two more open bugs that should be considered by someone: > > (1) Record has been broken in Joyride for quite some time: ever since > the introduction of compositing? (#6850) Joyride has no composite enabled, so this seems to be something different. Tomeu ___ 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] Preparing for the feature freeze
Alas, two more open bugs that should be considered by someone: (1) Record has been broken in Joyride for quite some time: ever since the introduction of compositing? (#6850) (2) Browse has some issues that are important to Uruguay (#6825, 6826, #7078) -walter ___ 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] Moving to metacity with composition (was: Preparing for the feature freeze)
On Tue, Jun 3, 2008 at 12:23 PM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > On Tue, Jun 3, 2008 at 12:16 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: >> On Tue, Jun 3, 2008 at 11:54 AM, Marco Pesenti Gritti >> <[EMAIL PROTECTED]> wrote: >>> On Tue, Jun 3, 2008 at 11:45 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: >> activate composition (eToys and >> Record have trouble with this). > > Priority 1. Can we actually do this given the memory constraints? We'll be saving 3.5MB per python activity with the prefork trick, and in the worst case we would be having a penalty of 2MB per fullscreen window because of composition. >>> >>> Bernando was saying that this is not possible because of *video* >>> memory constraints. >> >> Hmm, but not all those pixmaps will be kept in video mem, right? If >> so, then I don't get why the faster builds work so fine. > > What I understood from Bernardo is that they needs to be in video mem. > If you open several windows in faster and try to rotate the screen, > does it work? Quite well. Just tried with Journal, Terminal, Browse, Write and Chat and queued several rotates without any crash. X took a bit of memory during the rotate, but was released when the operation finished. 70MB free. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 12:29 PM, Guillaume Desmottes <[EMAIL PROTECTED]> wrote: >> What happens if we land only the backend without the search features? >> Do we only see a random number of buddies? > > Yes, if sugar request these buddies (shouldn't be more complicated than > a D-Bus method call on PS). > > I think that's a good idea to focus on random queries for now as it > doesn't require new UI and sugar changes should be pretty simple. > > That's not a new feature from user pov but could allow us to deploy a > public jabber server without the shared roster hack and see how it > scales. True. We could probably land the sugar changes even after the freeze. It would be good the bulk of the work before though (gadget, gabble, ps, sugar-toolkit). >> Is Collabora planning to do the UI side of it? >> > > For now I'm focusing on PS API. If someone wants to work on the GUI side > when they are done that would be great. What kind of API are you planning for the PS? Trying to understand how much work it will be to hook it up into the UI. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
Le mardi 03 juin 2008 à 12:11 +0200, Marco Pesenti Gritti a écrit : > On Tue, Jun 3, 2008 at 11:59 AM, Morgan Collett > <[EMAIL PROTECTED]> wrote: > > Gadget is a server side component for the jabber server that will > > address the scalability issues by showing presence for only a subset > > of those on the server. It will therefore allow many more on the > > server at once. > > > > There will be PS and mesh view changes required - see Guillaume's > > recent mail(s) to [EMAIL PROTECTED] > > When is the backend planned to land? > Well, this involves work in a lot of modules: - the gadget component itself - telepathy-gabble: new API's for search/random and protocol to talk to Gadget - sugar-presence-service: new API's using Gabble's search features - sugar-toolkit: convenient wrapper for PS new API's - sugar: GUI to perform searches, etc Currently, most of the work has been done in Gadget and Gabble and I recently started PS changes. > What happens if we land only the backend without the search features? > Do we only see a random number of buddies? Yes, if sugar request these buddies (shouldn't be more complicated than a D-Bus method call on PS). I think that's a good idea to focus on random queries for now as it doesn't require new UI and sugar changes should be pretty simple. That's not a new feature from user pov but could allow us to deploy a public jabber server without the shared roster hack and see how it scales. > How does it work from the UI code perspective? We set a filter and > buddies which doesn't match the search disappear (as if they have had > left)? Don't know. I'm not a GUI expert, we are open to any suggestion. > Is Collabora planning to do the UI side of it? > For now I'm focusing on PS API. If someone wants to work on the GUI side when they are done that would be great. > Sorry, lots of questions :) np :) G. ___ 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 Tue, Jun 3, 2008 at 12:16 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > On Tue, Jun 3, 2008 at 11:54 AM, Marco Pesenti Gritti > <[EMAIL PROTECTED]> wrote: >> On Tue, Jun 3, 2008 at 11:45 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: Priority 2. I would love to have it but it might be too late, given that Sayamindu experimentation run into interesting problems. >>> >>> A nice thing about this is that little changes to sugar are expected >>> to be needed, so it's easy to swap-in swap-out, perhaps in a quick >>> 8.2.1 release? >> >> Well, if we go for the fullscreen hint approach, it will need changes >> to all the non-python activities, so it would be pretty invasive. > > Ouch, is that acceptable? What will happen when kids try to run an old > activity? Well, there is no official API freeze in effect yet. Old activities will get a window frame. Personally I think that's acceptable if using the fullscreen hint is considered the best semantic. We could also consider to use normal window + maximized. If someone could spend some time thinking about the possible approaches and to write them down (with advantages and disadvantages) that would be a good step forward. > activate composition (eToys and > Record have trouble with this). Priority 1. Can we actually do this given the memory constraints? >>> >>> We'll be saving 3.5MB per python activity with the prefork trick, and >>> in the worst case we would be having a penalty of 2MB per fullscreen >>> window because of composition. >> >> Bernando was saying that this is not possible because of *video* >> memory constraints. > > Hmm, but not all those pixmaps will be kept in video mem, right? If > so, then I don't get why the faster builds work so fine. What I understood from Bernardo is that they needs to be in video mem. If you open several windows in faster and try to rotate the screen, does it work? Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Moving to metacity with composition (was: Preparing for the feature freeze)
On Tue, Jun 3, 2008 at 11:54 AM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > On Tue, Jun 3, 2008 at 11:45 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: >>> Priority 2. I would love to have it but it might be too late, given >>> that Sayamindu experimentation run into interesting problems. >> >> A nice thing about this is that little changes to sugar are expected >> to be needed, so it's easy to swap-in swap-out, perhaps in a quick >> 8.2.1 release? > > Well, if we go for the fullscreen hint approach, it will need changes > to all the non-python activities, so it would be pretty invasive. Ouch, is that acceptable? What will happen when kids try to run an old activity? activate composition (eToys and Record have trouble with this). >>> >>> Priority 1. Can we actually do this given the memory constraints? >> >> We'll be saving 3.5MB per python activity with the prefork trick, and >> in the worst case we would be having a penalty of 2MB per fullscreen >> window because of composition. > > Bernando was saying that this is not possible because of *video* > memory constraints. Hmm, but not all those pixmaps will be kept in video mem, right? If so, then I don't get why the faster builds work so fine. Anyway, Martin Dengler did an awesome job measuring the mem hit in matchbox, so I guess we should reread it and maybe redo the tests with metacity: http://lists.laptop.org/pipermail/sugar/2008-March/004718.html 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? >> If we only keep the active activity >> composited, we could limit this to a total of 4MB with peaks of 6MB >> (desktop window + active activity + inactive activity while we take >> the screenshot). > > I would like to see a proof of concept of this approach. Me too ;) Just for the record, I'm not strongly advocating for composition in 8.2. I just happen to think that it could bring a lot of value and we should consider carefully if it's doable or not. Cheers, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 11:59 AM, Morgan Collett <[EMAIL PROTECTED]> wrote: > Gadget is a server side component for the jabber server that will > address the scalability issues by showing presence for only a subset > of those on the server. It will therefore allow many more on the > server at once. > > There will be PS and mesh view changes required - see Guillaume's > recent mail(s) to [EMAIL PROTECTED] When is the backend planned to land? What happens if we land only the backend without the search features? Do we only see a random number of buddies? How does it work from the UI code perspective? We set a filter and buddies which doesn't match the search disappear (as if they have had left)? Is Collabora planning to do the UI side of it? Sorry, lots of questions :) Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Gadget's feature integration in Sugar
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. > > Here is a list of few points that should be discussed about their sugar > integration. > > - We need GUI to perform buddy searches. Buddies can be searched using > their properties (color, key, jid). > > - We also need GUI to perform Activity searches. Activities can be > searched using their properties (color, name, type, tags) or their > participants (based on their jid). > > I guess these searches should be done directly from the mesh view. How > should we expose the different type of search in the GUI? I'm not sure it's necessary to differentiate the two in the UI. We chould just search for both and perhaps support some keyword in the query. > - 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. > Once a search is performed, user will automatically received change > notifications from the result of the search until the "search > result" (called "view" in Gadget) is closed. Do we want to allow users > to keep more than one search result a time? If yes, we need GUI to close > views. If not, I'll guess that each new search will close the previous > one. Maybe in a future UI revision... I wouldn't worry about it for now. > For privacy reasons, user can choose to not be indexed by gadget (so he > can't be found by other users). Do we want to expose this in the GUI? As > that's not a really common use case, I guess an option modifiable using > sugar-control-panel should be enough. Make sense. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 11:03 AM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > The feature (and strings) freeze is approaching very quickly. We have > 17 days left. Can we make a quick list of things that we need to get > in by the 20 June? > > Let me start it. Priorities goes from 0 to 5. > > * Control panel (almost ready) - priority 5 > * New startup notification (has patch, has consensus?, needs to clean > it up) - priority 4 > * Session. Can either create a sugar-session based on gnome-session or > come up with something minimal. I tend to prefer the first option at > the moment even if it will provide us some unneeded features. - > priority 4 > * Browser bookmarks and autocompletion. - priority 3 > > Please add stuff you know about. I can clean up and move to the wiki > when we are done. I'd like to land the private invite stuff for Chat invites from a non-Sugar jabber client. It's almost ready. Morgan ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 11:54 AM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > On Tue, Jun 3, 2008 at 11:45 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: * Presence scalability when using Jabber (gadget). >>> >>> Priority 2. >> >> Sure about this? Usefulness of presence is very limited without this. > > Did we actually reach the point where reliability of the network with > a high number of buddies/activities make this useful? What work is > involved to get this working? Gadget is a server side component for the jabber server that will address the scalability issues by showing presence for only a subset of those on the server. It will therefore allow many more on the server at once. There will be PS and mesh view changes required - see Guillaume's recent mail(s) to [EMAIL PROTECTED] While this is not related to reliability of simple mesh, it will definitely improve reliability of collaboration via jabber server on AP. Regards Morgan ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 11:45 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: >> Priority 2. I would love to have it but it might be too late, given >> that Sayamindu experimentation run into interesting problems. > > A nice thing about this is that little changes to sugar are expected > to be needed, so it's easy to swap-in swap-out, perhaps in a quick > 8.2.1 release? Well, if we go for the fullscreen hint approach, it will need changes to all the non-python activities, so it would be pretty invasive. >>> activate composition (eToys and >>> Record have trouble with this). >> >> Priority 1. Can we actually do this given the memory constraints? > > We'll be saving 3.5MB per python activity with the prefork trick, and > in the worst case we would be having a penalty of 2MB per fullscreen > window because of composition. Bernando was saying that this is not possible because of *video* memory constraints. > If we only keep the active activity > composited, we could limit this to a total of 4MB with peaks of 6MB > (desktop window + active activity + inactive activity while we take > the screenshot). I would like to see a proof of concept of this approach. > Doesn't sound too bad if the avoided rewrites give us > a smoother experience. > > Notifications on the lower corners look quite weird because of lack of > transparency, btw. > >>> * Presence scalability when using Jabber (gadget). >> >> Priority 2. > > Sure about this? Usefulness of presence is very limited without this. Did we actually reach the point where reliability of the network with a high number of buddies/activities make this useful? What work is involved to get this working? Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
Hello, On Tue, Jun 3, 2008 at 2:56 PM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > On Tue, Jun 3, 2008 at 11:20 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: >> Three more items I can think of: > > My take on the priorities. > >> * Switch from Matchbox to Metacity and > > Priority 2. I would love to have it but it might be too late, given > that Sayamindu experimentation run into interesting problems. > I agree with Marco on this. At the moment, I don't think Metacity gives us anything other than whatever is given (in terms of functionality) by Matchbox. The main reason for considering a switch to Metacity is, IIRC, seamless running of stock desktop apps within Sugar, and I think we would need some more work before this can be achieved (eg: support for standard window icons in the activity list, etc). I would probably stick to Matchbox during this release cycle, and devote a complete release cycle to testing out Metacity + Sugar for finding out possible regressions and weird behaviours. The only significant advantage is composite support, my comments on that below: >> activate composition (eToys and >> Record have trouble with this). > > Priority 1. Can we actually do this given the memory constraints? > Some comments: a) Memory is a pretty significant issue. I was running a yum install gucharmap in a B4 while sugar + browse + terminal activity was running, and during the installation of the dependencies, I saw a number of "Out of memory" messages (I think they were being printed by some XML related utilities.. scrollkeeper ??) b) The compositor in metacity seems to be quite new (http://svn.gnome.org/viewvc/metacity/trunk/src/compositor/compositor.c?view=log). I'm not sure what's up here, I remember seeing drooling at screencasts of a branch of metacity called luminocity around 2 years back. Maybe they have only recently started to merge stuff ? For stock builds, the compositor is disabled (via a Gconf option, though it is compiled in), so I am not very sure how stable thing thing is. Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 11:26 AM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > On Tue, Jun 3, 2008 at 11:20 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: >> Three more items I can think of: > > My take on the priorities. > >> * Switch from Matchbox to Metacity and > > Priority 2. I would love to have it but it might be too late, given > that Sayamindu experimentation run into interesting problems. A nice thing about this is that little changes to sugar are expected to be needed, so it's easy to swap-in swap-out, perhaps in a quick 8.2.1 release? >> activate composition (eToys and >> Record have trouble with this). > > Priority 1. Can we actually do this given the memory constraints? We'll be saving 3.5MB per python activity with the prefork trick, and in the worst case we would be having a penalty of 2MB per fullscreen window because of composition. If we only keep the active activity composited, we could limit this to a total of 4MB with peaks of 6MB (desktop window + active activity + inactive activity while we take the screenshot). Doesn't sound too bad if the avoided rewrites give us a smoother experience. Notifications on the lower corners look quite weird because of lack of transparency, btw. >> * Presence scalability when using Jabber (gadget). > > Priority 2. Sure about this? Usefulness of presence is very limited without this. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 11:20 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > Three more items I can think of: My take on the priorities. > * Switch from Matchbox to Metacity and Priority 2. I would love to have it but it might be too late, given that Sayamindu experimentation run into interesting problems. > activate composition (eToys and > Record have trouble with this). Priority 1. Can we actually do this given the memory constraints? > * In-page search in Browse. Priority 3. > * Presence scalability when using Jabber (gadget). Priority 2. > * Improve the object chooser: http://wiki.laptop.org/go/Designs/Object_Chooser Priority 3. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 3, 2008 at 11:03 AM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > The feature (and strings) freeze is approaching very quickly. We have > 17 days left. Can we make a quick list of things that we need to get > in by the 20 June? > > Let me start it. Priorities goes from 0 to 5. > > * Control panel (almost ready) - priority 5 > * New startup notification (has patch, has consensus?, needs to clean > it up) - priority 4 > * Session. Can either create a sugar-session based on gnome-session or > come up with something minimal. I tend to prefer the first option at > the moment even if it will provide us some unneeded features. - > priority 4 > * Browser bookmarks and autocompletion. - priority 3 I agree with all that. Do we have clear what needs to be done in the last item? Eben, do you know? Three more items I can think of: * Switch from Matchbox to Metacity and activate composition (eToys and Record have trouble with this). * In-page search in Browse. * Presence scalability when using Jabber (gadget). * Improve the object chooser: http://wiki.laptop.org/go/Designs/Object_Chooser My current top priority is the last one. I proposed journal object transfers to OLPC, but as I had no replies I guess that their deployments are not asking for it very strongly. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Preparing for the feature freeze
The feature (and strings) freeze is approaching very quickly. We have 17 days left. Can we make a quick list of things that we need to get in by the 20 June? Let me start it. Priorities goes from 0 to 5. * Control panel (almost ready) - priority 5 * New startup notification (has patch, has consensus?, needs to clean it up) - priority 4 * Session. Can either create a sugar-session based on gnome-session or come up with something minimal. I tend to prefer the first option at the moment even if it will provide us some unneeded features. - priority 4 * Browser bookmarks and autocompletion. - priority 3 Please add stuff you know about. I can clean up and move to the wiki when we are done. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
