[Sugar-devel] datastore results inconsistency
Hi Tomeu, I found the issue with the journal showing a duplicated entry after hand-deleting a datastore entry. It's an issue in the datastore, in the same function: DataStore.find() After your patch, we now weed out the entries that don't exist on-disk, but we still return "count" items (which is not adjusted accordingly) My suggested fix: decrement count in the loop if the file does not exist. for uid in uids: if os.path.exists(layoutmanager.get_instance().get_entry_path(uid)): metadata = self._metadata_store.retrieve(uid, properties) entries.append(metadata) + else: + count = count - 1 Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] datastore results inconsistency
On Sat, 2009-06-27 at 12:57 +0200, Tomeu Vizoso wrote: > On Fri, Jun 26, 2009 at 18:57, Daniel Drake wrote: > > Hi Tomeu, > > > > I found the issue with the journal showing a duplicated entry after > > hand-deleting a datastore entry. > > Thanks for looking at this. As we discussed on IRC, things are a bit > more complex than I initially thought and we should rebuild all the > index when we find that the disk contents don't match the index. > > Would be great if you could try these patches and see if the journal > is more resistant in these cases: > > DS: http://shell.sugarlabs.org/~tomeu/rebuild_index_on_inconsistency.patch > Shell: http://shell.sugarlabs.org/~tomeu/remake_cache_on_inconsistency.patch Thanks, these seem to fix the problem! Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar + OLPC mesh network selection logic
On Wed, 2009-07-01 at 12:18 -0400, Dan Williams wrote:
> If other APs appear later, it may well trigger the
> schedule_activate_check() which might cause NM to try to connect to that
> new network. To combat that, I'd suggest that the mesh device block the
> wifi device from activating if it already failed by putting it into the
> UNAVAILABLE state or something, but that could be error prone. What I
> think we really want here is the 'device idle' concept that asac and I
> have been talking over for a while.
The same consideration has to apply for when the mesh device disconnects
the eth device, because the user requested a mesh connection. Right now,
NM immediately reactivates eth0 (usually reconnecting to the same
network as before) and "wins."
What is the "device idle" concept? What do you think of an approach
along these lines? This way the mesh device can attach to the
autoconnect-allowed signal on the main device, and influence when it can
and cannot be used for automatic connections.
Daniel
>From bf78fa416ecf96bf9e607d1dd7c8fec29652a821 Mon Sep 17 00:00:00 2001
From: Daniel Drake
Date: Mon, 6 Jul 2009 16:42:55 +0100
Subject: [PATCH] Allow devices to inhibit autoconnect through a signal
This allows a device (or a companion) to signal that it is not a good
time for a specific device to autoconnect to a network.
---
src/NetworkManagerPolicy.c |2 +-
src/nm-device.c| 45
src/nm-device.h|1 +
3 files changed, 47 insertions(+), 1 deletions(-)
diff --git a/src/NetworkManagerPolicy.c b/src/NetworkManagerPolicy.c
index 6bba92f..e2d4c95 100644
--- a/src/NetworkManagerPolicy.c
+++ b/src/NetworkManagerPolicy.c
@@ -726,7 +726,7 @@ schedule_activate_check (NMPolicy *policy, NMDevice *device)
if (state < NM_DEVICE_STATE_DISCONNECTED)
return;
- if (!nm_device_can_activate (device))
+ if (!nm_device_can_activate (device) || !nm_device_autoconnect_allowed (device))
return;
for (iter = policy->pending_activation_checks; iter; iter = g_slist_next (iter)) {
diff --git a/src/nm-device.c b/src/nm-device.c
index 5826a2a..488b2cf 100644
--- a/src/nm-device.c
+++ b/src/nm-device.c
@@ -50,11 +50,19 @@
#include "nm-setting-connection.h"
#include "nm-dnsmasq-manager.h"
#include "nm-dhcp4-config.h"
+#include "nm-marshal.h"
#define NM_ACT_REQUEST_IP4_CONFIG "nm-act-request-ip4-config"
static void device_interface_init (NMDeviceInterface *device_interface_class);
+enum {
+ AUTOCONNECT_ALLOWED,
+ LAST_SIGNAL,
+};
+
+static guint signals[LAST_SIGNAL] = { 0 };
+
G_DEFINE_TYPE_EXTENDED (NMDevice, nm_device, G_TYPE_OBJECT,
G_TYPE_FLAG_ABSTRACT,
G_IMPLEMENT_INTERFACE (NM_TYPE_DEVICE_INTERFACE,
@@ -360,6 +368,34 @@ nm_device_can_activate (NMDevice *self)
return TRUE;
}
+static gboolean
+autoconnect_allowed_accumulator (GSignalInvocationHint *ihint,
+ GValue *return_accu,
+ const GValue *handler_return, gpointer data)
+{
+ if (!g_value_get_boolean (handler_return))
+ g_value_set_boolean (return_accu, FALSE);
+ return TRUE;
+}
+
+gboolean
+nm_device_autoconnect_allowed (NMDevice *self)
+{
+ GValue instance = { 0, };
+ GValue retval = { 0, };
+
+ g_value_init (&instance, G_TYPE_OBJECT);
+ g_value_take_object (&instance, self);
+
+ g_value_init (&retval, G_TYPE_BOOLEAN);
+ g_value_set_boolean (&retval, TRUE);
+
+ /* Use g_signal_emitv() rather than g_signal_emit() to avoid the return
+ * value being changed if no handlers are connected */
+ g_signal_emitv (&instance, signals[AUTOCONNECT_ALLOWED], 0, &retval);
+ return g_value_get_boolean (&retval);
+}
+
NMConnection *
nm_device_get_best_auto_connection (NMDevice *dev,
GSList *connections,
@@ -2380,6 +2416,15 @@ nm_device_class_init (NMDeviceClass *klass)
g_object_class_override_property (object_class,
NM_DEVICE_INTERFACE_PROP_MANAGED,
NM_DEVICE_INTERFACE_MANAGED);
+
+ signals[AUTOCONNECT_ALLOWED] =
+ g_signal_new ("autoconnect-allowed",
+ G_OBJECT_CLASS_TYPE (object_class),
+ G_SIGNAL_RUN_LAST,
+ 0,
+ autoconnect_allowed_accumulator, NULL,
+ _nm_marshal_BOOLEAN__VOID,
+ G_TYPE_BOOLEAN, 0);
}
static gboolean
diff --git a/src/nm-device.h b/src/nm-device.h
index 9084816..b230da8 100644
--- a/src/nm-device.h
+++ b/src/nm-device.h
@@ -159,6 +159,7 @@ void nm_device_activate_schedule_stage4_ip_config_timeout (NMDevice *device);
gboolean nm_device_deactivate_quickly (NMDevice *dev);
gboolean nm_device_is_activating (NMDevice *dev);
gboolean nm_device_can_interrupt_activation (NMDevice *self);
+gboolean nm_device_autoconnect_allowed (NMDevice *self);
NMDeviceState nm_device_g
Re: [Sugar-devel] poor man's mmap "sliding window" on Python 2.5.x
On Wed, 2009-07-08 at 15:23 +1200, Martin Langhoff wrote: > Had some time to retest this on the plane, and I think it was > mis-diagnosis. The original code I was testing is lost. In re-testing > this I find that the problem is more nuanced, and I may have been > wrong: looking at 'top', the kernel does not appear very eager to > discard old mapped pages. You can probably influence this by marking the ranges that you're done with with madvise(). Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar + OLPC mesh network selection logic
On Wed, 2009-07-01 at 12:18 -0400, Dan Williams wrote:
> > http://dev.laptop.org/~sjoerd/NM0.7/olpc-mesh.fdi
>
> Though you're really not going to want to use HAL fdi files for this,
> since master now uses only udev. You'll either want to hardcode the
> Marvell device IDs into nm-hal-manager (or match on "mshX") or you'll
> want to tag it with udev rules and grab the property from NM instead.
OK. I think udev rules is nicer. Do you think such rules should be
shipped within NM, or in udev itself?
The rule is currently:
KERNEL=="msh*", SUBSYSTEM=="net", DRIVERS=="usb", ATTRS{idVendor}=="1286",
ATTRS{idProduct}=="2001", ENV{NM_DEVICE_TYPE}="olpcmesh"
I don't know why we can't match on DRIVER=="libertas" (it's blank, must
be a libertas bug) so it's a bit messy. Also soon we will be adding
another rule since the XO-1.5 will come with wifi on SDIO.
Thanks,
Daniel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Nobody understands "Keep"
Hi, Nobody in the world seems to understand the Keep button. People think it's for regular saving and you should do it before you close or switch away from your activity. Even with all the expertise on-site they seem to have been advising the (incorrect) use of the Keep button here: http://lists.sugarlabs.org/archive/iaep/2009-July/007038.html and then they wondered why they had 2 copies in the Journal. I have seen misuse of this button by the country teams in Ethiopia and Paraguay, in both cases they were giving teacher training and teaching the teachers the wrong thing... Perhaps it's time for a rethink/redesign. This functionality could be moved to the journal itself, in a place where it can be presented with more context, something like "Create duplicate copy." Or even some kind of visual feedback (to appear after clicking Keep) that makes it pretty obvious that you've just forked your work - that way you'd quickly learn the true functionality and know when and when not to use it. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Nobody understands "Keep"
On Thu, 2009-07-09 at 10:45 +0100, Martin Dengler wrote: > On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote: > > Nobody in the world seems to understand the Keep button. People think > > it's for regular saving and you should do it before you close or switch > > away from your activity. > > That's not far from the truth, right? At least in any work-losing or > surprising way... It's far from the truth in that it's not normally what you want to do. To save your work, simply click the Stop button or change so that another activity has focus. If you click Keep, you'll end up with 2 copies - one from when you clicked Keep, and one from when you clicked Stop (or focused on another activity). As far as I understand it, Keep is useful for these types of scenarios: - you've done a lot of work but now it's time to refactor/reorganize the whole thing. However you want to keep a copy of the rough version you have now, as "insurance" or perhaps for reference while you re-mangle the work. - you've made a template for something, now you want to save that template (as a blank template) before starting on a version where you fill in the content. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] updating from aslo
On Wed, 2009-07-15 at 10:17 -0500, David Farning wrote: > Attached is a very early prototype of a sugar updater which pulls from ASLO. > > It kind-of works on jhbuild;-/ To test, unzip and drop it into > sugar-jhbuild/install/share/sugar/extensions/cpsection. > > run using 'install/share/sugar/extensions/cpsection/updater/model.py' > > Big Issues: > The GUI interface is reporting a network error. I personally feel that this kind of approach is not a great idea, but I suppose it depends who your target users are. This type of setup seems inappropriate for low-bandwidth/high-latency OLPC-style deployments, since it seems to rely on the internet. Unless you're suggesting that people run the updates website on the school server, in which case xs-activity-server would need to be reworked into that, or an alternative solution developed which does not require deployers doing too much setup. The current updater has some nice properties in that the microformat is simple, the surrounding infrastructure is in place for deployments (use xs-activity-server, or maintain a .html file), and that at least with this patch it will operate very well even without internet access: http://dev.laptop.org/ticket/9259 Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] updating from aslo
2009/7/16 David Farning : > A possible answer would be to abstract ALSOParse.py and microformat.py > as back ends for Sugar-Update-Control (SUC). It's not so much the issue of losing support for the existing widely-deployed setup (although that would be unfortunate), it's that this seems to lack design. The microformat-style update (along with certain characteristics of the updater and server implementation) is not perfect, but it is good for field use and "G1G1" style internet users. The motivation for moving to "aslo" seems to be only that of "because it's running on sugarlabs.org," without consideration for any technical pros or cons of the different format, how it might be deployed in the field, etc. I think you should take a more detailed approach to this, without limiting yourself to the quirks and current behaviour of the aslo code. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Duplication of Effort: Don't do it.
2009/7/28 Tomeu Vizoso : > Regardless of what I said, I think your point of increased memory > usage is a valid one and the community should voice its opinions on > this trade off. My opinion: - Focusing resources on different technologies like this is a distraction - It's an unjustified effort; I don't see lack of KDE software or lack of pygtk-capable developers being a hinderance to the mission of education - It will cause resource usage to increase, so it should be avoided. (there is no need to measure this, as there is no doubt that it will be an increase. we should be working exclusively in the opposite direction) Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity as regular objects proposal
2009/7/28 Aleksey Lim : > The problems that 0.84 has in case of activity versions are: > > * it can't upgrade activities if they were pre-installed from > native packages; it makes process of upgrading activities > from .xo impossible In reality Sugar's message is confusing here and I don't think any distributor will mix-and-match the two ways of installing activities. (either they'll use distro packages and disable .xo, or they will exclusively use .xo e.g. OLPC). This is a larger problem and I don't think yours is a solution, since it will result in wasted disk space and we still end up with the confusion of how activities can be installed and which one is being used. > * sugar can have only one activity version installed at the same > time i.e. it could be useful to have several versions > simultaneously e.g. to start proper version when join request > arrived(activity version of arrived request could be different > to installed version) I think this calls for wider discussion. Having multiple versions of the same activity installed sounds silly. Instead, activity designers should be encouraged to strongly avoid making backwards-incompatible protocol changes, just like the principles of any other software designer. Once everything is compatible, this problem goes away. Sugar should continue to make no promises about interoperability between different major releases (e.g. no promises about 0.82 talking to 0.84) and hence if it is necessary, activity developers are allowed to break compatibility once every 6 months, which should be more than enough. Finally, I personally don't like the idea of having activities (as in applications) in the journal. The journal is for recording what the user has done. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity as regular objects proposal
2009/7/28 Aleksey Lim : > Proposal is not about storing all versions but about possibility of > storing not only one(last?) version and we can uninstall old versions > by removing entries from journal. The journal can't delete activities that are installed by a package at /usr/share/activities, and I also think it is unlikely that our users would realise to do this even if it were possible. > There is no confusion, sugar is aware of what versions of particular > activity it has by using datastore.find() method, so user can run > `rpm update`, install any version by downloading .xo and sugar will run > last version(when user create new activity instance) or run particular > version(if activity object requires it). I was referring to confusion by deployments and those who are diagnosing bugs and soforth. > btw, activity can declare, in activity instance object, what activity > version(range) should be used with this particular instance object. Sounds like overcomplication. In response to your question on how I think it should be done, I feel that it's time to admit that packaging activities in this way is a mess. We should leave packaging and the related complications to the experts - packagers, and the package manager, and then we can stop wasting our time on it. For some kind of cross-distro package manager compatibility, someone recently raised the idea of PackageKit which seems well worth investigating and given its rapid development can probably be adapted to our needs. IOW I feel that the concept of sugar providing prepackaged binary activities should die. I think you would be a good person to work on this, and it is an interesting problem. > Well we can't say to activity developers that they must write > backwards-incompatible activities otherwise we won't host them on ASLO. > In that case using compatibility ranges of versions could fix problem > (w/o obliging developers write complicated code for > merge/support-backwards-incompatibility). It's nice to have the freedom to post whatever I want on ASLO and I'm not saying that should change. I'm free to write a buggy activity or one that isn't sugarized and post it on ASLO. Even though my activity is low quality and doesn't fit into the desktop, I'm welcome to post it. The consequence is that my activity probably won't be included in deployments, and I'll get some mails from testers making suggestions how I could improve it, and maybe even some patches. I'd say that this case is no different. > I like this idea only if all sugar users have 100% access to internet. > And they can run "upgrade my 0.82 to 0.84 from internet" process by one > click. But imho thats impossible in case of educational infrastructure > around of the world. The responsibility of keeping all machines in sync can be handled by the deployments, with the aid of good tools from Sugar/distro/OLPC. This is how it already works in the field. It's not your problem, but you could certainly help improve those tools and their concepts which seem a bit neglected right now. > imho activities are the same kind of objects - user should have chance > to edit/hack/share them like other sugar objects. Good point, but this seems to be beyond what sugar is capable of at the moment and raises more questions. Perhaps once there is the ability to modify your activity within sugar, the development activity could offer functionality to package up the modified version and save it in the journal. Exactly how the user could modify activities, how the user-modified activity would be saved on-disk alongside the original one, how they would be differentiated in the UI and how the user could switch between the two seems to be out of scope of this discussion -- or at least I can't see how it would be covered by your proposal. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] community influence on development
quoting Tomeu from another thread (with no bad feelings at all): "Sugar Labs has currently no resources to focus on anything, it depends on volunteers doing whatever they want. I chose to spend my time to make easier for more people to bring their knowledge and experience to Sugar and the community has no say on this." Perfectly reasonable answer and this kind of development model works well for open source projects, including this one. However, I feel like it could be better if the community (who I might even stretch to call "customers") could have more influence. so..to create an open thread: What are the options for the community having more of an influence here? One would be to somehow get sugarlabs to hire people, and somehow process "customer" feedback and assign technical tasks to payroll developers. Are there others? Having now visited 3 large deployments I feel frustrated that most of the features and changes entering sugar are not increasing deployability or increasing the educational impact of the platform. General technical and usability improvements are always needed (and are always of value) but I feel that the balance is wrong and I feel that I have not been very successful in getting community members to understand the needs of deployments. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] community influence on development
2009/7/29 Walter Bender : > Daniel, could you start the ball rolling by being more explicit about > some specific unmet needs of deployments that might be actionable? OK, where should we make such a list? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] will the one true browse please stand up?
2009/7/31 David Farning : > On Thu, Jul 30, 2009 at 8:37 AM, Joshua N Pritikin wrote: >> Can a person in-the-know assemble a browse-103 release with all the most >> recent bits? > > It looks like Simon has release browse 103 on activities.sugarlabs.org > http://activities.sugarlabs.org/en-US/sugar/addon/4024 > > Would you mind testing that package? That's for Sugar-0.84. Here's the one you want: http://dev.laptop.org/~dsd/py-activities/Browse-102.xo this is the one on the OLPC 8.2 G1G1 activities page. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] will the one true browse please stand up?
2009/7/31 Joshua N Pritikin : > OK, I figured out the problem. > > In fact, I was trying to install precisely that version of Browse-102 > (sha1sum 258861e353d32134128be834889f3bd5368d2297) since the beginning. > > However, I was using a customization key in an attempt to upgrade > Browse. Apparently, the customization key can only add new activities > and does not upgrade activities. Is this a bug? At a minimum, some > clarification is needed on the customization key page: > http://wiki.laptop.org/go/Customization_key It upgrades them just fine. In fact, all it does is a "stupid" unzip on all the .xo bundles it can find, meaning that it'll also do downgrades. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] will the one true browse please stand up?
2009/7/31 Joshua N Pritikin : > That was not my experience. Where does the customization key code live > in GIT? Here: http://dev.laptop.org/git/users/mstone/irfs-udebs/tree/src-olpc/init?h=unpack-bundles ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] safer customization key (was Re: will the one true browse please stand up?)
2009/7/31 Joshua N Pritikin : > On Fri, Jul 31, 2009 at 03:52:06PM +0545, Daniel Drake wrote: >> 2009/7/31 Joshua N Pritikin : >> > That was not my experience. Where does the customization key code live >> > in GIT? >> >> Here: >> http://dev.laptop.org/git/users/mstone/irfs-udebs/tree/src-olpc/init?h=unpack-bundles > > Well, I'd feel a lot better if prior to the unzip you added something > like: > > if ext == '.xo': > dest_dir = re.sub(r'\-\d+\.xo$', '', f) + '.activity' > shutil.rmtree(join(tgt['.xo'], dest_dir)) > > I know this does not work as written because the filename can (and often > does) mismatch unzip's idea of the directory name. Any idea how to get > directory prefix from the zip? The customization key has always been sweet and simple like this; I don't suggest changing it as some deployments rely on this. Documenting the limitations would be sensible, though. In my opinion the real solution is moving away from .xo which has outgrown its original design... Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] safer customization key (was Re: will the one true browse please stand up?)
2009/8/1 Tomeu Vizoso : > What do you propose doing? Leaving packaging to the experts (the distributions) and focusing on being a good upstream -- only stepping into the packaging areas where the distro people are lacking. I think activities should be packaged by distros and we should use their standard systems, which have already solved this class of problem 5 times over. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] About the need for .xo bundles (again) (was Re: safer customization key (was Re: will the one true browse please stand up?))
2009/8/1 Tomeu Vizoso : > They haven't solved the problems we want to solve and are probably not > even interested in trying. I'm a bit suprised you are not aware of > this, there was a whole session dedicated to this in the last FUDCon > in boston. Anyone has a link to the minutes? Which problems are those? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Local Collaboration with an ethernet bug 1113
2009/8/3 Caroline Meeks : > Please point me to the documentation a sysadmin would need to read to know > how to set up local collaboration and how it works. Without a jabber server, it is designed to "just work" with no configuration. It uses multicast apple-style zeroconf through avahi. Some first things you could try: 1. check that the machines are on the same IPv4 subnet 2. see if they can see each other with avahi (avahi-browse, avahi-publish, etc) 3. see if you can get any multicast transmission between the machines at all, using something low-level e.g. http://www.venaas.no/multicast/ssmping/ Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] F11 for XO1 - Fonts
2009/8/4 Tomeu Vizoso : > We could make it a GConf property if it's really needed, but as you > already know, I think we should have all the UI use a default of 10 > and solely use Xft.dpi to scale it up and down. We don't need to > discuss this now again, though. I would like to discuss it. In my opinion, artificially adjusting DPI is the wrong answer. Is there room for change? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] F11 for XO1 - Fonts
2009/8/4 Tomeu Vizoso : > Ok, what do you propose? A method to specify the font size (measured in points). This should be geared towards deployments, so it should be something that can be pre-set in global configuration, or customized through files that are not in conflict with files provided by packages. That way OLPC can provide a configuration which just sets size 7 or whatever. And if there is interest in exposing this to the user, I would say it should be kept as simple as one button that makes the fonts get bigger, and another button that makes them get smaller. Those buttons would not mess with DPI, they would just increment or decrement the font size. I'd be happy to write that into a ticket if you don't hate the idea :) Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] F11 for XO1 - Fonts
2009/8/4 Tomeu Vizoso : >> A method to specify the font size (measured in points). > > What font size would be that? That would be up to the deployments. For example, OLPC would choose 7. > I guess we should, for improved accessibility. And would be convenient > if the paddings, line widths, icon sizes, etc also scaled accordingly > (may not be possible with current gtk+). Not yet, but there are ongoing efforts to create an overall "scale factor"-like system that will be nice. > I don't hate it in itself. But I need to know better why using Xft.dpi > is not a good solution (real technical disadvantages) and which > mechanism uses gtk+/gnome so we can reuse their work there. It's going against an established system that ensures that fonts of the same point size are the same physical dimensions when shown on different screens and on paper. To me it also just doesn't make sense... if the fonts are too small, then the logical thing is to use bigger fonts, not to start pretending that you have a screen with different characteristics from the one that you are using. This would also be important to deployments where technical resources are lesser - at least to me, thinking of font size in terms of the size of the font (a familiar concept to MS word users!) is much more logical than thinking about the number of pixels in a square inch on the display on which the fonts will be rendered. (for example, for someone unfamiliar with that line of thinking, it is not obvious whether you should increase or decrease the DPI in order to make the fonts bigger) Freetype visually optimizes the font renderings based on the DPI and sometimes gives odd-looking results when the selected DPI is not that of the actual display. (ever seen the subpixel rendering option result in worse appearance than before? this is usually the cause) It also will confuse any applications that make calculations based on the DPI of the fonts against the millimetre-width of the screen -- although these are not that common. GNOME use this same kind of approach. GNOME ships default font sizes and has an "Appearance" dialog with a fonts tab that lets you increase or decrease the font size. KDE is similar. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] F11 for XO1 - Fonts
2009/8/4 Tomeu Vizoso : > I meant to ask to which UI elements this font size would apply to. All of them, the same way that the currently written "10" value does. > That's all ok, but how do you see us moving from using Xft.dpi (that > today can get us font sizes that look good on several systems), to > font sizes to achieve the same? I don't see how it differs. At the moment you are telling people to falsify a dpi of X in order to get more readable fonts. Now you will just ask them to specify font size Y. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Deployment feedback braindump
Hi, In response to the thread I started recently about feedback from deployments, I've been thinking a lot about specific changes/features that would be a big help for deployments. And even though it only takes 10 minutes in a classroom to see some real potential areas for improvement, actually I am finding the task of selecting a few important features/bugs/changes very difficult, and I keep coming back to various broad questions and loose ideas about Sugar's direction, goals, and SugarLabs' roles. So I'm afraid that I'm creating another vague, broad and fluffy discussion without any real immediate technically actionable items, but I'm going to try and put my thoughts into writing anyway. Suggestions on how to make some of these ideas actionable would be appreciated. I fully understand that nobody can really define Sugar's direction at the moment since it's all volunteer time, but hopefully we can at least get some objective things written down which will possibly feed the motivation of our valued hackers. I'll start with roles. Sugar was born inside the belly of OLPC, and SugarLabs was born out of OLPC, effectively taking some roles of OLPC and further opening them to a community. So, in terms of roles, you might look at this as OLPC being top of the food chain (I'm referring to the times when OLPC had a substantially larger technical team), with SugarLabs below doing some specific subset of OLPC's earlier work (i.e. developing the UI), and finally deployments below being the consumers. But actually I think it makes sense for this model to be considered differently, as follows: SugarLabs is the top of the chain, it is the upstream that generates the core user experience. One step down, OLPC as an implementation specialist (again referring to the time when the development team was more substantial) takes Sugar from upstream, makes some small customizations to fit the OLPC mission, and fills in some big gaps of OS development and support, deployability and scalability, distribution, hardware work and software to support such hardware, user support, etc. Then the deployments feed directly from OLPC, not sugarlabs. In this model, OLPC performs a huge chunk of support for sugar's users. I think this model was working reasonably well (and was improving over time) but the middle layer (OLPC) has now changed to the point where it is not performing many of the roles mentioned above, or at least not in much capacity. So who can take over this work? It is certainly very important. My gut feeling is that SugarLabs should - but that really is only because (1) a number of the OLPC people who would be involved in the above roles are no longer OLPC people, but they are still sugarlabs contributors, and (2) there are no other good candidate parties that I can think of, so I naturally have desires that the one that I do know of pick up the work ;) These might not be considered good reasons, but it seems that sugarlabs was "designed" with the consideration of having OLPC performing a great deal of support on its behalf, and I don't recall seeing any proposed change of SugarLabs' direction in response to OLPC's recent restructuring. I've only written about OLPC so far, although it's clear that SugarLabs is aimed at a broader audience. And in persuit of these efforts, SugarLabs has started muddying the waters by taking on (in small scale) some of OLPC's prior roles -- namely becoming a OS builder (e.g. SoaS) and a deployment implementer (e.g. GPA). Sometimes I even see hints of broadening even further, for example, in a SoaS meeting recently I saw some interest in SugarLabs becoming involved in improving Linux support for hardware chipsets -- a problem that half the friggin' world is already working on. So: which roles is SugarLabs trying to fill? Although I know that SugarLabs is trying hard to broaden beyond OLPC deployments, I'm going to throw in a couple more comments along OLPC-specific lines anyway: if SugarLabs is going to continue to be a deployment implementer, i.e. doing anything and everything required to make places like GPA "work," then I would encourage the interested people to not forget about OLPC deployments. With a bit of determination, it is possible to get yourself to these places. And with a reduction of support from OLPC themselves, they would really benefit from your help. Unlike most new Sugar deployments they have often already solved various problems related to logistics, finance, politics and scale, so you could focus directly on the Sugar experience. The next item that keeps coming up in my thoughts is that of aims and objectives for the platform, in a technical sense. OLPC still has a set of 5 clear principles that have stuck from early on, and have really really really taken root at deployments. I was always impressed with OLPC's focus on considering the scalability of any new technology entering the platform (i.e. we're going to be replicating this A LOT - will it work in numbers
Re: [Sugar-devel] multiple activity versions installed simultaneously (was Re: [Bugs] #1042 UNSP: cannot install new activity version)
2009/8/10 Tomeu Vizoso : > Hi, > > any opinions on this? I dislike the idea of having multiple versions installed at once. The argument I saw for this case was that different versions might have incompatibilities in their collaboration protocols, but I feel that we should instead stick to standard software practices of not breaking network-exposed APIs during a stable cycle. If people choose to break it, let them pick up the pieces. Are there other reasons? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] multiple activity versions installed simultaneously (was Re: [Bugs] #1042 UNSP: cannot install new activity version)
2009/8/10 Martin Dengler : > Learner-generated activity patches, perhaps? Like, we're under a tree > and here's my patched Terminal/Pippy/Speak that you may want to try > but not commit to blowing-away your "official" version... Do we have the relevant tools/interfaces/activities to make this possible and realistic? What are the user interfaces like when dealing with multiple activities? If I click on a new version of an activity in browse, does it upgrade the one I have or install it in parallel? How do I erase old versions? When I click the activity from the home screen, which version gets launched? Having user-modifiable activities like this is a nice idea, and laying the groundwork to make it possible could also be sensible, but right now it seems like we aren't ready and the reason for the introduction of this code is/was for unrelated reasons. I also feel that this functionality would rarely be used in the field. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Deployment feedback braindump
Hi Tomeu,
2009/8/10 Tomeu Vizoso :
> Hi,
>
> some thoughts follow. Please keep in mind that these are just my
> personal opinions and that not everybody at Sugar Labs share the same
> idea of what SLs is or should be.
Thanks for the response.
What you are saying makes sense -- it is indeed a nice idea to keep
SugarLabs as more of a loose structure, as a place for collaboration
on anything that might further the general mission.
It is a sensible idea to keep SugarLabs away from doing too much work
on the OS building and deployment implementing side of things, because
as you point out, even when you exclude those broad topics there is
still a lack of resources on the bits that remain.
That said, in a way, the "gap" that we're discussing is in some ways
more important than any of the Sugar features currently being worked
on, because the large majority of sugar users are currently a long way
away from even having access to the features that were finished 6
months ago. Difficult.
I disagree about local labs being key to filling the gap. While a nice
idea, I think it is necessary for there to be a central and
location-independent deployment-focused upstream, otherwise there will
be a lack of coordination accompanied by lots of duplication of work.
Local labs need to feed into something bigger, which doesn't currently
exist, although it could probably sit under the realm of sugarlabs if
the right people were to step up.
Also, when talking of scale, I am a little wary of local community
efforts because they have previously proven disruptive to deployments.
The sad reality is that you absolutely require more of a NGO or
business setup to be working with the relevant authorities. And when
this happens, the community efforts automatically become a bit
distanced. For example in many of these places, the "official"
organisation receives permission from the government for their staff
to enter government schools - but only their staff (not community
volunteers).
You mention lack of involvement and feedback from deployments -- why
do you think this is?
Here are some of my thoughts:
- The majority people we're working with are alien to the idea that
they might be able to talk to the people who are writing the software
that they are using. Since when has anyone been able to do that? Us
open source people are still the oddities in the world.
- People are afraid or mythed by the idea of this stuff being public
and global ("why would I want my feedback to be public?"), and are
confused/challenged by mailing lists.
- The people most able to give the kind of feedback you are looking
for are the teachers, who are probably even more distanced from these
ideas. Many will lack connectivity and english language skills.
- Many people who support the project with technical skills (e.g.
Linux) come from purely academic backgrounds which means they
understand the technical stuff well, but have little interest,
experience (and sometimes ability) to become good community members.
To put it plainly: in my opinion, wishing for substantially more
involvement from deployments is not realistic. SugarLabs would benefit
from being proactive here, especially by using the telephone rather
than email to contact deployments, but this is of course subject to
the "where are the resources?" question. Hopefully over time a
proactive approach from our side would likewise encourage a proactive
approach to communication from the deployments, but I suspect we'll
have to be patient. and yes, this makes your job pretty difficult.
> On Sun, Aug 9, 2009 at 19:41, Daniel Drake wrote:
>> At least from what I have seen, this kind of clarity seems to be
>> missing from discussions that define the Sugar platform nowadays, as
>> well as in the code that is flowing through the system. Does SugarLabs
>> still have a high degree of interest in bigger-than-you-can-believe
>> deployments in remote and really difficult parts of the world on
>> low-spec hardware, or are we moving towards looking at occasional
>> 30-student deployments on powerful computers in schools along the
>> Charles? Or are we trying to do both?
>> Are we still focusing on 6-12 year olds or has that changed?
>
> How do you expect that the SLs volunteers know what OLPC deployments
> need if they don't voice their needs? If you look at the Sugar commit
> logs, you will see that almost all commits are from someone sitting in
> a room somewhere in Europe, working on their free time. By which kind
> of epiphany do you expect them to know what's best for OLPC
> deployments?
I think you misunderstood my position here. I am personally having
trouble trying to formulate this kind of feedback because I no longer
know what is important to Sugar. Maybe it is a personal
misunderstanding, but after seeing some recent discussions and
features I
Re: [Sugar-devel] multiple activity versions installed simultaneously (was Re: [Bugs] #1042 UNSP: cannot install new activity version)
2009/8/10 Martin Dengler : > Do you propose SL explictly not support this (closing the bug as > WONTFIX or something, presumably) and - separately - let it be a > goal/feature request once there are sponsors? That seems sensible to > me. I'm a bit confused as to the current situation. The bug seems to suggest that we have some half-baked code already in sugar for supporting activity versions. I think that was added recently, but with a design focusing on fixing something other than supporting kids modifying activities under a tree. So I think the first thing to do is to clarify why having multiple versions is interesting and evaluate the reasoning and design of that. I don't think we yet have a design for the kids modifying activities thing, so I agree that should be left til later. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Candidate "paper cut" bugs for a new 8.2.x release?
2009/8/11 Martin Langhoff :
> In the _completely hypothetical_ case that I had some time and chance
> to spin a 8.2.x release aimed at fixing the "paper cuts"[1] and
> low-risk bugs that hinder XO-1 deployability _today_ in the field -
> have *you* got any candidates? Tell me about them :-)
I think doing a release is more work than you would think... but nice idea!
Here's a list of things deployed in Nepal, Paraguay, both, or soon :)
Some of these are hacks, lower quality than you'd want to see in an
official build, but very valuable at the same time.
http://dev.laptop.org/ticket/9246
http://dev.laptop.org/ticket/9289
http://dev.laptop.org/ticket/9248
http://dev.sugarlabs.org/ticket/362
http://dev.laptop.org/ticket/9250
http://dev.laptop.org/ticket/9259
http://dev.laptop.org/ticket/9288
http://dev.laptop.org/ticket/8104
http://dev.sugarlabs.org/ticket/1151
http://dev.sugarlabs.org/ticket/1152
http://dev.laptop.org/ticket/7531 (fixed in new bootanim)
first boot "upgrade your activities" notice is v confusing for first time users
sed -i -e 's/\.sugar-update/\.sugar-update-hackedout/g'
${pristine}/etc/init.d/olpc-configure
upgrade to abiword-2.6.5-2.olpc3 (built ages ago but never shipped by
OLPC) to fix problems with scripts such as nepali and arabic
(there are still a couple of nepali bugs so watch out for a -3 release
in the next week or so)
That's all I can think of for now
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] Ad-hoc networks - New Icons
2009/8/11 Simon Schampijer : > I think it would help, to have a new icon for the ad-hoc network to > distinguish them. Could be a badged wireless network one? Or is the mesh > icon appropriate? Or something completely new? I think new icons would be best, to distinguish from the mesh. I think we can expect mesh support again soon ;) Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] Ad-hoc networks - New Icons
2009/8/11 Simon Schampijer : > From the user POV they are the same I guess. A local network, that does not > need any infrastructure. I disagree. The mesh connections are automatic, and the presence of them does not indicate the presence of another computer like an ad-hoc network would do. Also, they do not have the principle of ownership that sugar places on ad-hoc networks. The behavioural properties of the networks (including the likelihood of communication) are different because there is no forwarding of frames. Also, neighbouring but sleeping laptops will not forward frames on an ad-hoc network. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Candidate "paper cut" bugs for a new 8.2.x release?
2009/8/11 Paul Fox : > one thing we've recently realized that would be very low risk > would be to change the "xset" command in /usr/bin/olpc-session > from "xset 7/4 0" to either "xset 7/6 0" or "xset 7/4 1". What effect does this have? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] Ad-hoc networks - New Icons
2009/8/11 Simon Schampijer : > I wonder if the ad-hoc network will scale up to that number of users :/ > Though I am not an expert in this area. Maybe Daniel has some more > insights on this topic. Yes. Ad-hoc networks do not scale at all because they are range limited. They also act quite odd in terms of networks because you frequently have situations where C can see A and B, but A and B are unaware of each others presence. This will lead to funky situations where C could share an activity, A and B could join without problems, but any actions by A would not be seen by B and vice-versa. The basic philosophy behind ad-hoc networks is "shout unless someone else is shouting" which also ends up causing various network splices and merges thanks to the poor quality of radios in the world, and interference. In short, ad-hoc networks are not reliable (especially when there are more than 2 participants) and are very quirky. It is a nice feature to have in sugar but it is not something that should be created automatically since in many cases they will just waste airtime for reliable networks and cause headaches for users. Automatic infrastructure-less networks are still very desirable of course, and the best solution that I know of for that would be open80211s which needs work done lower in the stack before it can be directly usable by sugar. and we're miles off topic on a thread about icons.. sigh Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] Ad-hoc networks - New Icons
2009/8/11 Benjamin M. Schwartz : > I am becoming very confused. Why does Sugar place an ownership concept on > an ad-hoc network? Just in principle. Have you tried it? Create a network and it will be called "Ben's network" I'd be relatively confident that I could find Ben on that network. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] Ad-hoc networks - New Icons
2009/8/11 Benjamin M. Schwartz : > Hmm... so if other people join that network, and then I leave, does the > network not persist? I haven't experimented with this yet. yes, it will persist ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] Ad-hoc networks - New Icons
2009/8/11 Peter Robinson : >>> Hmm... so if other people join that network, and then I leave, does the >>> network not persist? I haven't experimented with this yet. >> >> yes, it will persist > > Really? My understanding of the ad-hoc network is that it basically > puts the user that creates it wifi card into ad-hoc AP mode and that > machine basically acts as a AP and link local IPs are used. Yes, really. As an IBSS station you are responsible for attempting to send 10 beacons every second (including randomized backoff timer), but cancelling each one if you hear another beacon beforehand. Therefore in a nice RF environment, one person is the beacon sender sending 10 beacons every second (the station with the fastest clock) and the others continually cancel their own beacon transmissions just before they are about to transmit their own. When the beaconing station goes away, in theory the person with the 2nd fastest running clock sends a beacon and then continues. the other stations in the set hear that and keep synchronized. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Design] Ad-hoc networks - New Icons
2009/8/11 Gary C Martin : > H. Are you sure this is an accurate statement? I was under the > impression that mesh forwarding support had been removed/disabled from OLPCs > implementation a long time ago, since soon after the Mongolia deployment. > Mesh was killing the wireless spectrum with all the attempted packet > retransmissions. It is really only 'mesh' in name, all devices have to be in > range of each other to collaborate. Yes, forwarding still happens. And the mesh does scale quite well for sparse setups (its original design). It also works quite well in dense setups (e.g. classrooms) in that it allows reliable communication between about 15 nodes -- that's about 13 more than we were able to do reliably with the other infrastructure-free networking option (IBSS/ad hoc). of course, classrooms of that size (that are additionally RF-space isolated from other XOs) are not very common so we need other solutions there. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Re: #1157 HIGH: Show which jabber server to which you are connected
2009/8/12 Tomeu Vizoso : > Any opinions? Every other deployer thinks this is a good idea? Yes. OLPC deployments have historically had this tool in the form of olpc-netstatus which is indeed very useful. Sugar should provide an equivalent. I wouldn't say it's important to expose in the UI itself, but if you want to go that route then 2 places would spring to mind. First would be some kind of visual indiciation or mouseover of the school server when we display it on the neighborhood view (long term design proposition but never implemented), and the 2nd one could be in the palette for the network view. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Re: #1157 HIGH: Show which jabber server to which you are connected
2009/8/12 Bernie Innocenti : > Are you the current maintainer of olpc-utils? I used to be, but now I > don't feel like I have enough spare cycles to work on it. I think so, but I don't have the time either. However I get the feeling that olpc-utils is already XO-specific, or very nearly. olpc-netstatus came from another package, I'm not sure which. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] (Ab)using the Journal for stuff that the user didn't do, create, or access
2009/8/11 Tomeu Vizoso : >>> You mean that you cannot open that library bundle by clicking on its >>> journal entry? >> >> Correct me if I'm wrong, but none of the methods that could be used by >> deployments to distribute materials this way in mass would result in a >> journal entry appearing for their users. These methods are installing >> through a package into /usr/whatever/library or unzipping into >> ~/Library. > > Didn't thought about pushed updates, can they execute post-install > scripts? If so, they could use copy-to-journal. This only works when there is a journal created, so deployers would have to hook into the exact moment after the user types in their name and chooses colours as this is the earliest time when the journal is created. Doesn't sound sensible. This also wastes disk space as it results in 1 copy of the library bundle in the journal, and another copy uncompressed on disk. And am I the only one who feels like this is a role for the Sugar shell and not for the journal? I've seen this kind of Journal-based solution proposed for a couple of problems now, and I'm not keen on it. At least until this point, the journal has been for recording what the user has done, created, or accessed. With this kind of approach, we'd now be going into classrooms asking users to look for something in their journal which they've never seen before, and has never been a part of their interactions. I much preferred the previous trail of discussion which was that content would be treated as the same class as activities -- i.e. we'd be extending the home screen somehow, to deal with potentially lots of activity icons, or to become additionally a hub for opening any books that are saved on the system, or something like that. In other words, moving the functionality of olpc-library directly onto the home screen. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] multiple activity versions installed simultaneously (was Re: [Bugs] #1042 UNSP: cannot install new activity version)
2009/8/11 Gary C Martin : >> What are the user interfaces like when dealing with multiple >> activities? > > Well, we have this already, it's called the Journal. Just download Activity > bundles and they all live there (and have done as far back as I can > recall)... > >> If I click on a new version of an activity in browse, does >> it upgrade the one I have or install it in parallel? > > It downloads the bundle to Journal and auto unpacks/installs, though this > may have been modified by a very recent patch I haven't poked at yet: > > http://dev.sugarlabs.org/ticket/1042 > >> How do I erase old versions? > > Delete the bundle form the Journal > >> When I click the activity from the home screen, which version gets >> launched? > > The last one that you installed (via either downloading in Browse or > clicking a bundle in Journal). OK - this all makes sense. But it all involves only 1 activity being installed at the same time, and simply having the bundles for other versions being present in the Journal. Maybe I'm reading the bug report wrong, but to me it seems to say that if Read ETexts v1 is installed (where installed = extracted on disk, icon on home screen, etc), and if we then click a link to Read ETexts v2, then that one *additionally* gets installed without the first one being removed. Right? Or maybe I misunderstood and the behaviour is supposed to be as before - v1 would get uninstalled, v2 would get installed - but it's broken? If we can't upgrade activities then that sounds like a valid bug, and unrelated to having multiple versions installed at once. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] F11 for XO1 - Fonts
2009/8/7 Tomeu Vizoso : > But not all text is rendered with that default font size. Do you have examples? > I was asking you about how we can get there, IOW which is the > suggested technical plan. > > We have today a solution that allows scaling the size of the text in > all of Sugar, so it can adapt to any display. You point out that this > approach has a downside as text whose size is specified in points > won't have the same physical size in different displays. > > I'm asking you what do you propose to fix that (doing so in a ticket > and/or feature page may be better). OK, I'll give it some thought. Probably just making a gconf setting would be the best approach, and that's also what GNOME does. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] (Ab)using the Journal for stuff that the user didn't do, create, or access
2009/8/17 Tomeu Vizoso : > I don't see where we disagree any of us OK.. so what do you suggest as the next steps? File a ticket? Start a feature page? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] F11 for XO1 - Fonts
2009/8/17 Art Hunkins : > I'm dealing with another issue as well - one that is equally important: 4:3 > va. 16:9 displays. All my text has to be on a single screen; but 4:3 screens > will display more *lines* than 16:9. What I'm trying to do is for my script > to query for screen size (Walter showed me how - thanks, Walter!), and > depending on the answer, compress some of the text so that it takes fewer > lines. > > As a result, my script will need to determine the following: > a) XO or not - result: set appropriate font size > b) 4:3 or 16:9 - result: set appropriate font size (there *appears* to be a > difference here, unfortunately - I've yet to figure out this disparity), and > adjust number of lines and/or font size for selected text. This is a bad approach. If filling the screen (or an area of it) is important to you, then you should render some text using the font and measure it's size, then adjust accordingly. Measure is one example of an activity that does this. Otherwise, the only thing that is safe to assume is that 1 point means 1/72 of an inch. This alone is meaningless though, you should also consider the size of the screen to see if that would feel proportionally OK, and you also have to consider how far you expect the user to be sitting from the screen. Size 10pt on the XO looks uncomfortably large, but measure it and you'll see that it's exactly the same size as size 10 on your regular monitor, where it looks fine. The difference is that the XO screen is proportionally much smaller and you generally sit closer to it. The approach I'm advocating here is that nobody is encouraged to mess with DPI (and Sugar does not touch this). Instead, Sugar ships a default font and size setting (e.g. Sans 10) but allows it to be easily overridable by deployments. Additionally the numeric part of this can be changed through 2 new buttons in the control panel: "Make fonts smaller" and "Make fonts bigger." But this has not been implemented yet. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] multiple activity versions installed simultaneously (#1042)
2009/8/17 Sascha Silbe : > Current behaviour: If v1 is installed and you try to run v2 from bundle, an > exception is thrown (=> nothing happens). > After my patch: If v1 is installed and you try to run v2 from bundle, v1 > will be removed and v2 installed. > > In both cases the actual version numbers don't matter - i.e. there's no > distinction between up- and downgrading. OK. So there is actually no discussion of "multiple activity versions installed simultaneously" here, it is simply that plain-old activity upgrade is broken. yes, this is a regression that should be fixed. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] moving Shutdown above Control Panel
Hi, Here in Nepal we're moving the Shutdown option on the home menu above Control Panel. It is now the top of our two-item menu (we have also removed Restart and Register) The reasoning for this is that Shutdown is needed much more often than Control Panel, so we want it nearer the mouse when the menu opens. Indeed, this menu is difficult for new users at lesat, who often have trouble moving the mouse cursor into the menu box itself (as it starts in the top left of it) and then maintaining the mouse inside the menu box while they move to the desired option. any interest in this change being made in sugar for everyone? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] F11 for XO1 - Fonts
2009/8/18 Martin Langhoff : > IOWs, I pine for this gtk+ v3 patch > > http://bugzilla.gnome.org/show_bug.cgi?id=546711 > > which was introduced with a very insightful discussion thread > > http://mail.gnome.org/archives/gtk-devel-list/2008-August/msg00044.html This was brought up earlier in the discussion. Yes, it's hopefully the light at the end of the tunnel. > see specially > > http://mail.gnome.org/archives/gtk-devel-list/2008-August/msg00068.html > > Hmmm. You guys are papering over this gtk shortcoming -- which is > bound to be confusing. Here's a candle for GTK+v3 Feel free to suggest another option that can be implemented today. I feel that my proposal is technically sound given what we have right now, given its simplicity. Don't mess with DPI, just let deployers select font sizes that look good on their target systems, and give the users 2 nice simple buttons: get bigger, get smaller. It's simple and won't eat much developer time. It will allow things to look ok on XO and other platforms as long as there is someone who can select a good default base font size. It also fits nicely into what would come with GTK+3 since you'd just swap the backend control from "font size" to "scale factor" (or whatever equivalent knob comes out of all those discussions). The idea of deployers being able (and often required) to select a good default will remain, along with a dead-simple UI for changing it. It will be also interesting to see what the css/html world comes up with. I've seen a few discussions recently, they too are challenged by being a platform that's spreading to vastly different displays. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] (Ab)using the Journal for stuff that the user didn't do, create, or access
2009/8/17 Tomeu Vizoso : > On Mon, Aug 17, 2009 at 12:52, Daniel Drake wrote: >> 2009/8/17 Tomeu Vizoso : >>> I don't see where we disagree any of us >> >> OK.. so what do you suggest as the next steps? >> File a ticket? >> Start a feature page? > > Feature pages, I would say. We have already some design proposals in > the wiki, but I'm not sure if they cover all we have mentioned in this > thread. OK I wrote down some thoughts here: http://wiki.sugarlabs.org/go/Features/Content_support ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] F11 for XO1 - Fonts
2009/8/18 Art Hunkins : > I'm thoroughly confused and frustrated. > > My POV: I'm authoring an Activity *today*. I'd like it to look good on all > XO and (other) Sugar on a Stick screens (monitors) *today*. I think you're out of luck then. You could detect the XO somehow and choose a good setting that works there, but as for all of the SoaS machines in the world, they all have different displays and there isn't going to be one default setting that looks good on them all (hence our discussion of making this customizable by deployers and users). Unless you want to place a personal guarantee that you'll purchase any display that any SoaS user is ever possibly going to use, before they use it. and even then you aren't considering the quality of the users eyesight or the distance they will sit from the monitor. > I am lukewarm at best to having a user option in Control Panel to make font > size smaller or larger. (Please count me as a -1 for this suggestion.) For > *my* activity, this would only allow kids to make text too small to read, or > possibly overflow the screen If the user clicks "make text smaller" to the point where the font is too small to read then that's their problem, not yours, and they'll hopefully realise that they can fix the situation by clicking the "make text bigger" button. If they make it so big that you run out of space in your activity, you could dynamically add scroll bars. If it really is important that you fill the screen with text without scroll bars, then your activity would be an exceptional case that ignores the Sugar font size setting, and instead dynamically calculates the font point size needed to make the text fill the screen nicely. > Basically, I strongly feel that *authors* - not users, not the system > (including upstream), nor even deployments - should determine their basic > screen layouts. "One size" certainly does *not* fit all; and any/all > defaults should be overridable by authors in their scripts. It should be the > *author's* responsibility to make their activities look right on various > monitors. I disagree. This is an impractical responsibility to pass on. However, activity authors can of course render any graphics that they like, at any size, including fonts. They do not have to obey the font sizes suggested by Sugar, as is the situation now (sugar provides one font size in the GTK+ RC and another in profile.py but you can actually use any font size that you want). Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] F11 for XO1 - Fonts
2009/8/18 Art Hunkins : > I write my activities on the XO-1, *for* the XO. I hope there is no change > of default font or font size for the XO series. If there *is* a change, my > activity won't look right, nor, I suspect, would other activities with > substantial text then we're in agreement on the main item of discussion here: a size 10 font should always be 10/72 inches, and we shouldn't encourage users to set fictional DPI values to customize their font tastes (which would break that assumption) :) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] F11 for XO1 - Fonts
2009/8/18 Martin Langhoff : > How about icons and other widgets? Scrollbars are fairly thin for example... We don't have a solution there yet. but this is about fonts. feel free to open a new thread about other stuff :) daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] constantly logged out of trac
Hi, dev.sugarlabs.org seems to log me out 60 seconds after logging in. Reproduced in firefox and epiphany, and also on windows by christoph. This makes it unusable because from Nepal it usually takes more than a minute to load a page on trac, so by the time you've tried to file a ticket or modify a CC list you are logged out again (and no ticket changes were made). Other trac's like dev.laptop.org work fine. can someone look into this please? or at least file a ticket for this issue on my behalf? thanks Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] moving Shutdown above Control Panel
Great, can someone file a ticket for this please? I can't as trac doesn't like me. Something like this; Summary: reorganise home menu description: As discussed on the mailing list: 1. Restart option should be removed - can't think of why this would be useful for our userbase 2. Shutdown should be moved to the top of the menu as it's the most common option I guess the larger changes mentioned here should be followed up with more discussion/design if we want them, but the above items can at least be done quickly. thanks, Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] moving Shutdown above Control Panel
2009/8/19 Daniel Drake : > Great, can someone file a ticket for this please? I can't as trac > doesn't like me. Something like this; http://dev.sugarlabs.org/ticket/1206 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Fix Sound activity
Hi, All OLPC OS releases including 8.2.1 have an annoying issue, where activities can trash sound mixer settings. The result is that all Sugar activities lose the ability to play sound (they are muted) and sugar's volume control does not fix it. And unfortunately this becomes a very common issue in deployments. Speak, Measure and/or Adobe Flash are my key suspects in messing with sound levels. Anyway, I've written an activity that restores the PCM mixer, which acts as a workaround for this bug. Simply run the FixSound activity every time you lose sound. http://wiki.laptop.org/go/FixSound The OS images being deployed in Paraguay and Nepal already have this bug fixed, and it is also fixed in the F11-for-XO1 builds that will hopefully reach deployment readiness in the not too distant future. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fix Sound activity
2009/8/19 Martin Langhoff : > Same thought -- what's the fix applied in the F11-based images? oops, I lied. It's not fixed there yet. Only is for XO-1.5, inside olpc-configure. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] F11 for XO1 - Fonts
2009/8/19 Art Hunkins :
> 1) With regard to the new user controls (bigger and smaller) in the Control
> Panel (or elsewhere):
> If I specify (in my script), e.g., set.property("gtk-font-name", "14")
> will "bigger" be an increment up from "14", or one up from whatever the
> default font size was?
It will always be size 14, which is about 14/72" in size.
The idea is that activity developers don't specify font sizes other
than using the default and, if they need to, and , so
they wouldn't do something like the above except for exceptional
cases. You may choose to be an exceptional case..
Daniel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] F11 for XO1 - Fonts
2009/8/18 Tomeu Vizoso : > On Mon, Aug 17, 2009 at 12:17, Daniel Drake wrote: >> 2009/8/7 Tomeu Vizoso : >>> But not all text is rendered with that default font size. >> >> Do you have examples? > > No, but I find it highly unlikely that all activities are using > sugar.graphics.style.FONT_NORMAL. then those activities are probably a bit naughty :) In most cases they should be basing their font selections around what sugar suggests, as this will now reflect the desires of the user. My ideas so-far including my thoughts on the above issue are here: http://wiki.sugarlabs.org/go/Features/Font_configuration Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Ad-hoc network UI feedback
2009/8/22 Gary C Martin : > 1) Is it a bug that there are 2 'grey circles' showing the same "Create new > wireless network" entry? It's acting as designed - showing the status of all the wireless devices it can find in the system. eth0 and msh0. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] F11 for XO1 - Fonts
2009/8/18 Tomeu Vizoso : > Yes, I would be happiest if we did the same that GNOME does. Do you > know how widgets change the font size in response of changes to the > gconf setting? It's done with xsettings. The property name is Gtk/FontName. All GTK+ apps automatically listen for it (see gdk/x11/gdksettings.c in GTK+ source code as a starting point). In GNOME, gnome-settings-daemon watches the gconf key for changes and then generates xsettings/XChangeProperty calls once a change is detected. I've now finished the feature page for this: http://wiki.sugarlabs.org/go/Features/Font_configuration Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Ad-hoc network UI feedback
2009/8/24 Gary C Martin : > Can you create ad-hoc networks on a (XO-1) msh0 device? For me, trying it on > the left grey circle just pulses for a while with a palette title "Gary2's > network, Connecting...", and then goes back to grey with a blank palette Well, the mesh device doesn't function at all with NM-0.7 and sugar > 0.82 > One other quick question. Once you have created an ah-hoc network, the > "Create new wireless network" palette entry is still displayed. It seems a > redundant control, is it still necessary to show? I think it should remain there and have the function of creating a new wireless network. i.e. it should not use name "Gary's network" because that network already exists. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] New F11 for the XO-1 Build 6
2009/8/27 Yioryos Asprobounitis : > I had this issue with os5 (see "...-swap" posts above in the > fedora-olpc-list). It is something not related to swap but is happening often > enough. Usually after 1-3 attempts removing all peripherals (and overclocking > :) recovers and boots fine. Didn't have it with os6 yet. > Of course the old firmware does not help either :) If it's freezing after the "loading ramdisk" line, then it's not related to swap. That's way too early for swap to be having an effect. http://dev.laptop.org/ticket/9100 I also see this bug very often and work around it simply by turning off the machine for 5 minutes and trying again. Here are my findings so far: - nothing is output from the kernel on the serial console, so it is a very early freeze from the kernel standpoint - the serial console does show a newline character *after* the "loading ramdisk" line, which seems to indicate that the ramdisk does load correctly and the crash is triggered by something that happens after - the OFW frame key does not cause the debugger to start - waiting a few minutes does seem to increase success rate - I have had very little success with on,off,on,off,on,off type cycles, but if you insert a few minutes wait inbetween then it does feel to be more likely to boot - once booted, you can reboot indefinitely and it won't hang - I discount reports that this is related to external devices, swap partitions, etc. I run my XOs with the standard configuration and no external devices and I frequently see this bug - I've seen this ever since we upgraded kernel after 8.2 - the 8.2 kernels continue to work fine Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] erasing the journal and config
2009/8/27 Sameer Verma : > I posed this question on OLPC Support Gang earlier and got responses > that its not possible to do so under bitfrost and rainbow. > > === > "Hello everybody, > > We have a lending library at SFSU, ready to go, but we need to have a > way to erase the config and journal every time the XO comes back from > a borrower. The SFSU library staff have made it very clear that they > don't want the process to be "open the terminal and run a script". An > activity (say, Erase) would be quite desirable. In my opinion, this is silly. Teach them how to run a script, teach them how to reflash or tell them to stop being difficult. As for the borrowers end - this is sillier. What are you expecting the borrowers to actually do with their XOs? It's for generating contributions to the community, right? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Deployment Team meeting on Wednesday September 2nd - 14:00 UTC
Hi, 2009/8/31 Pilar Saenz : > Next deployment team meeting Wednesday September 2nd - at 14 UTC (9 EST) on > irc.freenode.net (English channel: #sugar-meeting Spanish channel: > #sugar-reunion). Thanks for organsing the meeting. Can we please introduce some variance in the day and time for these meetings? Like the last Wednesday 1400 meeting, I will not be able to attend :( Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] F11 for XO1 - Fonts
2009/9/1 Art Hunkins : > I've developed a way to handle fonts both on the XO-1 and on SoaS that fits > text nicely, on fixed pages, to all-sized screens. It seems to me like you have this working on 2 screen sizes, but it certainly won't apply to them all. You seem to make assumptions like that if 50 characters at a specific font size can fit on a screen that is 600 pixels wide, then 100 characters will fit on a screen that is 1200 pixels wide. And that's not how displays and font sizes work. The number of lines that can fit on a screen (at a certain font size) does not depend on the aspect ratio, it depends on the physical size of the screen. The correct way to do this is to render the fonts and measure the resultant number of pixels occupied by them, then dynamically adjust. You can discover the approximate size of a character of a font (in pixels) to seed the process. Pango provides you all you need to do this. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Server-devel] splitting large xol
2009/9/4 Sameer Verma : > We have a offline dictionary that we'd like to ship as xol. Its > tar.bz2 is at 63MB. Reading the instructions, it looks like the bundle > will have to be split across two files. Why? 63mb should be fine in 1 bundle. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Server-devel] splitting large xol
2009/9/4 Sameer Verma : > The page says: " > How big is your collection? If the size of your entire collection > is between 5-20MB, you're all set. Otherwise, you'll need to make two > bundles-- one bundle of 5-20MB for use on individual laptops, and a > second bundle of unlimited (but reasonable) size for inclusion on each > school's library server. " I'm pretty sure this is nonsense... 63mb should be fine. Of course, it will eat 63mb on every XO that it is installed on, but there won't be any issues with the actual installation or usage. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] SLOBs Position on SoaS
2009/9/16 Sebastian Dziallas : > Let me rephrase again, to make things clear. I'd love to hear an > "official" answer on this. Soon. > > Is the current SoaS going to be the primary way Sugar Labs distributes a > Sugar-centric GNU/Linux distribution? Isn't there a wider question first? the one that asks if Sugar Labs is actually interested in being a distributor rather than just an upstream. I raised that question in my recent discussion and my feeling is that the responses basically said "well we should really just focus on being an upstream since we already are overworked there, but actually Sugar Labs is just a platform where everyone interested in Sugar can get together and run Sugar-related projects" Based on that, I'd say that SoaS is a fine project to sit under Sugar Labs but there shouldn't be a "primary way" of getting Sugar. Like other upstream projects, Sugar Labs should work with multiple downstreams (treating them equally) in order to achieve wide adoption of the software. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] SLOBs Position on SoaS
2009/9/16 Daniel Drake : > 2009/9/16 Sebastian Dziallas : >> Let me rephrase again, to make things clear. I'd love to hear an >> "official" answer on this. Soon. >> >> Is the current SoaS going to be the primary way Sugar Labs distributes a >> Sugar-centric GNU/Linux distribution? > and to answer a question with a question: how does the answer to this affect your work? I can't immediately see its importance. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SLOBs Position on SoaS
2009/9/16 Jim Simmons : > Sebastian, > > I have a similar question. What I want to know is, when I am finally > able to upgrade my XO from .82 to something better, will I use SoaS to > do it? Or will I be able to do upgrades over the network as I have > done in the past? You will probably have both options. There are efforts to make SoaS run well on the XO through an additional released image. There are also efforts to backport the XO-1.5 distribution work to the XO-1. We previously decided that we would again enable the olpc-update technology for the XO-1.5, but that work has not been completed yet. Presumably when that happens, the XO-1 builds will follow suit. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SLOBS] SLOBs Position on SoaS
2009/9/16 Sebastian Dziallas : > Args! I notice that what I asked could have been misunderstood. I didn't > mean to imply SoaS being only way of distributing Sugar. That's out of > question and was never my intention. I apologize for any confusion if this > feeling has been created. I don't think anyone interpreted your question in this way. > I wonder, though, if the current SoaS is going to be the primary LiveUSB > distribution of Sugar supported by upstream (known as SoaS). I think Sugar should treat all downstreams equally, so there would be no primary distro. But users/deployments may prefer one or the other based on quality/performance/stability/ > Daniel, yes, I think this question needs to be asked. I still don't understand how this affects the work your doing from anything other than a prosperity standpoint. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SLOBS] [IAEP] SLOBs Position on SoaS
2009/9/16 Sebastian Dziallas : > Now it comes to what I think is important in a project. And that is - also - > certainty and trust. Those are pretty important factors. For developers, as > well as for users, to know where one stands. Personally i would just get on with it and let the code do the talking... Produce the best distribution that you can and people will use, respect and protect it. In the unlikely event that SL screws you over, take the project somewhere else, you'll still have your users because your work is high quality. And in the worst-case scenario you have to change the name, but everything else can stay, and you'll still achieving your goals - education. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SLOBS] SLOBs Position on SoaS
2009/9/16 Tomeu Vizoso : > That's true for SoaS, Sugar and for any other FOSS project, but I > think it's a reasonable request to ask for some explicit commitment > from the umbrella organization, just to not have to switch orgs every > release. What kind of commitment do you have in mind? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SLOBS] SLOBs Position on SoaS
2009/9/16 Tomeu Vizoso : > I cannot speak for Sebastian nor the whole SoaS community, but > something like making SoaS an official project in SLs could go a long > way. This would mean saying that "Sugar on a Stick" is a project with > this vision, this mission, this roadmap, this governance model, etc. Yes, that makes sense. Sebastian, if it were made a project would that clear up your doubts? This isn't giving SoaS any special treatment -- any project that comes close to the calibre of soas is obviously candidate to become recognised as an official project. > Also discussing like Sean has made the possibility of an hypothetical > switch to another distro is very good I think. Better have this on the > table than letting it be hidden in the backs of our minds. I don't think it would be fair to take over the name of another project. If another distro project comes along, I feel that it should pick its own name. And is the name really that important? As an example, the existing OLPC distros never really had a name. I call them e.g. "OLPC OS 8.2.0" but there doesn't seem to be any consensus, and it hasn't been a hinderance in adoption. The users don't really get to see the bits that are underneath, so they only refer to "Sugar" anyway. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar-devel Digest, Vol 11, Issue 94
2009/9/17 Jim Simmons : > So the real answer to your question is, how will the other kids > upgrade and when will they be able to do it? In the majority of cases (i.e. large deployments) it will be done as a coordinated effort by the overseeing deployment team. The deployment team will make the decisions of when to upgrade, which release to upgrade to, and how it will be rolled out. After getting past any applicable barriers imposed by OLPC's security system (not used in all deployments), deployments are free to choose to install any software they like. But I predict that they will stay with sugar even if other options become available. I don't know much about the direction or purpose of soasXO but I did notice it seems to have jumped to F12, so maybe it is taking on the role of being experimental/cutting edge. At least one realistic deployment option is slowly emerging -- OLPC is developing a F11-based OS (with Sugar as default desktop) for the XO-1.5, and is porting all the important deployment technologies like theft deterrence, customization key, olpc-update, etc. Community members are working to backport this to XO-1, which is a relatively easy thing to do. http://wiki.laptop.org/go/F11_for_XO-1 There are still holes and bugs, most of which are also seen on the XO-1.5 so will hopefully be fixed in the near future. I should hopefully be back working on that side of things later this year. However for the XO-1 there is still uncertainty, even though we have code - who's going to do QA? Who's going to champion a release based on the builds we have already? or maybe none of that will happen in any capacity but at some point it will mature to the stage where a subset of deployments feel happy to start shipping it anyway. The XO-1 stuff depends heavily on the community so you should definitely be reporting any issues that you find, and if possible, doing anything you can to help fix them. We don't yet have a place on the OLPC trac for this but I'll work on getting that created... Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar-devel Digest, Vol 11, Issue 94
2009/9/17 David Farning : > One step in that direction might be to clearly communicate and try to > gather momentum around a series of stable releases. > > One thought that might work is to set .84, .88, .94, and 1.0 as stable > releases for down streams to unite around. That would be useful but actually the critical area lacking resources right now is people working on OS building and deployment technologies. If I can tame your interest in getting new Sugar on XO in a deployment-quality release, finding resources to work on these resources would be the biggest help you could provide. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0.84 for XO-1 (was Re: Sugar-devel Digest, Vol 11, Issue 94)
2009/9/18 Tomeu Vizoso : > Great, thanks for the kind offer. > > I think the effort is already underway, leaded by Fedora's Steven M. Parrish: > > http://wiki.laptop.org/go/F11_for_XO-1 > > I also think that Martin Dengler is working on this as well, but I'm > not sure how their work relates to each other. > > So testing seems like something that is needed, though I would like to > know what is required in order to say that one of these builds is > ready to be deployed somewhere. Maybe Steven, Daniel, Martin or others > have already thought about this? Afterwards we can count the people > interested in helping and maybe even write a tentative roadmap. I think the strongest requirement at this time is for developers. A few things that spring to mind that need to be worked on: - Camera is not working - build scripts need to be modified to build "updatable" versioned disk images again, so that olpc-update can start working (and the code that supports this in the new initramfs will need to be tested/fixed) - switch to ubifs for new installs (ok, not necessary, but this is so easy it's worth doing -- all info is on the wiki) - screen rotation is broken - mesh support needs finishing - probably missed a few things I spoke with Chris and I think we'll be able to have a section on OLPC trac to keep track of these things sometime now. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SLOBS] SLOBs Position on SoaS
2009/9/19 Chris Ball : > "Should Sugar Labs be a Linux distributor, rather than just an > upstream producing Sugar releases?" > > "Should SL be neutral about distributions containing Sugar, and > refuse to endorse one over another?" > > "Should 'Sugar on a Stick' be a phrase that SL asks its community > to avoid using unless they refer to the SoaS-Fedora distribution?" After speaking with Sebastian on IRC, I think we concluded that really only the 3rd question is of importance to him at this time. The other 2, which may involve a lot more consideration and discussion could be avoided for now (that would be my vote). The 3rd question is important to Sebastian because of some doubt regarding the 'ownership' and usage of the name "Sugar on a Stick." This is perfectly understandable given that: - Sugar on a stick has been a concept within the community for a long time, only recently has it become a solid, mainstream implementation (and even then, there was still a strong element of concept in the marketing) - Non-Fedora distros have also started making sugar distros that run from live USB, and although they haven't been named "Sugar on a stick," I recall at least a few mentions from people in the community referring to them that way - Another party registered the domain name sugaronastick.com This question has been discussed on the mailing list a few times and we have a couple of conflicting responses: 1. Give the name "Sugar on a stick" to Sebastian's project and discourage anyone else from using it 2. Let him use the name for now, but make no promises because if we find a better live USB project in the future, we'll move the "sugar on a stick" name over to *that* one (for the purposes of clarity of marketing?) This is the discussion that would benefit from a decision from the oversight or decision groups, and because it's quite specific, hopefully it can be answered without too much beating around the bush. Sebastian, I hope the above is an accurate summary :) Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SLOBS] SoaS: Searching for Decision Panel volunteers.
2009/9/20 Bernie Innocenti : > I can't volunteer to serve as a member of the volunteer panel, but I'd > like to offer my viewpoint on this issue. I agree and I also feel that we have consensus on those 2 things (SL should promote SoaS, SL should treat distributors equally). The 3rd, about naming, is where we have conflicting viewpoints. Some feel that the "sugar on a stick" name should be permanently assigned to Sebastian's Fedora-based project, but there are some opposing viewpoints: Sean wrote: "Of course, such a scenario raises other questions. If Fedora SoaS is the official version offered to parents and teachers, what happens if a different distro does a better job with a liveUSB implementation? The day a liveUSB version of Sugar contains a risk-free hard-drive installer (if such a thing is even possible) and close integration with the XS server, entire fleets of schools' machines can be flipped to Sugar. Should that better version become Sugar on a Stick? My answer is yes - because it is Sugar Labs building up the brand equity in Sugar on a Stick, and it is Sugar Labs that should have final say about what it is and what it means." Tomeu wrote: "I think the problem is that SLs may want to market an user-end distro and only one, and call it the same regardless of the underlying technologies, because the user doesn't care about those." Yamandu wrote: "I believe SL should support and highlight the best, generally allowing the others to call themselves "a" SOAS if they want to, and also be mentioned in SL web pages and presentations, with the reasonable caveat that they are even more so "works in progress" than the highlighted SOAS" I don't quite understand this decision panel stuff. Is a different decision panel elected every time there is an undecided issue at hand? Or do we elect one group that remains in place for all unanswered questions, present and future? Everyone here seems to already have their own opinions already, and we have already discussed them, provided our own reasoning, and read the views of others. So it seems like the vote of the decision panel would only be unanimous if you were to pick people only on 1 side of the argument.. and the number of votes each way would depend exactly on who you pick for it. Why can't the oversight board make decisions directly? It seems to me that they were voted for based on the fact we trust their vision for the direction of sugarlabs. and it would save us a lot of time and email... Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [SLOBS] Long-term support for Sugar
Hi, 2009/9/22 Benjamin M. Schwartz : > This is incompatible with our (or at least my) goal of allowing > users to throw packages around as atomic objects, without internet access > and without having to understand anything beyond "my friend has Sugar, so > it will work". It is also incompatible with allowing novices to generate > first-class Activities. And to throw in a contrasting view: I feel it's unrealistic and uninteresting for the field. (even though I would personally be thrilled to see this) Before I go further, I want to re-enumerate the items of discussion and the outstanding problems with the .xo format. First of all the problems with our current activity packaging: 1. Versioning system sucks, in that it's not obvious which version of Sugar's activity-exposed APIs each activity is compatible with and you can't even specify this in the metadata, and hence Sugar can't even reject activities that we know simply will not work on version x.y.z. 2. Because there is no user-friendly way of installing system-level libraries, and the bundles itself cannot specify dependencies to be automatically installed, and even because of a variance of system libraries available on different sugar distros, we end up with a common practice of including precompiled libraries within activities. This is a waste of disk space, makes bundles architecture-specific, sometimes even makes the bundle specific to a certain set of system libraries or a specific ABI even within the same architecture, and includes the usual disadvantages equivalent to "regular software" using static instead of dynamic linking (if a single bug in a supporting library is uncovered, multiple bits of software must be patched, released, distributed, built, and installed). 3. Sometimes, even though the activity does not require any extra libraries, an activity bundle includes native code -- for example, someone ports a C/GTK+ app to Sugar - this often involves the C code being compiled for Fedora/x86 then bundled up with a Python wrapper inside a .xo bundle. This has some of the same disadvantages as above - it becomes architecture-specific and ABI-specific. and, in addition to solutions to the problems described above, people want: 4. The ability to send a Sugar activity to any other Sugar user, regardless of Sugar version, underlying distribution and version, and even system architecture 5. The ability to modify activities, revert modifications, and share modified versions with other Sugar users. (there are other difficult/controversial things that people want too -- for example, a guarantee that a shared activity instance of ActivityX on Sugar-0.86 will continue to be compatible with the shared activity instance of ActivityX on Sugar-0.94, but I'll try and keep this discussion limited to the .xo bundle format itself) and features that we have already that people regard as important: 6. The ability to create a .xo bundle in a simple way from any platform, and ease of installation onto XO My own thoughts: 1. Versioning scheme - probably the easiest thing to discuss as it can be solved easily within the current format. My vote would be to adopt GNOME's versioning scheme of basing component and application versions on the version number of the platform. e.g. Write-0.88.1, Paint-0.86.4, etc. 2. Shipping of binary libraries within bundles - I hate this, even just because of the duplication. Never mind that it's become a common practice and is wholly incompatible with Sugar's cross-platform goals. I think we have 3 options available - switch to using distribution package systems which have already solved these problems. let the distributors take care of this... - move to a model where several .xo bundles are generated for each activity release (e.g. one for Fedora9/x86, one for Fedora11/x86, one for Fedora11/ppc, one for Ubuntu/x86, etc) - ban or discourage this practice, and clearly define which system libraries are available for activities My opinion is that distro packaging is the best option, so that installing the Physics activity can install a system copy of Box2D from distro repos at the same time. For the Sugar-side implementation, PackageKit would be the obvious way to go, but as a plan B it would even be OK (in my opinion) to individually support the common package managers in modular fashion. 3. Native code on the application-level only: almost exactly the same set of solutions as (2) and my opinion is the same. 4. Sharing of activities between hugely varying systems: The only real solution to this that I have seen proposed is for *all* activities to switch to some kind of cross-platform VM platform (e.g. Java) which guarantees eternal forward-compat and backwards-compat and will be able to run on any architecture that we might want Sugar to end up on. There is no other workable solution that has been discussed -- shipping .xo bundles with native code cannot work if we are to accept that Sugar runs on multiple archite
Re: [Sugar-devel] Quick notes from a lazy smoketest of os30
2009/10/5 Martin Langhoff : > Got my 1.5-B2 prototype in the mail last week. (Yay! Toys!) I used it > a bit over the week (it is nice and fast), and then yesterday I had a > bit of downtime, so I updated it to cjb's os30. > > Overall, lots of things work (wohoo!). Also, lots of things don't > work, to a puzzling extent: the F11-based SoaS I tested were a lot > more functional than this. Maybe someone knows why? That's strange. Is it just the 2 issues you listed (pippy, recording sound) or are there more? Bugs should be filed under the F11-1.5 milestone. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] incremental activity update
Hi, At OLE Nepal we have difficulties with updating activities because our main educational activity is so huge. Aayush Poudel implemented an incremental activity update which I have now merged with the standard software updater. When updating activities and content, the updater now only downloads the files of the new activity that have changed, greatly reducing time and bandwidth needed for updates. Patches at http://dev.sugarlabs.org/ticket/1499 We're also adding the patch I used in paraguay so that the updater does not try to go online when the school server has an activity available: http://dev.laptop.org/ticket/9259 I hope this is useful for other deployments too! Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] incremental activity update
2009/10/14 Tomeu Vizoso : > Wonder how we could make it easier for other deployments to benefit > from these changes. > > Do you have plans to push the changes to the sugar-update-control repo > and spin new F9 rpms? No - my time is too tight and at least for Paraguay and Nepal it's easier to apply customizations as patches rather than to add RPMs. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] MANIFEST experiments
Today I ran a quick experiment on OLPC OS v8.2.1, based on the question: what are the activity MANIFEST files used for? I see sugar frequently complaining about MANIFEST inconsistencies in the logs, but I don't recall seeing it act on these inconsistencies in any way. I noticed that it even logs such inconsistencies during startup, meaning that it must be checking every file in every activity during a regular boot... So, I reflashed 2 XOs, booted for the first time, entered a name. On one, I modified sugar.bundle.ActivityBundle.read_manifest() to be a no-op, then turned it off. On the other, I just turned it off. Then I powered both on at the same time and started a stopwatch. I measured how long it takes for the XOs to reach the stage of boot where the XO stick figure and the activity icons are visible. The one with the modification reached this point *55* seconds faster than the other one! It basically zeroes the time where you can see the XO stick figure on screen but the activity icons on the home view have yet to appear. This was using OLE Nepal's customized build which includes a big activity with many manifest errors, so the difference might be less elsewhere. Tomeu points out that this behaviour has been improved in more recent sugar versions to the point where manifest checking probably is not happening in the startup path, but personally I question why we are even checking at all. Perhaps we should rip out all that code and leave MANIFESTs purely as a tool for developers to specify which files get included in a bundle or something like that. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] incremental activity update
2009/10/15 Martin Langhoff :
> For the F9 series (8.2.1) my current plan is to work to polish the
> imagecreator scripts so that it is easier for deployents to
>
> - prepare a custom image (mostly covered)
> - base on an existing image ("in place", even if the tar isn't available)
> - create and inject signatures with the local keys (ofw, initramfs, kernel)
I know I myself hacked the image-builder script into this direction,
but in hindsight I feel that it got too hacky and that was the wrong
approach. It presented various surprises along the way and at the very
end left me with the "this is the wrong thing" feeling.
I feel that for making such customizations, the deployments should
clone the build setup (pilgrim) and make changes there. It's more
complex but works well and doesn't leave such a bad taste in the
mouth.
Daniel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] RFC: Kill the delayed menus for good
2009/10/13 Bernie Innocenti : > Hello, > > Michael just passed by the Acetarium and, since the dinner was late, we > found the time to test and review his latest prototype^W patch. > > I'm loving how the menus suddenly are now snappy and responsive. I haven't tried it, and your mail also lacks an explicit explanation of what your patch actually does, but based on the hints you have provided, : It makes all menus that currently have a delay appear instantly? I don't like the idea, as I think that the delay has influenced Sugar's UI design quite heavily. For example, a user is on the home screen with ring view enabled, and the mouse cursor is on the left side of the screen. The user wants to shut down the XO. He moves the cursor towards the XO figure in the middle of the screen, but while doing so passes over an activity icon in the ring. The menu immediately appears, completely obscuring the XO figure that he was going to click on. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] RFC: Kill the delayed menus for good
2009/10/15 Michael Stone : > the menus also *disappear* > quickly when the cursor leaves their boundary. In the field I actually have considered on various occasions doing the opposite. I've seen many children struggle to keep the mouse inside the menu while navigating to the item they want to click on, and having 1 or 2 more seconds to reposition the mouse before the menu disappears might help a lot. (of course it might bring in some other undesirable effects, these are just some initial thoughts from field frustration) Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] incremental activity update
2009/10/15 Martin Langhoff : > Would be interesting to know more on concrete issues (that lead to the > feeling part :-) ). I guess the turning point in my thinking was when I realised that I had to update the .contents file inside the image after making non-activity customizations. This was after we had deployed this buggy image in the field. My realisation was that the more things we do with the image-builder script, the more complications we will have to duplicate from the "real" build system. And sometimes we might only discover the importance of those things when it is too late. > The Pilgrim path is too hard and brittle. Have you tried to set it up? I haven't, but I get the impression from the team here that it is not as bad as you might expect. I'm sure it's not where we'd like it though. Looking forward, the F11 build system is easy to get running. I feel confident it's the kind of thing that can be documented on a single wiki page, which is my general threshold for "[some] deployments can do it" :) Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] RFC: Kill the delayed menus for good
2009/10/15 James Cameron : > No, it doesn't. Try it. I think you'll like it. > > It is quite easy to run the cursor over the activity ring ... nothing > appears until you stop for long enough. But what does appear appears > without a two second delay! OK then, that sounds a lot better. I'm surprised that this point wasn't raised earlier. Given that this thread is largely about process, let me throw in one more point then: all patches should be accompanied with a good description of the change that they actually make :) Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Bug 422302] Re: Soas-2-beta: drop-down menu on XO icon incomplete
2009/10/13 Art Hunkins : > I was mistaken about this. Both SoaS (yes, Strawberry) and the XO-1 act > identically: downloaded activities register immediately; *copied* activities > (from a USB stick) require a restart to register. I'm not seeing this on XO-1. I plug a USB disk in, go to the journal, click the USB icon, then drag-and-drop the activity I want to install onto the journal icon in the bottom left. The activity is then immediately available from the home screen. Are you using a different process? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] is csound-python part of the Sugar Platform?
Hi, http://wiki.sugarlabs.org/go/0.84/Platform_Components doesn't make it clear. Is csound-python part of the Sugar platform? For old OLPC builds, olpcsound did include the csound python module, although this was unused by all of the standard OLPC-shipped activities. (TamTam uses csound directly, without the python wrapper) As of the latest fedora packages, the standard csound packages do not include the python wrapper, you need an extra package (csound-python) for that. FWIW, The OurMusic activity requires this. Thanks, Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] pippy woes
Hi, Latest pippy on activities.sugarlabs.org is v35, but the latest one in git is v34. Please could git be updated? activities.sugarlabs.org says that pippy v35 is only for Sugar v0.86 and newer, is that true? Does groupthink require this? pippy is currently broken because of: http://trac.sugarlabs.org/ticket/1058 It has a patch, but at a glance I can't see how or why it would change anything. Who is the pippy maintainer? can we get this merged and released, please? Including a 0.84-compatible release, pretty please. Aleksey, perhaps you could add an explanation of the bug to the ticket, that may help get things sorted out. Thanks, Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-0.84.7
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.84.7.tar.bz2 == News == * Upgrade activities that were installed from bundles #1176 * Fix .xoj support #1098 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Rationale behind the JSON -> CJSON switch in Sugar codebase?
On Fri, 2009-11-13 at 10:14 +0100, Martin Langhoff wrote: > On Thu, Nov 12, 2009 at 4:40 PM, Tomeu Vizoso wrote: > > Right now just using the json module in python 2.6 may be best as the > > parser is a C module (AFAIR). > > > > Is because of a bug in cjson why those files aren't being parsed? > > Re-reading this -- and given that yes, it's a bug in the cjson parser > -- probably a revert is the sanest thing to do. It would be worth a quick look at fixing cjson yourself. And if that fails, we could report upstream and give them a couple of days to fix it, before moving forward with other options. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Rationale behind the JSON -> CJSON switch in Sugar codebase?
On Fri, 2009-11-13 at 10:53 +0100, Martin Langhoff wrote: > After a few tries, I did find that the same problem was reported in > Debian, a patch proposed, and upstream rejected it: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534709 > > As Tomeu mentions, Python 2.6 reduces the cjson/json performance advantage. OK, didn't see this. Yes, using python standard library seems like the way to go. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Rationale behind the JSON -> CJSON switch in Sugar codebase?
On Fri, 2009-11-13 at 11:50 +0100, Tomeu Vizoso wrote: > For past stable releases, deployers are the ones who should know best. > If you are talking about 0.82, then we should go back to use > simplejson. If this is 0.84 on F11, then we can use what python 2.6 > provides. 0.82 doesn't have this bug - we're talking about an 0.84 regression introduced by the post-0.82 switch to cjson, right? If I'm going to maintain 0.84 further then the a requirement for anything included should be that it is already included in git master. So I'd still like your input on this, please, since we also want to fix in current/future releases :) Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Discrepancy regarding an Activity
2009/11/15 Mohit Taneja : > Well it seems to be an unmaintained fake release of the original FoodForce2 > game. I guess only the copyrights have been changed. In fact, I went through > the their homepage and saw that this organization is into doing such things > only, they copy source code of open source activities, do minor tweaks and > then upload it by their own credits. Well they have certainly contributed some new activities to Sugar which I assume are their own, but this is indeed a bit odd. Is this really the first you've heard of this fork? The page says: Food Force II activity beta-version was released on May 8, 2009 with great success (http://blog.laptop.org/2009/05/08/food-force-2-makes-waves/). The activity was forked into different separate projects on June 23. One will be maintained and developed under the aegis of SEETA (http://seeta.in/j/products-and-services/food-force-ii.html). And, the other would be developed and maintained by Mohit Taneja and Deepank Gupta, who have been the founding developers of this learning activity, and were recommended to Walter Bender by Manusheel Gupta to work on this project with him in 2008. I wonder what the reason for forking is. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Discrepancy regarding an Activity
2009/11/15 Daniel Drake : > 2009/11/15 Mohit Taneja : >> Well it seems to be an unmaintained fake release of the original FoodForce2 >> game. I guess only the copyrights have been changed. In fact, I went through >> the their homepage and saw that this organization is into doing such things >> only, they copy source code of open source activities, do minor tweaks and >> then upload it by their own credits. > > Well they have certainly contributed some new activities to Sugar > which I assume are their own, but this is indeed a bit odd. Is this > really the first you've heard of this fork? And to confuse matters more.. surely you knew of Manusheel's involvement (or at least his interest) in your project well before the supposed fork date of June 23 -- I have a personal email in my inbox from May where Manusheel was persuading deployments to try out the new activity and provide feedback (I was in Paraguay at the time). He writes it as if you are all a team, seeta included, and suggests that it was even listed as a project on the SEETA website at that time. And see his name on http://blog.laptop.org/2009/05/08/food-force-2-makes-waves/ Anyway, it seems like the easiest thing to do here would be to give commit access to Manusheel's team to the original repository. It looks like they have just made the first change in their forked version, adding a spanish translation, and I imagine that's not a contribution you would turn down. Manusheel, in the open source world, when forking a project the common etiquette is to rename it to something substantially different. But in this case I suggest you simply dissolve the fork and attempt to work together, in the same place. Less work for everyone. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
