Re: [Sugar-devel] The Sugar Network technical implementation overview
On 19 December 2011 23:19, Aleksey Lim alsr...@activitycentral.org wrote: IMHO, you will need to get a lot more concrete than that if you want anyone to understand what you are trying to do. The brief info, http://wiki.sugarlabs.org/go/Platform_Team/Sugar_Network/Architecture#Functioning Hi Aleksey, unfortunately you have lost me much earlier than that. I have read and reread the Concept page and still I have absolutely no idea of what you are trying to accomplish. Perhaps you started from concrete deployment needs but, when designing and documenting the system, you brought it up to such an high level of abstraction that it's impossible to understand what you are talking about (for my little, unimaginative brain at least!). For example http://wiki.sugarlabs.org/go/Sugar_Network/Concept#Overview Is that describing a video game, a social network, or maybe even... human life? :) Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The Sugar Network technical implementation overview
On 19 December 2011 19:34, Aleksey Lim alsr...@activitycentral.org wrote: Is a social network? It is exactly what http://wiki.sugarlabs.org/go/Sugar_Network#Summary says, ie, share various types of content (http://wiki.sugarlabs.org/go/Sugar_Network/Concept#Resources) between Network participants. In might be treated as a distributed social network, but it not only about this, see the purpose section on http://wiki.sugarlabs.org/go/Sugar_Network#Summary, ie, IMHO, you will need to get a lot more concrete than that if you want anyone to understand what you are trying to do. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Add a run target to the makefile
silbe pointed out how this is somewhat similar to alsroot Support isolated start patches. I don't like how those patches are setting environment variables inside the sugar script. It's not necessary for the normal case (when things are installed in the system prefix), it's more of a development convenience so I'd rather keep it as something external (it's in jhbuild at the moment, having it in the Makefile is convenient for people which are not using it). Also, fwiw, I don't think sweets stuff should be in sugar. It sounds like some kind of alternative packaging framework and we don't have, say, fedora spec files in sugar git. Marco On 7 December 2011 18:12, Marco Pesenti Gritti ma...@marcopg.org wrote: This allows to run sugar from outside the system path for development purpouses. Signed-off-by: Marco Pesenti Gritti ma...@marcopg.org --- Makefile.am | 9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/Makefile.am b/Makefile.am index 9e252af..97992be 100644 --- a/Makefile.am +++ b/Makefile.am @@ -12,3 +12,12 @@ EXTRA_DIST = \ intltool-extract.in DISTCHECK_CONFIGURE_FLAGS = --disable-update-mimedb + +run: + PATH=$(prefix)/bin:$(PATH) \ + PYTHONPATH=$(pythondir) \ + XDG_DATA_DIRS=$(datadir) \ + GTK_PATH=$(libdir)/gtk-2.0 \ + GTK_DATA_PREFIX=$(prefix) \ + GI_TYPELIB_PATH=$(libdir)/girepository-1.0 \ + sugar-emulator -- 1.7.7.3 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH 2/2] Ensure we have an m4 directory before running intltoolize
Fixes the following error: ln: failed to create symbolic link `m4/intltool.m4': No such file or directory cp: cannot create regular file `m4/intltool.m4': No such file or directory Signed-off-by: Marco Pesenti Gritti ma...@marcopg.org --- autogen.sh |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/autogen.sh b/autogen.sh index 28bc45c..739ffac 100755 --- a/autogen.sh +++ b/autogen.sh @@ -6,6 +6,8 @@ test -n $srcdir || srcdir=. olddir=`pwd` cd $srcdir +mkdir -p m4 + intltoolize autoreconf -i -- 1.7.7.3 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH 1/2] Allow to build outside the source directory
Signed-off-by: Marco Pesenti Gritti ma...@marcopg.org --- autogen.sh | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/autogen.sh b/autogen.sh index a71e202..28bc45c 100755 --- a/autogen.sh +++ b/autogen.sh @@ -1,4 +1,13 @@ #!/bin/sh + +test -n $srcdir || srcdir=`dirname $0` +test -n $srcdir || srcdir=. + +olddir=`pwd` +cd $srcdir + intltoolize autoreconf -i -./configure --enable-maintainer-mode $@ + +cd $olddir +$srcdir/configure --enable-maintainer-mode $@ -- 1.7.7.3 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Add a run target to the makefile
This allows to run sugar from outside the system path for development purpouses. Signed-off-by: Marco Pesenti Gritti ma...@marcopg.org --- Makefile.am |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/Makefile.am b/Makefile.am index 9e252af..79511e8 100644 --- a/Makefile.am +++ b/Makefile.am @@ -12,3 +12,12 @@ EXTRA_DIST =\ intltool-extract.in DISTCHECK_CONFIGURE_FLAGS = --disable-update-mimedb + +run: + PATH=$(prefix)/bin:$(PATH) \ + PYTHONPATH=$(pythondir) \ + XDG_DATA_DIRS=$(datadir) \ + GTK_PATH=$(prefix)/lib/gtk-2.0 \ + GTK_DATA_PREFIX=$(prefix) \ + GI_TYPELIB_PATH=$(prefix)/lib/girepository-1.0 \ + sugar-emulator -- 1.7.7.3 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Add a run target to the makefile
This allows to run sugar from outside the system path for development purpouses. Signed-off-by: Marco Pesenti Gritti ma...@marcopg.org --- Makefile.am |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/Makefile.am b/Makefile.am index 9e252af..97992be 100644 --- a/Makefile.am +++ b/Makefile.am @@ -12,3 +12,12 @@ EXTRA_DIST =\ intltool-extract.in DISTCHECK_CONFIGURE_FLAGS = --disable-update-mimedb + +run: + PATH=$(prefix)/bin:$(PATH) \ + PYTHONPATH=$(pythondir) \ + XDG_DATA_DIRS=$(datadir) \ + GTK_PATH=$(libdir)/gtk-2.0 \ + GTK_DATA_PREFIX=$(prefix) \ + GI_TYPELIB_PATH=$(libdir)/girepository-1.0 \ + sugar-emulator -- 1.7.7.3 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] State of Palettes for GTK+ 3.x
On 3 November 2011 20:59, Benjamin Berg ben...@sugarlabs.org wrote: I am actually thinking about removing the popdown when the user leaves the palette with the mouse. Do you mean change how the palettes behave? Or is just an implementation detail? Maro ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Idea about palettes with gtk3
Hey,
we was discussing at the hackfest today how to fixup palettes to work
in gtk3. I looked more into the GtkMenuShell code on the train and I
had an idea. It seems like GtkMenuShell basically gets access to all
the enter/leave events while it's active (because of the grab and some
local forwarding through gtk_widget_event). And we can get the actual
widget that was entered/left using Gtk.get_event_widget. You can see
this by running the attached code snippet.
So the palette could be a standard GtkMenu. The icon would popup() on
enter. The palette would listen to those events and popdown/popup
things depending if we are on the icon, the palette, another icon for
the palette in the same group, a submenu of the palette.
Marco
---
#!/usr/bin/env python
from gi.repository import Gtk
class MyMenu(Gtk.Menu):
__gtype_name__ = 'MyMenu'
def __init__(self):
super(Gtk.Menu, self).__init__()
def do_enter_notify_event(self, event):
print enter %s % Gtk.get_event_widget(event)
def do_leave_notify_event(self, event):
print leave %s % Gtk.get_event_widget(event)
class MenusApp:
def __init__(self):
self.window = Gtk.Window()
self.window.connect('destroy', Gtk.main_quit)
box = Gtk.HBox()
self.window.add(box)
self.menu = MyMenu()
menuitem = Gtk.RadioMenuItem(label=Item1)
self.menu.append(menuitem)
submenu = MyMenu()
menuitem = Gtk.RadioMenuItem(label=Item1)
submenu.append(menuitem)
menuitem = Gtk.MenuItem(label='Submenu')
menuitem.set_submenu(submenu)
self.menu.append(menuitem)
submenu.show_all()
self.menu.show_all()
button = Gtk.Button(Click me)
button.connect('clicked', self.clicked_cb)
box.pack_start(button, False, True, 0)
self.window.show_all()
def clicked_cb(self, button):
self.menu.popup(None, None, None, None, 0, 0)
app = MenusApp()
Gtk.main()
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Do not cache the buddy palette in friends tray, SL #3108
On 19 September 2011 12:59, Simon Schampijer si...@schampijer.de wrote: + #self.palette_invoker.cache_palette = False Leftover? Looks good to me otherwise. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Remove hippo from the frame
On 18 Sep 2011, at 13:47, Daniel Drake d...@laptop.org wrote: +# ask not to be collapsed if possible +self.set_size_request(4 * style.GRID_CELL_SIZE, -1) This sucks a bit. Doesn't packing the toolbar with expand true work? Not a big deal anyway, hopefully we can improve things with the gtk3 layout stuff. Rest looks cool to me. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] de-hippo'd CanvasIcon: windowed or not?
On 18 September 2011 18:19, Daniel Drake d...@laptop.org wrote: So even though one of the lower levels has changed internally, the problem is still the same. However, with GTK3's change to directly pass in a cairo context to the expose/draw handler, it doesn't feel as hacky to set an alpha channel on it. If my understanding is correct (I haven't tested) in GTK3 you should be able to get transparency by using either cairo_set_source_rgba in expose, gdk_window_set_background_rgba on a GdkWindow, or by specifying it in a theme css. None of these is an hack. At lower level what we get should be pretty much the same as hippo. I'm not sure about GTK2. I suppose it might work if X supports composite, you set an rgba colormap on the widget and you use cairo_set_source_rgba. I'm not quite sure it's worth to spend time on it because the results might vary depending on X/graphics hardware and we are going to use the client side path very soon anyway with the GTK3 port. So getting back to your question, I think we should go with the transparency option because it's not nasty but properly supported in GTK3. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] de-hippo'd CanvasIcon: windowed or not?
Trying to answer your initial email more clearly... 2011/9/15 Daniel Drake d...@laptop.org: The transparency option seems rather simple, but is perhaps nasty in that it basically decides to mess around with core window stuff when GTK+ has its back turned. Without having tested, I don't think it's nasty in GTK3, it seems like a legitimate, supported use case. Also, when icons are overlapping, it seems like the on-top window would receive the mouse event, even if the mouse is physically closer to the centre of an icon that is sitting on a lower layer. Wouldn't solving this issue generally require to test if the mouse event is contained in the widget shape? Anyway I'm not sure this is something we need to solve now, I can't think of cases in our UI where it's important and it would not be a regression compared to hippo. Just my $0.01. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Remove hippo from the intro screens
On 17 September 2011 12:30, Daniel Drake d...@laptop.org wrote: Switch to standard GTK containers. Specific coloring details have been moved to the theme at the same time. Based on earlier work by Raul Gutierrez and Walter Bender. --- src/jarabe/intro/colorpicker.py | 24 src/jarabe/intro/window.py | 122 ++- 2 files changed, 69 insertions(+), 77 deletions(-) For correct visual appearance, depends on patch: [PATCH sugar-artwork] Enforce white background on intro screen This looks good to me. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-artwork] Enforce white background on intro screen
Looks good to me. On 17 September 2011 12:27, Daniel Drake d...@laptop.org wrote: As part of the hippocanvas removal process, we can move intro window theming details into the theme. The intro window has a white background for itself and its children. --- gtk/theme/gtkrc.em | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/gtk/theme/gtkrc.em b/gtk/theme/gtkrc.em index 7f180a7..0811548 100644 --- a/gtk/theme/gtkrc.em +++ b/gtk/theme/gtkrc.em @@ -770,6 +770,8 @@ widget_class *SugarAlert* style black-bg-child widget_class *SugarSectionView style white-bg widget_class *SugarSectionView* style white-bg-child +widget_class *SugarIntroWindow style white-bg +widget_class *SugarIntroWindow* style white-bg-child # The notebook is very high, so that everything is overriden # Only the color of the tab labels needs to be modified inside the -- 1.7.6 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-toolkit] Remove hippo from naming alert
On 17 Sep 2011, at 18:37, Daniel Drake d...@laptop.org wrote: Reimplement the favorite icon as a ToggleButton, and use standard boxes, entrys and textviews for the other aspects. --- src/sugar/activity/namingalert.py | 227 +++-- 1 files changed, 90 insertions(+), 137 deletions(-) I know there is some discussion around removing this dialog, but to keep things moving and unblocked on the hippo removal front, here is a quick port. For correct visual appearance, depends on: [PATCH sugar-artwork] Add style for naming alert Simon has a patch to drop the alert. If there is consensus I guess it would be easier to just do that, not sure if that's the case though. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] de-hippo'd CanvasIcon: windowed or not?
Hey, isn't the problem going away with GTK 3.0? From the release notes GDK has been rewritten to use ‘client-side windows’. This means that GDK maintains its own window hierarchy and only uses X windows where it is necessary or explicitly requested. Of course it would be nice to decouple de-hippo from the gtk 3 port, but I'm not sure there is a good solution for this with gtk 2. Marco 2011/9/15 Daniel Drake d...@laptop.org: Hi, Me and Raul spent most of Sugarcamp Paris working on the no-hippo project. We made great progress - many hacks in the previous efforts were replaced with real code, and many temporarily removed bits of functionality were restored. However, we were left with one area of uncertainty: CanvasIcon. To recap, CanvasIcon is currently a widget that shows an Icon and tracks clicks and mouse cursor presence (to fire off a palette), that can be placed in a hippocanvas. It is used for all the icons on the home, friends and neighborhood views. The biggest part of this project is replacing CanvasIcon with a standard GTK-like widget, and replacing HippoCanvas with custom gtk.Container code at the same time which can render its child widgets (such as the new-style icon widget) at specific locations. Hippo-style CanvasIcons do not have a window associated with them. However, in our initial reimplementation, we have replaced it with a windowed widget (using an EventBox). This seemed like the obvious choice, given that mouse clicks and mouse enter/exit must be tracked. This was all working well until we realised that we have the requirement of partially overlapping icons in some cases. For example, when loads of buddy icons are grouped in a circle around an activity icon in the neighborhood view, they can sit together veeery snugly and partially overlap. With our current choice of windowed icons (with windows naturally rectangular in shape), this would not work well, as the underlying rectangles would overlap neighbors and clip them badly. We have thought up two possible solutions... Firstly, we already catch expose events in our icon class so that we can let cairo do the painting, we could simply make the windows transparent at the same time as described here: http://stackoverflow.com/questions/3908565/how-to-make-gtk-window-background-transparent Or alternatively, we could make the icon widgets non-windowed, and implement code in the (windowed) container class that tracks mouse movements and tells its children about mouse-in/mouse-out/click events. Presumably hippo had similar logic. The transparency option seems rather simple, but is perhaps nasty in that it basically decides to mess around with core window stuff when GTK+ has its back turned. Also, when icons are overlapping, it seems like the on-top window would receive the mouse event, even if the mouse is physically closer to the centre of an icon that is sitting on a lower layer. The non-windowed icon idea sounds attractive in that it would presumably result in less resource usage (fewer windows) but would need some careful coding in the container classes. It would also avoid the mouse event assignment problem as the distance to the centre of each icon from the mouse cursor could be computed before deciding which icon to pass events to. Thoughts? Replies before Sunday would be much appreciated - we'll be continuing work on this then, and this is quite a pivotal decision for the remaining tasks. cheers Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] de-hippo'd CanvasIcon: windowed or not?
On 15 September 2011 21:49, Walter Bender walter.ben...@gmail.com wrote: Maybe I am mistaken, but I thought hippo was dropped from F15 and had to be backported. It seems to be included in stock F15 (and sugar is running on it). Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] de-hippo'd CanvasIcon: windowed or not?
On 15 September 2011 21:45, Walter Bender walter.ben...@gmail.com wrote: On Thu, Sep 15, 2011 at 4:38 PM, Marco Pesenti Gritti ma...@marcopg.org wrote: Hey, isn't the problem going away with GTK 3.0? From the release notes GDK has been rewritten to use ‘client-side windows’. This means that GDK maintains its own window hierarchy and only uses X windows where it is necessary or explicitly requested. Of course it would be nice to decouple de-hippo from the gtk 3 port, but I'm not sure there is a good solution for this with gtk 2. The hippo support is disappearing faster than perhaps we'll be ready to complete the GTK 3 migration so we may have no choice... Why is that the case? I mean it seems like there shouldn't be an issue to keep depending on hippo with gtk2 and without introspection... Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Features/GTK3 updated
On 1 September 2011 17:41, Daniel Drake d...@laptop.org wrote: Hi, http://wiki.sugarlabs.org/go/Features/GTK3 has been updated. Ready for the next round of feedback! Did we consider moving from gconf to gsettings? It's not strictly necessary but it seems like it should be straightforward and perhaps a good idea while we are breaking API. Is there any way to track the status of this work? For example I've seen mentions of several dehippoification branches but I'm not sure if they landed yet. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Features/GTK3 updated
On 6 September 2011 23:08, Daniel Drake d...@laptop.org wrote: It's been mentioned, but so far I've been unconvinced of strapping it onto an already huge project. GConf does have introspectable bindings, and while nobody is contesting moving to gsettings, its effects would be limited to sugar (not activities) and it would be an invisible change to the user. So it doesn't need to be bolted onto the GTK3 project, and I think its simpler to keep it separate, but it could certainly happen immediately after as a separate step, and your help would be much appreciated there. Oh yeah, the fact that it would not affect activities is a very good point to do it separately. I didn't realise that. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Change string Remove in device palette by Remove device
On 29 Aug 2011, at 16:06, Simon Schampijer si...@schampijer.de wrote: On 08/24/2011 04:12 PM, godi...@sugarlabs.org wrote: From: Gonzalo Odiardgodi...@gmail.com This more specific string, help solve translationes where Remove does not have the same meaning. In Spanish, for example the translation Eliminar means Destroy and must be used Quitar meaning take out. Yes, agreed, we need to do something about it. I just wonder if 'device' is the best naming. GNOME for example use 'Drive'. 'Volume' might be another candidate. Do we really need to change the string? It seems like we could just use pgettext. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On 24 Jun 2011, at 13:08, Lucian Branescu lucian.brane...@gmail.com wrote: I would like to see a lot of experimentation with html activities outside the platform before we even consider integrating. There is just too much unknown and possibilities, the ideas in this area needs to be proven first. I don't really see what integration with Sugar needs to be achieved that isn't possible using the same APIs as any other activity. A html/js/node equivalent of sugar-toolkit would be useful, but I don't see any integration necessary beyond that. I didn't mean integration of the HTML activities stuff with Sugar but integration (inclusion) of the HTML activities stuff in the Sugar platform. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On 24 Jun 2011, at 15:56, Lucian Branescu lucian.brane...@gmail.com wrote: On 24 June 2011 15:13, Marco Pesenti Gritti ma...@marcopg.org wrote: On 24 Jun 2011, at 13:08, Lucian Branescu lucian.brane...@gmail.com wrote: I would like to see a lot of experimentation with html activities outside the platform before we even consider integrating. There is just too much unknown and possibilities, the ideas in this area needs to be proven first. I don't really see what integration with Sugar needs to be achieved that isn't possible using the same APIs as any other activity. A html/js/node equivalent of sugar-toolkit would be useful, but I don't see any integration necessary beyond that. I didn't mean integration of the HTML activities stuff with Sugar but integration (inclusion) of the HTML activities stuff in the Sugar platform. Right. But that first requires a sugar-web-toolkit to exist :) The way I see it, after one such toolkit has been written, it can be decided whether or not to bundle it with Sugar. I don't see it any differently, I'm not sure if/where we are disagreeing :) Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On 22 June 2011 19:02, Daniel Drake d...@laptop.org wrote: I think this is exciting and definitely a good area to explore, but at this point I'm trying to keep it separate from the rescue Browse operation. I outlined the reasoning here: http://wiki.sugarlabs.org/go/Features/WebKit I totally agree with you there. I would like to see a lot of experimentation with html activities outside the platform before we even consider integrating. There is just too much unknown and possibilities, the ideas in this area needs to be proven first. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On 21 June 2011 23:23, Daniel Drake d...@laptop.org wrote: You could have been even more convincing if you had used this API: http://webkitgtk.org/reference/index.html (yes, its webkit1, but it looks excellent from a GTK perspective, and a breath of fresh air after seeing what mozilla put you through with hulahop etc!) The reason I posted an example of the cross platform API is that I think it's what really set it apart from gtkmozembed. We would be using (directly or indirectly) the same API everyone else is using which means 1 it will be complete, 2 it will be stable, 3 it will be maintained by the core webkit developers. So, let me see if my understanding lines up with yours. WebKit2 provides an API specification, and all of the different frontends (Qt/GTK/...) implement that API, with only the minor tweaks needed to make it fit in to the platform? Yes. In your example, WKViewCreate() must have been provided as a GTK-specific thing, as it returns a GtkWidget. And the other platforms would provide their own platform-specific implementation? Yes. If I understand it correctly, the webkitgtk developers are aiming to provide both options. First, the cross-platform API implemented to return a GTK+ widget (looks like they've made great progress there). Secondly, a refresh of the GObject-style API, implemented based on top of that cross-platform API. This is what seems to be suggested here: http://blog.kov.eti.br/?p=110 Do you agree with that interpretation? That's also my understanding. As you suggest I do plan to get closer to the upstream development to really get a grip on this, but firstly, I'd be interested in your opinion on 2 further points: 1. If my understanding above is correct, do you think Browse should go with the cross-platform API, or the upcoming GObject-style one? I went back and forward on this. I was annoyed about introducing an extra layer (compared to direct python bindings of the cross-platform API), since there is already plenty of them in that stack. Though I think I'm now pretty convinced using the GObject API is the best approach for Sugar. It's more practical because there are people working on GObject but not direct python bindings. More flexible because you could use it from any language with gobject-introspection bindings. More consistent with the rest of the stack. 2. In order to get Browse, Help and Wikipedia up and running on webkit, do you see the need for a hulahop equivalent? Or some kind of sugar-level web widget abstraction? Or just direct calls into webkit. I'm not sure. I think hulahop in principle is pretty much equivalent to WebKitGtk + PyGi. In practice though I suspect there are going to be differences on the amount of code required to write something like Wikipedia and Help. If it's too much, people will just cut/paste the whole Browse, which I think we should avoid. The way I would approach it, is to first port Browse basing it directly on WebKitGtk. Then port Help or Wikipedia and see if it make sense to share code. If it's generic enough to be upstreamed we should try to. If it's sugar specific, adding it to sugar-toolkit would probably make sense (a common toolbar implementation for example?). The hardest case are activities which implement their content view in html and the rest using native widgets. Just some thoughts: * I'm not really convinced about using the web page exclusively as a DOM tree and try to manipulate it outside the sandbox. I'm not going to elaborate much on that to not digress, suffice to say that you wouldn't be able to use stuff like the canvas with that approach. * I like the idea of activities based exclusively on the web stack, using a local nodejs server to communicate with the system, but it's a lot of work. Using the cross platform API to write the viewer would be the most sensible approach, so it doesn't really affect Browse anyway. http://marcopg.org/2011/06/12/html-activities/ * Injecting javascript is a bit of an hack but it might be a practical/low cost solution. WebKitGtk doesn't seem to have something like iOS stringByEvaluatingJavaScriptFromString but it looks like it should be easy to add. I'm not sure about browser - application communication, maybe we could use window.postMessage and some hooks in WebKitGtk to listen to those. It could even be abstracted as sendMessage/addMessageListener kind of API, in both directions, using json messages. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On 17 June 2011 17:51, Martin Langhoff martin.langh...@gmail.com wrote: On Tue, Jun 14, 2011 at 6:52 PM, Marco Pesenti Gritti ma...@marcopg.org wrote: With WebKit2, this all you need to load a web page into a GtkBox So that's my understanding of WebKit -- it's easily embeddable. I am not sure whether the API is as complete or as good as we want it. I think the WebKit2 API must be complete or Apple wouldn't have been able to build Safari on the top of it. What I'm not sure is if the gtk backend implementation is complete/polished enough. IOWs, it's likely not a trivial job to get a good polished result. Absolutely not trivial. It would be probably quicker to get a working browser by forking firefox or chrome, but then maintenance would be quite a burden. Just from using the various webkit-based browsers in existence in recent Fedoras and Ubuntus -- while both Safari and Webkit are outstanding (and backed by large dev teams), Surf limited but workable (a few versions back, need to test latest!...) everything else has been very unstable and disappointing. Did you test epiphany? I think that would give you a pretty decent idea of what is achievable without putting work into WebKit itself. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
On 14 June 2011 20:58, Daniel Drake d...@laptop.org wrote: 1. I've only made half the argument above. Mozilla is bad, but why is WebKit the solution? The key questions here are: is it embeddable? Does it work well when embedded? Do the developers support it being embedded? With WebKit2, this all you need to load a web page into a GtkBox WKViewRef web_view = WKViewCreate(WKContextGetSharedProcessContext(), 0); WKPageLoadURL(WKViewGetPage(web_view), WKURLCreateWithUTF8CString(PAGE_URL)); gtk_box_pack_start(GTK_BOX(box), GTK_WIDGET(web_view), TRUE, TRUE, 0); gtk_widget_show(GTK_WIDGET(web_view)); Quite an improvement over mozilla :) More importantly, from http://trac.webkit.org/wiki/WebKit2 WebKit2 will provide a stable C-based non-blocking API that is mostly platform agnostic. In order to achieve the goal of a non-blocking API, several techniques are used to make the API usable while still providing a comprehensive set of features to the embedder. A couple of important points here: 1 The API is stable, something that mozilla never guaranteed even between minor releases. 2 The API is the same every other WebKit2 based browser will be using, it's not a special, incomplete subset of the API for embedders (I would say that was the crux of the problem with gtkmozembed). My main worry is not about embeddability really but about the quality of the gtk specific bits. I'm not sure I trust libsoup for example. Motorola and Igalia are working on those http://blogs.igalia.com/alex/2011/04/08/webkit2-minibrowser-for-the-gtk-port-running/ It would probably be a good idea to talk with them about status/plans. Testing MiniBrowser should be interesting too, it builds very easily on F15. Hope that helps, Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-toolkit] Debug logs for default profile
On 7 June 2011 12:06, Simon Schampijer si...@schampijer.de wrote: The generic path foes nt work for the telepathy logs. As we Couple of typos there :) have removed the support for different profiles it is ok to just use the default path. --- src/sugar/profile.py | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/sugar/profile.py b/src/sugar/profile.py index 8a76d2c..c1dffd7 100644 --- a/src/sugar/profile.py +++ b/src/sugar/profile.py @@ -196,14 +196,14 @@ class Profile(object): '#export LM_DEBUG=net\n' \ '#export GABBLE_DEBUG=all\n' \ '#export GABBLE_LOGFILE=' \ - '$HOME/.sugar/$SUGAR_PROFILE/logs/telepathy-gabble.log\n' \ + '$HOME/.sugar/default/logs/telepathy-gabble.log\n' \ Maybe define PROFILE_PATH=$HOME/.sugar/$SUGAR_PROFILE/logs to avoid all the duplication. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse scaling for XO display
On Thu, Nov 4, 2010 at 4:41 PM, Simon Schampijer si...@schampijer.de wrote: http://git.sugarlabs.org/projects/hulahop/repos/mainline/blobs/master/python/__init__.py#line96 We still do set the DPI in hulahop. Slightly OT: However I think some pages display rather badly on the XO. For example the links on the top left on the google landing page are rather small and blurry (not when in b/w mode). In the last days I tried to figure if we can improve there but I did not find a good solution yet. We used to have a xulrunner patch to go with this. I forget the exact details, but it was XO specific so it might have gone lost (there is a discussion somewhere on b.m.o about why it was necessary). Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse scaling for XO display
On Thu, Nov 4, 2010 at 5:00 PM, Marco Pesenti Gritti ma...@marcopg.org wrote: On Thu, Nov 4, 2010 at 4:41 PM, Simon Schampijer si...@schampijer.de wrote: http://git.sugarlabs.org/projects/hulahop/repos/mainline/blobs/master/python/__init__.py#line96 We still do set the DPI in hulahop. Slightly OT: However I think some pages display rather badly on the XO. For example the links on the top left on the google landing page are rather small and blurry (not when in b/w mode). In the last days I tried to figure if we can improve there but I did not find a good solution yet. We used to have a xulrunner patch to go with this. I forget the exact details, but it was XO specific so it might have gone lost (there is a discussion somewhere on b.m.o about why it was necessary). https://bugzilla.mozilla.org/show_bug.cgi?id=374775#c5 Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving forward (Sugar-devel Digest, Vol 24, Issue 161)
On Tue, Oct 26, 2010 at 10:10 AM, Yioryos Asprobounitis mavrot...@yahoo.com wrote: I'm not really in the field of ITC but I do know a bit about projects, particularly collaborative ones. Every development project to have a hope of success it needs Clearly defined aims Clearly defined road map Clearly defined tools/methods of implementation Clearly defined, tangible, milestones Yes! To that extend I would think that any individual taking a leading role without the above thoroughly discussed and defined, will just burn-out and be wasted. The actual definition of the aforementioned issues is what will define the best person for the job. Yes. Maybe is time for a Reinventing-Sugar face to face meeting. Yes. I generally resist sending +1 emails but well, you just wrote a big part of what was on my mind. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar and activities flag day
On Mon, Sep 20, 2010 at 4:40 PM, Tomeu Vizoso to...@sugarlabs.org wrote: The hackers at #python in GIMPNet have proposed holding a hackfest for porting Sugar to introspection and thus getting PyGObject ready. Who else would be interested from the Sugar side? We'll also need sponsors for travel and venue. Right now Boston, Bolzano and Prague have been mentioned as possibilities. The GNOME Foundation will be able to fund some travel but it will be easier to get that funding if other organizations partner on this one. I might be able to make it if it's in Europe. In the US would probably be more complicated for me. (Sounds like a great idea anyway!) Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar and activities flag day
On Tue, Sep 14, 2010 at 9:26 AM, Tomeu Vizoso to...@sugarlabs.org wrote: One way of seeing things that might make more palatable 0.92 == 1.0 is that we are really still in the first iteration and 1.0 will be when that first iteration reaches maturity, without big changes in the API. After 1.0 we can start working on what will be one day 2.0 which should be the second iteration of Sugar, hopefully using what we have learned during these years. This would mean that the next cycle would be devoted to rebasing on top of GNOME 3 so we remain packageable in future distros and that the next-gen activity APIs would only come afterwards. How does it sound? I think that's a good plan. I would accept API cleanups (especially deprecated API removals) if someone has time to do them though, I would just not make it the focus for the release. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar and activities flag day
On Tue, Sep 14, 2010 at 12:11 PM, Simon Schampijer si...@schampijer.de wrote: I myself, do not draw too much on version numbers. If you look at the consequences in support then what we shipped with 0.82 was 1.0. Exactly! Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar and activities flag day
On Mon, Sep 13, 2010 at 4:58 PM, Daniel Drake d...@laptop.org wrote: On 10 September 2010 13:41, Daniel Drake d...@laptop.org wrote: Just wanted to summarize an enlightening conversation that just happened in #sugar: No responses..surprising! Let me try a bit harder then. My thoughts/suggestions: 1. Rename sugar-0.92 to Sugar-1.0 2. Switch to pygi and GTK+ 3 for sugar-1.0 3. Allow significant sugar API changes up until the sugar-1.0 API freeze date, which I think would land mid-January 2011. These would be subject to the usual review processes to ensure quality. The time might be a bit short to do both porting and API changes. An alternative would be to have a longer unstable cycle (probably in parallel to a stable 0.92). I have the feeling that porting stable changes to unstable for a long time might be too much work for us though. So perhaps we really have to break API two times (1.0 and 2.0)... Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] internationalization: homonym handling in genpot?
On Fri, Sep 10, 2010 at 4:36 PM, Erik Blankinship er...@mediamods.com wrote: (maybe there is genpot list where this message is more apropos? Sorry, genpot is opaque to me.) My activity has two identical-in-english strings (homonyms) which need translating, but have two different meanings depending on context in an activity. How should I flag genpot that these are two different strings which might require different translations? #TRANS: bow and arrow activeDisplay = _(Bow) #TRANS: the front of a ship istrDisplay = _(Bow) Currently python setup.py genpot produces this output, making it impossible for the translator to handle both meanings differently: #. TRANS: bow and arrow #. TRANS: the front of a ship #: constants.py:35 #: constants.py:38 msgid Bow msgstr It looks like python doesn't support contexts yet: http://bugs.python.org/issue2504 Bernie is subscribed to the bug, so he might know how we are dealing with this in other activities, adding him to cc. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Enhancing Sugar to support multiple users
On Mon, Sep 6, 2010 at 9:14 AM, Tomeu Vizoso to...@sugarlabs.org wrote: I don't think you can give Sugar an accountname as a startup parameter, so there's at least something to change. When you start Sugar, you are already in an user account, so you don't really need to give it an username. What is going to allow the user to choose an account with which to log in is a display manager and you have several implementations to choose from. All should work fine with Sugar. Hi, the display manager look and feel should integrate well with the rest of the UI. We could pick a suggested dm and provide an upstream theme for it. Not sure how account name and sugar nick name should interact. Ideally they would be the same I think, but then you can't change the name easily. Finally account management is going to be tricky because it requires privileges and deployment requirements may vary. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Enhancing Sugar to support multiple users
On Mon, Sep 6, 2010 at 10:05 AM, Marco Pesenti Gritti ma...@marcopg.org wrote: Not sure how account name and sugar nick name should interact. Ideally they would be the same I think, but then you can't change the name easily. A possible approach might be sugar nick name == account full name. I think at least gdm has a way to show full name instead of user name. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Patch to display 'Sugar inside Xephyr' instead of 'Xephyr on' in the title bar. Ticket #2285
On Sun, Sep 5, 2010 at 5:12 PM, Ishan Bansal is...@seeta.in wrote:
This patch is to display 'Sugar inside Xephyr' instead of 'Xephyr on' in the
title bar of the sugar windows.
---
sugar-0.88-0.88.1/src/jarabe/util/emulator.py | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/sugar-0.88-0.88.1/src/jarabe/util/emulator.py
b/sugar-0.88-0.88.1/src/jarabe/util/emulator.py
index 5a99dbe..32ab982 100644
--- a/sugar-0.88-0.88.1/src/jarabe/util/emulator.py
+++ b/sugar-0.88-0.88.1/src/jarabe/util/emulator.py
@@ -36,6 +36,7 @@ def _run_xephyr(display, dpi, dimensions, fullscreen):
cmd = [ 'Xephyr' ]
cmd.append(':%d' % display)
cmd.append('-ac')
+ cmd += ['-title', 'Sugar inside Xephyr']
Looks fine to me. I would change the appends to use += too for consistency.
(Ideally we would translate this but it's probably too much trouble)
Marco
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] requesting reviews
On Mon, Sep 6, 2010 at 10:00 AM, Tomeu Vizoso to...@sugarlabs.org wrote: Hi, please don't submit the same patch for review to both trac and the mailing list, otherwise the review discussion bifurcates. I would add this to http://wiki.sugarlabs.org/go/Talk:Development_Team/Code_Review in the paragraph about old workflow. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Patch review request for ticket #2290
On Sun, Sep 5, 2010 at 3:44 PM, Dipankar Patro dipan...@seeta.in wrote: Hi, In reference to ticket #2290 (http://bugs.sugarlabs.org/ticket/2290) I have uploaded a patch (have attached it too). Problem: in the register procedure the time out of connection was not implemented, for an unavailable server. Solution in Patch: - Have implemented a TimedOut connection (TimedOutServerProxy( ) function) which encounters the problem of unavailable servers. - The connection timeout can be changed in seconds through the variable : 'timeout'. The default setting is at : timeout=socket._GLOBAL_DEFAULT_TIMEOUT Change it to : timeout=10, to find Sugar does not freeze anymore. How long is the default timeout? Are we freezing because we are doing the xmlrpc requests synchronously? Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Patch review request for ticket #2290
On Mon, Sep 6, 2010 at 6:04 PM, Dipankar Patro dipan...@seeta.in wrote: Sorry for that duplicate bug. Missed out that lfaraone already filed the bug. I have attached the revised patch. (uploaded at bugs.sl.o too) * changed things (subject, description, etc) according to Sascha Silbe's suggestions. @ Marco : The default timeout is way too long (unable to find out exact time). Yes, the process is synchronous, thats why Sugar is freezing. With Tomeu clarification the very short timeout make sense. As Sascha suggested the log should explain why we are doing this though. I think it would be good to also put a similar comment in a FIXME in the code. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Patch review request for ticket #2290
On Mon, Sep 6, 2010 at 11:42 AM, Tomeu Vizoso to...@sugarlabs.org wrote: Previous discussion is actually in http://bugs.sugarlabs.org/ticket/2289 and not in #2290. Looks like we cannot do XML-RPC with GIO because it doesn't support POST for http requests. The right component in our stack would be libsoup but we find again that we need introspection to use it because nobody cared to write, maintain and package python bindings for it. So many reasons to move to introspection :) Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Patch review, combining/splitting modules (was: Re: Patch review)
On 2 Sep 2010, at 21:21, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: BTW, I've recently changed my mind on the repo-combining: We should work on splitting up our code, not combine it in a single repo. Our modules are too tightly coupled; sometimes even from foo import bar doesn't work (cyclic dependencies?). Let's factor out stuff like - Sugarised / improved widgets (most of sugar.graphics?) - API wrappers (e.g. sugar.datastore.datastore) - Activity framework and make them as self-contained as possible, with a layering approach. E.g. the activity framework would use the API wrappers, but the API wrappers would not depend (w.r.t. code) on anything else. The widgets also wouldn't depend on anything else; the Object Chooser widget should be in the Journal and the code to invoke it (currently sugar.graphics.objectchooser) should be in the API wrappers package. Splitting in different packages can be helpful to mark more strongly the separation between components, but it's neither necessary nor sufficient to ensure proper modularity and decoupling. Our codebase is so tiny... Dependencies can be expressed just fine by the directories structure, without having to pay the maintenance and complexity costs of a gazillions of small packages. As I gather from recent threads on sugar-devel Gnome will force some incompatibilities on us for Sugar 0.92 anyway, so now is a good time to do this split (as it will break API). It's definitely a very good time to cleanup our API. Improving modularity would be awesome but I disagree it requires splitting packages even more. My hope is that having a separate list might lower the barrier of posting to it. People might feel more comfortable about posting unfinished / hacky stuff if there's a dedicated list for it instead of getting exposed on the main list. I don't know if it actually is a problem currently, but it's worth a try. I would make damn sure we have a problem before considering to complicate processes and create new mailing lists because of it. Cheers, Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bug tracking Vs Patch review
On 2 Sep 2010, at 21:02, Bernie Innocenti ber...@codewiz.org wrote: Let's get started this way. If needed, we could refine the rules later on. To avoid confusion, I'd wait updating the documentation in the wiki until we've tested this new workflow for a while. If a maintainer cannot stand to approve patches submitted to the mailing-list, I'd ask them to state it clearly, so we don't needlessly disappoint submitters. If a submitter still prefers the old workflow, they can keep filing patches in the bug tracker as before. Agreed? Sounds good to me. I would put the notes somewhere on the wiki as experimental/unofficial so that we can integrate improvements. I'm pretty confident we can setup and improve patchwork to help us tracking patch status reliably. I don't have a lot of time but I will commit to help out with both infrastructure and the reviews themselves. We've already had Patchwork on this list for a while: http://patchwork.sugarlabs.org/project/sugar/list/ It's a useful aid on the side, but I don't think it needs to get in the middle of the patch workflow. People are generally good at keeping track of threads in mailing list within their MUA. Some people are, some are less, included our most active maintainer :) I think we agree about patchwork being an additional tool anyway. In case a patch gets overlooked by the maintainer, the submitter can resend it after a while. If even the submitter forgets, someone else could ping. If nobody cares to ping, it means that patch wasn't very interesting after all. This is a bit simplistic. The submitter might just think we don't care and stop submitting patches. Let's forget about that for now though, we need to make this work well for the existing contributors before we even start thinking about involving more. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bug tracking Vs Patch review
Guys, honestly this whole discussion is getting a bit ridiculous, lots of rhetoric and very little practical disagreement. We agree that we should try out reviews on the mailing list, let's just do it. I'm pretty confident we can setup and improve patchwork to help us tracking patch status reliably. I don't have a lot of time but I will commit to help out with both infrastructure and the reviews themselves. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-artwork] Remove unused CFLAGS and LIBS
On Mon, Aug 23, 2010 at 8:38 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Sun, Aug 22, 2010 at 02:04, ma...@marcopg.org wrote: From: Marco Pesenti Gritti ma...@marcopg.org --- configure.ac | 5 - 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/configure.ac b/configure.ac index 3ade698..f92776d 100644 --- a/configure.ac +++ b/configure.ac @@ -25,11 +25,6 @@ fi PKG_CHECK_MODULES(GTK2, gtk+-2.0 = 2.0.0,, AC_MSG_ERROR([GTK+-2.0 is required to compile sugar-artwork])) -GDK_PIXBUF2_CFLAGS=`$PKG_CONFIG --cflags gdk-pixbuf-2.0` -GDK_PIXBUF2_LIBS=`$PKG_CONFIG --libs gdk-pixbuf-2.0` -AC_SUBST(GDK_PIXBUF2_CFLAGS) -AC_SUBST(GDK_PIXBUF2_LIBS) - Hasn't gdk-pixbuf2 been split again from gtk+ since the next stable release (2.22)? Not sure, but the variables here are not used anyway, so afaict they can do no good. Btw, may be good to CC Benjamin, I'm not sure he reads the ml regularly. Thanks. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Use GNOME_COMPILE_WARNINGS
On Fri, Aug 20, 2010 at 10:12 AM, Tomeu Vizoso to...@sugarlabs.org wrote: Hi, for which module is this patch? Heh, sorry, I somehow assumed sugar-artwork would appear in the patch... Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Remove Presence Service
On Tue, Aug 17, 2010 at 11:01 AM, Tomeu Vizoso tomeu.viz...@collabora.co.uk wrote: I still think we should move away from GObject for non UI stuff :) Agreed, but as above I think it should be a cleanup goal rather than having feature patches fixing it bit by bit. Sure, I agree. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Remove Presence Service
I don't have enough time for a very detailed review and I don't really
know telepathy, but here a few comments. Mostly nitpicks, it looks
great in general.
+BuddyIcon.__init__(self, buddy=get_owner_instance(), size=size)
Maybe assign to self._buddy here and reuse later to pass to the menu?
+if not self._buddy.props.present or \
+not self._buddy.props.current_activity:
I would align the not :)
+name = self._get_new_icon_name(self._buddy.props.current_activity)
Do we still need to use .props? I thought at some point gobject add
some magic to be able to just use properties.
+p_text = glib.markup_escape_text(self._model.bundle.get_name())
+p_icon = Icon(file=self._model.bundle.get_icon(),
Not your fault but I hate abbreviating like this... It's not
immediately clear what the variable refers to.
+item.show()
+self._invite_to_item[invite] = item
I'd /n here to make the two blocks separate.
+def set_present(self, present):
+self._present = present
+
+present = gobject.property(type=bool, default=False, getter=is_present,
+ setter=set_present)
I still think we should move away from GObject for non UI stuff :)
+if service.startswith('org.freedesktop.Telepathy.Connection.'):
+path = '/%s' % service.replace('.', '/')
+Connection(service, path, bus,
+ ready_handler=self.__connection_ready_cb)
I don't know enough about telepathy, but the path guessing here looks weird.
+logging.debug('__got_dispatch_operation_cb')
+dispatch_operation_path = kwargs['dispatch_operation_path']
Nitpicking again... In several places, I think it would be clearer to
separate the logging in its own block.
+if connection_path == '/':
+return
Why are we ignoring this? Unless it's obvious to someone that
understands telepathy, a comment would be useful here.
+#self._start_listening()
Leftover?
+if handle.invited:
+wait_loop = gobject.MainLoop()
+self._client_handler = _ClientHandler(
+self.get_bundle_id(),
+partial(self.__got_channel_cb, wait_loop))
+# The current API requires that self.shared_activity is set before
+# exiting from __init__, so we wait until we have got the shared
+# activity.
+wait_loop.run()
Ouch, quite an hack :) I'd open a bug and reference it here, it should
go away at some point.
+# Cannot call datastore.write async for creates:
+# https://dev.laptop.org/ticket/3071
+datastore.write(self._jobject)
Update the bug reference to sugarlabs.org while you are changing this?
+if handle.object_id is None and create_jobject:
+logging.debug('Creating a jobject.')
+self._jobject = datastore.create()
+title = _('%s Activity') % get_bundle_name()
+self._jobject.metadata['title'] = title
+self.set_title(self._jobject.metadata['title'])
+self._jobject.metadata['title_set_by_user'] = '0'
+self._jobject.metadata['activity'] = self.get_bundle_id()
+self._jobject.metadata['activity_id'] = self.get_id()
+self._jobject.metadata['keep'] = '0'
+self._jobject.metadata['preview'] = ''
+self._jobject.metadata['share-scope'] = SCOPE_PRIVATE
+if self.shared_activity is not None:
+icon_color = self.shared_activity.props.color
+else:
+client = gconf.client_get_default()
+icon_color = client.get_string('/desktop/sugar/user/color')
+self._jobject.metadata['icon-color'] = icon_color
Separate blocks while you are at it :) It's really hard to read.
+++ b/src/sugar/presence/util.py
Maybe a more specific name for this module? connection or something...
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
Sent from my iPad On 8 Aug 2010, at 18:40, Tiago Marques tiago...@gmail.com wrote: Just killing a random activity is a terrible idea becayse you don't want your product behaving like it's defective; the pop up idea is way more acceptable(and a lot better than having the system randomly behaving like it's crashed). Either way, this is the extremely important use of swap memory that doesn't exist here. I understand your engineering constraints on the hardware but randomly killing activities is poised to confuse users and cause people considering the hardware for deployment to think that you're selling them something defective/baddly manufactured. I tihnk I have been sloppy with my words, so let me clarify two things: I read through the thread but may also missed something. - killing processes should be done only to avoid OOM (because currently the kernel kills the wrong thing most of the time). True. - before the need for killing arises, we can do a myriad of things to prepare the user for what is coming and maybe to avoid it (some good ideas have already been posted in this thread). The idea of killing activities with the content closed seems ok but it would probably be a good idea to have a way to opt out of it for some apps. I'm thinking a PDF that may be left open on purpose to serve as reference to something, a browser window, etc. Are you then proposing to use the LRU policy to do the killing? I'm thinking that a popup with a cancel tied to a timeout may be a good idea. Once it is not allowed to be killed, it should not try to again for the session, or at least for a very large increase in query time. Apps like instant messaging(though I don't recall one for Sugar), would definitely need a definitive opt out, no? Best regards, Tiago Regards, Tomeu Best regards, Tiago Marques This, however, makes non-sugarized activities more dangerous to deal with. One more reason to demand proper sugarization. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
On 8 Aug 2010, at 18:40, Tiago Marques tiago...@gmail.com wrote: The idea of killing activities with the content closed seems ok but it would probably be a good idea to have a way to opt out of it for some apps. I'm thinking a PDF that may be left open on purpose to serve as reference to something, a browser window, etc. An opt out could be easily abused... In the PDF case the activity could be closed and reopened under the hoods, without the user even noticing (well, startup time aside). Are you then proposing to use the LRU policy to do the killing? I'm thinking that a popup with a cancel tied to a timeout may be a good idea. Once it is not allowed to be killed, it should not try to again for the session, or at least for a very large increase in query time. Imo a confirmation popup would become annoying very quickly. Also if the user refuses, the kernel will have soon to kill an activity, which is worst. Apps like instant messaging(though I don't recall one for Sugar), would definitely need a definitive opt out, no? Yeah, that's where things get tricky :/ Same issue with a background music player for example. Ideally we would just keep the connection open somehow and close the whole UI, but that's going to get complex. As long as this causes just minor annoyances to the user (like being disconnected or music stopping), I think it's probably something we don't need to solve in the first iteration. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
On 8 Aug 2010, at 20:38, Lucian Branescu lucian.brane...@gmail.com wrote: Imo a confirmation popup would become annoying very quickly. Also if the user refuses, the kernel will have soon to kill an activity, which is worst. Activities already write_file when they lose focus, they could write_file periodically or at least when warned of low memory. Yes, that's how I think it should work. Of course activities will need to do a better work to save all the possible state, because we are closing without user intervention. Apps like instant messaging(though I don't recall one for Sugar), would definitely need a definitive opt out, no? Yeah, that's where things get tricky :/ Same issue with a background music player for example. Ideally we would just keep the connection open somehow and close the whole UI, but that's going to get complex. As long as this causes just minor annoyances to the user (like being disconnected or music stopping), I think it's probably something we don't need to solve in the first iteration. Separating the activity from the service would help here. In the case of music, MPD would use a lot less memory than one of its GUIs. Right, I was thinking to something along these lines too. I'm not sure how the shell would enforce this policy though. Maybe we could allow the activity processes to use a minimum amount of memory when it has been asked to close. As I said, it gets complicated :) Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
On 8 Aug 2010, at 20:57, Lucian Branescu lucian.brane...@gmail.com wrote: Separating the activity from the service would help here. In the case of music, MPD would use a lot less memory than one of its GUIs. Right, I was thinking to something along these lines too. I'm not sure how the shell would enforce this policy though. Maybe we could allow the activity processes to use a minimum amount of memory when it has been asked to close. As I said, it gets complicated :) An activity frontend to MPD could be killed following activity policy and the MPD daemon itself would be killed following regular daemon policy. Music would play after the activity dies and would only be stopped if the MPD daemon is killed (which is less likely since it uses very little memory). Ah yeah that could work for global services. It would be good if the same could be done at activity level though. You could use the a similar mechanism but it would require figuring out how to launch these services, register them with the shell etc. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Adding committers on gitorious (was: Re: [PATCH] Remove nbsp chars from the html string before parsing)
On 6 Aug 2010, at 13:35, Tomeu Vizoso to...@sugarlabs.org wrote: I was just throwing in the idea here. I will bother you further only once I have a realistic plan in mind (and confidence in the ability to execute it with our limited resources) :) Sorry if I sounded harsh, I wanted to explain why some reforms are not going forward yet even if people agree are necessary. Oh, no worries, I don't think you sounded harsh at all. That's actually the other thing I'm planning to look into. Maybe I'm mistake but I feel we are stuck with a review process most of the existing contributors are unhappy with. I can work on a formal proposal and try to reach consensus, if that's what is missing... Sounds great, though I have felt that there was a bit of misdirected frustration during that conversation. As in the real problem not being the process but the slow response due to the lack of maintainers? If distros drop a platform dependency in the same release where the replacement lands (what happens with gnome-python2-desktop in Fedora 14), it means that everybody needs to build that dependency until they update to that release. Moreover, if some distros only include the new dependency at a later release (as with Ubuntu Maverick and Gtk3), contributors running one of those distros need to build more stuff for longer. My feeling is that these are a bit of special situations due to the dynamic bindings migration and gtk 3, I don't see they happening normally. Also it seems like they will hurt in the same way when we actually get to package Sugar on these distributions. We can reduce the harm by keeping PPA-like repos for the distros that need it (what the telepathy guys do for Ubuntu), but then someone needs to do that work. I wouldn't spend resources on this, it's error prone and time consuming. In summary, I'm able to see the importance of making as easy as possible running latest sugar on all distros, but I'm afraid it's one more goal we want to attain but don't know how to resource. To be clear, my goal is not to support all distro. I think it would be reasonable to say that you need the latest Fedora/Debian/Ubuntu to be able to build Sugar without messing with dependencies. I think there is a bit of a chicken and egg problem here. Making it easy to start developing Sugar is probably one of the best ways to increase the resources we can spend on user visible improvements. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
On 7 Aug 2010, at 21:08, Tiago Marques tiago...@gmail.com wrote: Just killing a random activity is a terrible idea becayse you don't want your product behaving like it's defective; the pop up idea is way more acceptable(and a lot better than having the system randomly behaving like it's crashed). Either way, this is the extremely important use of swap memory that doesn't exist here. I understand your engineering constraints on the hardware but randomly killing activities is poised to confuse users and cause people considering the hardware for deployment to think that you're selling them something defective/baddly manufactured. As long as activities are saving and restoring properly it could be made pretty much transparent to the user. Of course that's easier said then done... Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Adding committers on gitorious (was: Re: [PATCH] Remove nbsp chars from the html string before parsing)
On Fri, Aug 6, 2010 at 8:05 AM, Tomeu Vizoso to...@sugarlabs.org wrote: Yeah, I think we need to look into merging core in a single repository. At the end it's basically the same problem we find again and again: we spend days-person discussing some big changes, eventually may reach an agreement (or not), then nobody finds time to actually do the work. I understand your frustration but we cannot give up on the inability to make big changes. It's a normal situation when a projects gets mature (see the the struggle GNOME had to come up with a plan for 3.0), but it's even more critical for us because we have been forced to stabilize a code base which was not ready to be. I was just throwing in the idea here. I will bother you further only once I have a realistic plan in mind (and confidence in the ability to execute it with our limited resources) :) It happened with the code review process and I see very well it happening here because it would require coordination with packagers, updating lots of wiki pages, etc. That's actually the other thing I'm planning to look into. Maybe I'm mistake but I feel we are stuck with a review process most of the existing contributors are unhappy with. I can work on a formal proposal and try to reach consensus, if that's what is missing... Not even so much because of the maintenance burden, but because we really need to get to the point where building Sugar on a recent distribution is just cloning one git repository and running ./configure; make install. I'm afraid this won't be always possible no matter what we do because distros such as Fedora are willing to drop stuff that doesn't conform to GNOME 3, while Debian behaves more conservatively. http://lists.fedoraproject.org/pipermail/desktop/2010-August/006407.html Can you elaborate here? In very simplistic terms, what I'm thinking is that Sugar gets ported to GNOME 3, and then it works both on Fedora and Debian. I'm sure I'm missing something :) Cheers, Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Adding committers on gitorious (was: Re: [PATCH] Remove nbsp chars from the html string before parsing)
On 6 Aug 2010, at 00:20, James Cameron qu...@laptop.org wrote: On Thu, Aug 05, 2010 at 09:06:03AM +0200, Tomeu Vizoso wrote: Another option is having some script that adds committers to all sugar core modules in one go, that would be similar to what GNOME does. There are too many core modules, in my opinion (and Michael Stone's). I see no good reason why there isn't just one git repository for the whole of Sugar. Yeah, I think we need to look into merging core in a single repository. Not even so much because of the maintenance burden, but because we really need to get to the point where building Sugar on a recent distribution is just cloning one git repository and running ./configure; make install. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] update on the collaboration refactoring
On Mon, Aug 2, 2010 at 6:04 PM, Tomeu Vizoso tomeu.viz...@collabora.co.uk wrote: Activities using the sugar.presence API in sugar-toolkit should require no changes Is the long term plan to deprecate sugar.presence and have activities interact directly with telepathy? Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] update on the collaboration refactoring
On Tue, Aug 3, 2010 at 12:08 PM, Tomeu Vizoso tomeu.viz...@collabora.co.uk wrote: Yes, Collabora is working on higher level APIs in telepathy-glib that will be exposed through introspection and Canonical is exploring similar APIs as part of the Quickly widgets library. Sounds great! Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Evince browser plugin
Hi Lucian, sorry for the long delay, here is the git repository with the evince browser plugin. http://git.sugarlabs.org/projects/evince-browser-plugin The changes are on the plugin branch. It builds and seems to work fine for me in Lucid. Unfortunately it's still based on 2.25... I haven't tried rebasing to master, so I'm not sure how much work that would involve. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH 1/3] Touchpad extension for the frame
On 9 Jul 2010, at 05:58, Walter Bender walter.ben...@gmail.com wrote: +from gettext import gettext as _ + +import gtk +import gconf +import os Move the os import to the first block :) Nice work! Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH 1/3] Touchpad extension for the frame
On 8 Jul 2010, at 17:23, Walter Bender walter.ben...@gmail.com wrote:
---
extensions/deviceicon/touchpad.py | 152 +
1 files changed, 152 insertions(+), 0 deletions(-)
create mode 100644 extensions/deviceicon/touchpad.py
diff --git a/extensions/deviceicon/touchpad.py
b/extensions/deviceicon/touchpad.py
new file mode 100644
index 000..a182d9c
--- /dev/null
+++ b/extensions/deviceicon/touchpad.py
@@ -0,0 +1,152 @@
+# Copyright (C) 2010, Walter Bender, Sugar Labs
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+
+
+from gettext import gettext as _
+
+import gtk
+import gconf
+from os import system, path, remove
The os import should be in the first block. I wouldn't import the methods,
prepending os. to the actual calls makes it clearer what the methods are doing.
+from sugar.graphics.tray import TrayIcon
+from sugar.graphics.xocolor import XoColor
+from sugar.graphics.palette import Palette
+from jarabe.frame.frameinvoker import FrameWidgetInvoker
+
The jarabe import should be in a separate block.
+_STATUS_TEXT = {'capacitive': _('finger'), 'resistive': _('stylus')}
+_CAPACITIVE_ICON_NAME = 'touchpad-capacitive'
+_RESISTIVE_ICON_NAME = 'touchpad-resistive'
+_FLAG_PATH = '/home/olpc/.olpc-pentablet-mode'
+_NODE_PATH = '/sys/devices/platform/i8042/serio1/ptmode'
I think we don't need to mark these has private, the plugins code is not
imported by other modules, so private/public doesn't matter.
+
+
One less new line :) I'm sure everyone has been missing my nitpicks!
+class DeviceView(TrayIcon):
+ Manage the touchpad mode from the device palette on the Frame
+
+FRAME_POSITION_RELATIVE = 500
+
+def __init__(self):
+ Create the touchpad palette and display it on Frame
+
+# Only appears when the device exisits
+if not path.exists(_NODE_PATH):
+return
+
Aborting constructions looks wrong, better to move the check to the setup
method.
+if get_touchpad() == 'resistive':
+icon_name = _RESISTIVE_ICON_NAME
+else:
+icon_name = _CAPACITIVE_ICON_NAME
It would be nice to use a dictionary like you did with the label.
+
+client = gconf.client_get_default()
+color = XoColor(client.get_string('/desktop/sugar/user/color'))
+TrayIcon.__init__(self, icon_name=icon_name, xo_color=
Splitting the blocks with a new line here would be more readable.
+self.set_palette_invoker(FrameWidgetInvoker(self))
+self.connect('button-release-event', self.__button_release_event_cb)
+self.connect('expose-event', self.__expose_event_cb)
+
+def create_palette(self):
+ On create, set the current mode
+self.palette = ResourcePalette(_('My touchpad'), self.icon)
+self.palette.set_group_id('frame')
+return self.palette
+
+def __button_release_event_cb(self, widget, event):
+ On button release, switch modes
+self.palette.toggle_mode()
+return True
+
+def __expose_event_cb(self, *args):
+pass
Leftover? Seems unnecessary to connect the signal since you are just passing
then.
+
+class ResourcePalette(Palette):
+ Query the current state of the touchpad and update the display
+
+def __init__(self, primary_text, icon):
+ Get the status
+Palette.__init__(self, label=primary_text)
+
+self._icon = icon
+
+self.connect('popup', self.__popup_cb)
+self.connect('popdown', self.__popdown_cb)
+
+self.updating = False
+
+vbox = gtk.VBox()
+self.set_content(vbox)
+
+self._status_text = gtk.Label()
+vbox.pack_start(self._status_text, padding=10)
+self._status_text.show()
+
+vbox.show()
+
+self._mode = get_touchpad()
+self.set_mode_graphics()
+
+def set_mode_graphics(self):
Looks like this can be marked as private? update would be more appropriate then
set since you are not passing a mode.
+ Set the label and icon based on the current mode
+self._status_text.set_label(_STATUS_TEXT[self._mode])
+if self._mode == 'resistive':
+self._icon.props.icon_name =
Re: [Sugar-devel] [PATCH 1/3] Touchpad extension for the frame
In general, this looks olpc specific right now, but I think it's fine to have it upstream, we can abstract it more later if we need to support different hardware. It's a while I don't code or review Sugar patches so I might very well be missing things... And I can't really test the patch right now. Thanks! Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH 3/3] Touchpad extension for the frame
Should be squashed with patch 2, to keep the tree functional. On 8 Jul 2010, at 17:24, Walter Bender walter.ben...@gmail.com wrote: --- icons/scalable/device/Makefile.am |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/icons/scalable/device/Makefile.am b/icons/scalable/device/Makefile.am index 28818ab..0d3f2fc 100644 --- a/icons/scalable/device/Makefile.am +++ b/icons/scalable/device/Makefile.am @@ -84,7 +84,9 @@ icon_DATA = \ speaker-muted-000.svg \ speaker-muted-033.svg \ speaker-muted-066.svg \ - speaker-muted-100.svg + speaker-muted-100.svg \ +touchpad-capacitive.svg \ +touchpad-resistive.svg EXTRA_DIST = $(icon_DATA) -- 1.7.0.4 -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] SoaS - moving onward...
On Tue, Feb 24, 2009 at 2:53 AM, Wade Brainerd wad...@gmail.com wrote: Hey, this link appears to have disappeared. I updated http://sugarlabs.org/go/Sugar_on_a_Stick to focus on downloading and writing this distribution to a USB stick. Other aspects of SoaS were moved down to the TODO links. Great, thanks! I'd like to standardize on a *single* program for creating USB keys, preferrably the Fedora LiveUSB Creator. Can anyone try this out on Linux and report back whether it works? If it indeed does, I'll move the other key creation methods and post instructions with screenshots. Unfortunately there are not Debian/Ubuntu packages of the liveusb creator :/ Second, given the amount of work we are doing on SoaS right now should we consider a SoaS namespace in the wiki? E.g. SoaS/VirtualBox, SoaS/Ubunto, SoaS/TODO, etc. I'm not suggesting a whole new Team (unless you guys want to do that) but just a little more organization. Sounds good to me, always wanted to do that but never got at it... Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] SoaS - moving onward...
On Tue, Feb 24, 2009 at 6:47 AM, Marco Pesenti Gritti marc...@sugarlabs.org wrote: I'd like to standardize on a *single* program for creating USB keys, preferrably the Fedora LiveUSB Creator. Can anyone try this out on Linux and report back whether it works? If it indeed does, I'll move the other key creation methods and post instructions with screenshots. Unfortunately there are not Debian/Ubuntu packages of the liveusb creator :/ If someone confirms that it works in Fedora, we could at least standardize on it for Windows + Fedora and keep the script instructions just for other distros. Also maybe at some point we can get a friendly debian packager to package it up :) Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar now has smoke test procedures.
On Sun, Feb 22, 2009 at 8:15 AM, Mel Chua m...@melchua.com wrote: Because of the impending 0.84 release and the need to have a simple answer to the question does build X work? Colin, Elsa, and I came up with http://sugarlabs.org/go/Smoke_test. It is meant to be a 20min does this build work? test for developers. It can also be used to verify that your new development/testing environment has set up correctly, or as a quick (but boring) intro to Sugar's basic functionality. Ww, this is fantastic, thanks Colin, Elsa and Mel! Yay Olin :) Needed: * a link to good 0.84 installation/setup instructions (step-by-step here's how to set up to test our latest build directions) - can someone point us in the direction of whatever is considered canonical for this release? We have instructions for SoaS. The whole page could use some cleanups. In particular we should not mix different distributions in the same page imo and we should expand the linux section. But it's a start. http://sugarlabs.org/go/Sugar_on_a_Stick#Fedora_based_Sugar_on_a_Stick In general I suggest that we don't settle on a *single* canonical distributions but we list all the distributions that matches certain criteria. For example: ship a very recent Sugar version, are reasonably easy and documented to install, are in a good enough state to be tested by non-developers. In practice SoaS is probably the only one that matches them at the moment, hopefully that will change soon. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SoaS - Another Snapshot
Awesome stuff! Let's make sure to update the link on the wiki page when announcing a new image. http://sugarlabs.org/go/Sugar_on_a_Stick#Fedora_based_Sugar_on_a_Stick (I'm removing a comment there about checking people blogs to figure out the latest one, because that seem complicated/unreliable especially now that both you and Simon are doing images). Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar now has smoke test procedures.
On Sun, Feb 22, 2009 at 12:51 PM, Marco Pesenti Gritti marc...@sugarlabs.org wrote: We have instructions for SoaS. The whole page could use some cleanups. In particular we should not mix different distributions in the same page imo and we should expand the linux section. But it's a start. http://sugarlabs.org/go/Sugar_on_a_Stick#Fedora_based_Sugar_on_a_Stick I cleaned up the page a bit and expanded the linux section. Running the script on Fedora is known to work, it *might* work also on other distributions. I'm sure the instructions can be improved, feel free to edit or to send questions. Also please report any problem you run into. Thanks, Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar now has smoke test procedures.
On Sun, Feb 22, 2009 at 3:36 PM, Marco Pesenti Gritti marc...@sugarlabs.org wrote: On Sun, Feb 22, 2009 at 12:51 PM, Marco Pesenti Gritti marc...@sugarlabs.org wrote: We have instructions for SoaS. The whole page could use some cleanups. In particular we should not mix different distributions in the same page imo and we should expand the linux section. But it's a start. http://sugarlabs.org/go/Sugar_on_a_Stick#Fedora_based_Sugar_on_a_Stick I cleaned up the page a bit and expanded the linux section. Running the script on Fedora is known to work, it *might* work also on other distributions. I'm sure the instructions can be improved, feel free to edit or to send questions. Also please report any problem you run into. If someone has time it would also be good to test liveusb-creator in Fedora (following the Windows instructions on our wiki), if it works it should be easier to use than the command line script. https://fedorahosted.org/liveusb-creator/ (Can't test myself right now, I don't have a Fedora install) Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Getting sugar-jhbuild run working
Is this a clean jhbuild? Do you have sugar-jhbuild/install/libexec/gconfd-2 ? Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Getting sugar-jhbuild run working
Please try the following: ./sugar-jhbuild shell python import gconf find out the python process pid cat /proc/[pid]/maps | grep gconf Thanks, Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Getting sugar-jhbuild run working
On Mon, Feb 9, 2009 at 3:22 PM, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: On Mon, Feb 09, 2009 at 02:59:16PM +0100, Marco Pesenti Gritti wrote: cat /proc/[pid]/maps | grep gconf 7fd77a69b000-7fd77a6d3000 r-xp 08:01 355522 /usr/lib/libgconf-2.so.4.1.5 7fd77a6d3000-7fd77a8d2000 ---p 00038000 08:01 355522 /usr/lib/libgconf-2.so.4.1.5 7fd77a8d2000-7fd77a8d4000 r--p 00037000 08:01 355522 /usr/lib/libgconf-2.so.4.1.5 7fd77a8d4000-7fd77a8d7000 rw-p 00039000 08:01 355522 /usr/lib/libgconf-2.so.4.1.5 This is why it's failing... It should use the libgconf inside sugar-jhbuild/install. ./sugar-jhbuild shell echo $LD_LIBRARY_PATH Please share the output and verify that you actually have a libgconf* inside that directory. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Getting sugar-jhbuild run working
On Mon, Feb 9, 2009 at 3:32 PM, Marco Pesenti Gritti marc...@sugarlabs.org wrote: On Mon, Feb 9, 2009 at 3:22 PM, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: On Mon, Feb 09, 2009 at 02:59:16PM +0100, Marco Pesenti Gritti wrote: cat /proc/[pid]/maps | grep gconf 7fd77a69b000-7fd77a6d3000 r-xp 08:01 355522 /usr/lib/libgconf-2.so.4.1.5 7fd77a6d3000-7fd77a8d2000 ---p 00038000 08:01 355522 /usr/lib/libgconf-2.so.4.1.5 7fd77a8d2000-7fd77a8d4000 r--p 00037000 08:01 355522 /usr/lib/libgconf-2.so.4.1.5 7fd77a8d4000-7fd77a8d7000 rw-p 00039000 08:01 355522 /usr/lib/libgconf-2.so.4.1.5 This is why it's failing... It should use the libgconf inside sugar-jhbuild/install. ./sugar-jhbuild shell echo $LD_LIBRARY_PATH Please share the output and verify that you actually have a libgconf* inside that directory. Also: ./sugar-jhbuild shell ldd /usr/lib/python-support/python-gconf/python2.5/gtk-2.0/gconf.so Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Getting sugar-jhbuild run working
On Mon, Feb 9, 2009 at 4:00 PM, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: On Mon, Feb 09, 2009 at 03:32:23PM +0100, Marco Pesenti Gritti wrote: This is why it's failing... It should use the libgconf inside sugar-jhbuild/install. Then why does config/sysdeps/ubuntu-8.10.xml list gconf and python-gconf as dependencies? Do some parts of sugar use the system-supplied ones and others the privately installed ones? It sounds like a bug in the sysdeps. /home/sugar/sugar-jhbuild/install/lib64/libgconf-2.so.4 Hmmm I suspect some x86_64 weirdness. Alex, are you also on x86_64? Sascha, can you try to install the 64 bit version of python-gconf and see if it helps? Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Getting sugar-jhbuild run working
On Mon, Feb 9, 2009 at 4:08 PM, Marco Pesenti Gritti marc...@sugarlabs.org wrote: Hmmm I suspect some x86_64 weirdness. Alex, are you also on x86_64? Sascha, can you try to install the 64 bit version of python-gconf and see if it helps? I must say I have no idea if Ubuntu is multilib... Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Getting sugar-jhbuild run working
On Mon, Feb 9, 2009 at 5:10 PM, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: I suppose python-gconf has been compiled using the -rpath option. Don't know how to dump the rpath setting, but the library does contain the string /usr/lib so it seems likely. Could be. If someone knows how to lookup Ubuntu build logs that should be easy to confirm... Any reason why sugar tries to use the system-supplied Python wrapper in combination with a locally installed gconf library? How do you ensure those two match exactly, given that the Python wrapper is compiled _before_ the library? You can't ensure it but GConf API has been stable for a while now and I don't expect it to change. If we could rebuild just gnome-python-desktop that would be probably fine but... I'm not sure it's possible to mix gnome-python modules from system and jhbuild because of the gtk-2.0 path trick. I guess at worst we could play with pythonpath. I don't have time to try that out right now, if someone wants to play with it, would be great. The other option is to use system GConf, but that also is quite painful because the ORBit version of it is not really jhbuild config (If I remember correctly we would have to ask people to mess with /etc to get stuff working). Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Getting sugar-jhbuild run working
On Mon, Feb 9, 2009 at 5:24 PM, Marco Pesenti Gritti marc...@sugarlabs.org wrote: The other option is to use system GConf, but that also is quite painful because the ORBit version of it is not really jhbuild config (If I remember correctly we would have to ask people to mess with /etc to get stuff working). s/jhbuild config/jhbuild friendly Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Getting sugar-jhbuild run working
On Mon, Feb 9, 2009 at 7:07 PM, Jonas Smedegaard d...@jones.dk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Feb 09, 2009 at 05:24:53PM +0100, Marco Pesenti Gritti wrote: On Mon, Feb 9, 2009 at 5:10 PM, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: I suppose python-gconf has been compiled using the -rpath option. Don't know how to dump the rpath setting, but the library does contain the string /usr/lib so it seems likely. Could be. If someone knows how to lookup Ubuntu build logs that should be easy to confirm... If this turns out to be the case, you should probably file a bugreport against Ubuntu. More general info on rpath here: http://wiki.debian.org/RpathIssue According to that document it seems like LD_LIBRARY_PATH should override rpath anyway... Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Cannot sugar-jhbuild update
On Sun, Feb 8, 2009 at 1:47 PM, David Farning dfarn...@sugarlabs.org wrote: Thanks for finding this. Indeed, Gnome must have recently moved the location of jhbuild in their git repo. A couple of weeks ago there was a poll at Gnome about changing their VCS to git. The changes to the gnome git infrastructure have been fast and furious since then. afaik GNOME git is experimental for now (their official repos are on svn and it has not yet been decided if they will be actually migrated to git, flamewars still going on about it). Perhaps it would be better to do our clone of jhbuild on git.sugarlabs.org and pull from there for now. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Getting sugar-jhbuild run working
Can you send ~/.sugar/default/logs/shell.log? Marco On Mon, Feb 9, 2009 at 5:47 AM, Alex Holkner alex.holk...@gmail.com wrote: Thanks for the previous help in getting sugar-jhbuild updating from the correct git repository. I've now got a successful install (this involved upgrading to Ubuntu 8.10 and installing some additional packages not listed on the wiki -- I've added them now). Running './sugar-jhbuild run' brings up an empty Xephyr window (just the patterned background) and does nothing else. The output is: [linux] ~/foreign/sugar-jhbuild% ./sugar-jhbuild run Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! unrecognised device identifier! (EE) config/hal: NewInputDeviceRequest failed unrecognised device identifier! (EE) config/hal: NewInputDeviceRequest failed unrecognised device identifier! (EE) config/hal: NewInputDeviceRequest failed Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list! unrecognised device identifier! (EE) config/hal: NewInputDeviceRequest failed unrecognised device identifier! (EE) config/hal: NewInputDeviceRequest failed unrecognised device identifier! (EE) config/hal: NewInputDeviceRequest failed 1234153991.2729919 STARTUP: Starting the shell Thanks for any help Alex. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Another Soas image for the XO
Now with readable fonts :) http://download.sugarlabs.org/soas/xoimages/soas3.crc http://download.sugarlabs.org/soas/xoimages/soas3.img Next challenge will be to trim the size down. I think Sebastian has been working on that. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Fedora 10 machine to build soas-1 images
Hello, do we have any F10 machine we can use to build Soas? sugarlabs1 has an old kernel, which prevents me to build XO images. I'll likely need sudo on it. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SoaS at FOSDEM
On Tue, Feb 3, 2009 at 1:56 PM, Simon Schampijer si...@schampijer.de wrote: I tried it by hand yesterday and added our sugar repo to the yum config does work fine. The question is how we create that file now. We could do it in the kickstart file - but maybe there are other options? You could also use a package... not really sure. What about asking on fedora-olpc about the best way to do it? Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [OBORONA-SPAM] Re: sugar-widgets request
On Mon, Feb 2, 2009 at 5:49 PM, Aleksey Lim alsr...@member.fsf.org wrote: I mean new sugar-widgets package should use only public activity API, something like a current-sugar's-version-independent link between sugar and activities (mostly honey activities). That's pretty much what sugar-toolkit is supposed to be though... My main concern is API stability policy for this code. It's going to be difficult to maintain large new API stable... especially if they are initially just cut and paste from activities. GNOME deals with having an egg module from which applications can cut/paste, which has his downsides too. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] What is a blocker bug today?
A bugsquad even! Reprioritized most of mine yesterday... Marco On Mon, Feb 2, 2009 at 2:47 PM, Bernie Innocenti ber...@codewiz.org wrote: Marco Pesenti Gritti wrote: I guess at some point the default was Blocker, because there lots of tickets marked that way in trac. Yeah, we should re-prioritize them. Do we have a Bugmaster role? We should /me steps back... quickly! -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Soas Distribution/OS
Can we add Soas as one of the field alternatives? Couldn't quickly figure out how to do it myself... Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] How to move on? Spins, SoaS, and more!
On Sun, Feb 1, 2009 at 7:34 PM, Sebastian Dziallas sebast...@when.com wrote: But regarding the Education Spin: Couldn't we push Sugar in there? The KDE project is doing a great job with their applications regarding education, and they continue to do so. Recently, Greg made me aware of this project [4], where they try to use Plasma for such purposes. Now. Wouldn't it be an idea, to work again on the Education Spin and restructure it a bit, include Sugar, talk about the advantages of using KDE, and so on? I want to ask for your opinion to make sure that this isn't happening too early. But that way, we could provide a great educational solution, based on Fedora, helping both the Sugar and KDE Edu project. But for this, we need a kind of collaboration, between those projects (e.g. Fedora / Sugar or Fedora / KDE Edu), so that we can provide a well designed, usable solution. Can you elaborate on what kind of collaboration are you thinking about here? Is the idea to ship Sugar as an alternative desktop on the Edu spin or something different? Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SoaS at FOSDEM
On Sat, Jan 31, 2009 at 11:43 AM, Simon Schampijer si...@schampijer.de wrote: Latest image and improvements (git head with some fixes) are listed in this post http://erikos.sweettimez.de/?p=332 It is even a bit smaller :) Now, we really need to make this as small as possible. I wonder how we can best do this. I mean I can get a list of deps of Sugar and then add all the rest needed to start it - for example taking @gnome-desktop out of the kickstart did not boot anymore. Any pointers to infos on how to best trim down are welcome. Why do you think size is very important for Soas (real question)? Caroline requested to have GNOME on the images so that people can switch to it if they want. I think Sebastian is doing some work to reduce size for the XO. If size is not a blocker we could just leverage his work... Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SoaS at FOSDEM
On Sat, Jan 31, 2009 at 2:15 PM, Tomeu Vizoso to...@sugarlabs.org wrote: Why do you think size is very important for Soas (real question)? If we want wide testing and people need to download 800MB each time, many people (me included) will have a hard time getting those bits. But you don't actually need to download images each time. yum update works fine... Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SoaS at FOSDEM
On Sat, Jan 31, 2009 at 3:09 PM, Sebastian Dziallas sebast...@when.com wrote: Well, it's mainly as small as it is due to removals regarding locals and drivers, but if you don't mind, I could also quickly draft up a kickstart file including GNOME and Sugar, wihch is not limited to the XO. I'd love that! Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SoaS at FOSDEM
On Sat, Jan 31, 2009 at 4:40 PM, Simon Schampijer si...@schampijer.de wrote: Ok, did not think about yum update. Did not know GNOME was a requirement, wonder if this is a benefit to have though. I mean it is Sugar on a stick in the end. If it helps to make mac users get to know gnome or sugar i guess that is ok. Caroline wants to get Soas to high school students so that they can play with and help us out with testing etc. At the same time they would like to be able to run normal linux applications like the gimp. That was more or less the rationale, but I'm ccing Caroline which can explain better. (Another way to cover that use case could be to have them yum install GNOME or build customized images with it). Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SoaS at FOSDEM
On Sat, Jan 31, 2009 at 4:53 PM, David Van Assche dvanass...@gmail.com wrote: You can easily make gdm the session manager from which to choose sugar or gnome, and thereby give them access to gimp, inkscape and whatever other apps... gdm was eating quite a bit of memory last time I tried. Also Caroline didn't want to have a choice visible in the UI, she wants Soas to look very clean and straightforward, advanced users can go to the shell if they want to use GNOME. (Again reporting her rationale, and hoping to do it correctly, but I tend to agree). Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A small request.
On Fri, Jan 30, 2009 at 9:54 PM, Michael Stone mich...@laptop.org wrote: Dear Sugar team, I've been very confused (and frankly, significantly angered) by recent remarks that I've encountered both in person (e.g. from Bernie) and in #sugar (e.g. from Simon and Tomeu) about how sugar-related folk are thinking about the issue of mass activity installation and update. Consequently, I'd find it really helpful if we could sit down, lay out all the agreed facts, disagreements, and desires, and then figure out a mutually agreeable plan for the future. What about discussing it in the next development team meeting? http://sugarlabs.org/go/DevelopmentTeam/Meetings#When_and_where Greg has magic powers to get all of us working together. We are such an apollo team! Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A small request.
On Sun, Feb 1, 2009 at 1:26 AM, C. Scott Ananian csc...@laptop.org wrote: Can someone tell me what it is we are discussing? We need to integrate some kind of activity updating solution in Glucose. There is disagreement on when (0.84 or next release cycle) and what (your updater, something based on it, a complete rewrite). Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SoaS at FOSDEM
On Fri, Jan 30, 2009 at 8:46 PM, Greg Dekoenigsberg g...@redhat.com wrote: So. If someone can point me to the *authoritative iso image* that we want to use for SoaS, I will make sure that we have install stations at the Fedora booth at FOSDEM. The latest known to work is: http://download.sugarlabs.org/soas/snapshots/1/Soas-200901271941.iso Simon did another image today, but I don't know what improvements it contains and if it's tested. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Soas snapshot
You can download the iso here: http://download.sugarlabs.org/soas/snapshots/1/Soas-200901271941.iso Instructions on how to install it are here: http://sugarlabs.org/go/Sugar_on_a_Stick I also made an experimental image for the XO. It's not signed, so you will need security disabled, if you want to try it. http://download.sugarlabs.org/soas/xoimages/soas1.img http://download.sugarlabs.org/soas/xoimages/soas1.crc Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] infrastructure mailing list
On Mon, Jan 26, 2009 at 5:26 PM, Wade Brainerd wad...@gmail.com wrote: I have a developer who has been unable to push to Gitorious using his SSH key. It was working two weeks ago, then suddenly stopped. We have sent emails to Bernie but have not gotten any real attention to the issue. Can there be a mailing list for infrastructure support requests? We have tried everything we can think of, including reinstalling his VM from scratch and re-uploading his public key. We really need an infrastructure squad... I *think* this is an osuosl problem, so you might want to mail the following address with the details. OSL Support support at osuosl.org Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
