Re: [Sugar-devel] versus, not
On Tue, May 5, 2009 at 10:33 AM, Walter Bender wrote: > On Mon, May 4, 2009 at 8:20 PM, Bill Kerr wrote: > > however, I do think the roll back of enlightenment principles is not well > > understood (http://learningevolves.wikispaces.com/nonUniversals) and > that a > > better understanding might persuade more people of the need to keep > > searching and struggling for different ways to go against some of the > tide > > of local culture - there is a recent interesting comment thread on mark > > guzdial's blog which is worth reading from this point of view > > http://www.amazon.com/gp/blog/post/PLNK3F4TMBURELZZK > > > > Regarding Guzdial's blog, I am optimistic. While I had always feared > that "phone culture" would turn us into a society of consumers of > services that Ma Bell chose for us; but the iPhone and the Android are > programmable and, while Apple is the iPhone gatekeeper, the meme that > phones can be programmed is spreading. This is a huge step forward. I'd also point out that there are some other great themes in the mark guzdial comments thread, eg. the difficult question of the need to transcend a marketing approach (dialogue b/w mark guzdial and alan kay) I've recently had some striking experiences from a couple of people - both huge mac fans - who I thought perversely avoided anything to do with programming, including visual drag and drop using scratch or even raw HTML markup The Guzdial blog helped me make the connection - that the mac way does in fact brainwash people to the mentality that everything is perfect, beautiful and shiny as it comes packaged to you, that there is an app for everything. Although I find that most students will accept "simple" challenges such as scratch programming and become absorbed in them this minority(?) trend does worry me - Guzdial's blog is pretty much devoted to the theme of how induce more students into programming in view of the trend to falling enrolments in programming courses (in Australia too, as well as the USA) I then thought of some notes I made a couple of years ago after reading John Maxwell's history of the dynabook ( http://thinkubator.ccsp.sfu.ca/Dynabook/dissertation): http://learningevolves.wikispaces.com/alanKay+talk What sort of user interface is suitable for learning? We have become very used to a certain style of user interface, one which is “user friendly” and which gives us access to the function of the computer. The user friendly user interface has been designed by experts to not demand too much of the end user. Some systems take this a step further and actively discourage the user from becoming curious about how things work under the hood. It is not just a matter of “user friendly”, in itself that is not serious grounds for complaint. It is the idea of users as users of clearly defined applications that have been developed by “experts”. In large part this state of things has arisen through commercialisation. A marketable commodity requires a clear definition. So proprietary applications are developed as a black box as an expression of “efficient software engineering”. In this commercial vision the “personal computer” is not really personal because most of its interfaces have been standardised which transforms the actors into docile agents who respond in predictable ways to stimuli. “my life belongs to the engineers ... we hesitate to exist” (Latour) “The self evident state of the art blinds people to other possibilities” (Andy diSessa) If you start from a more philosophical perspective of amplifying human reach, of computer as a meta medium for expressing the creative spirit then the attitude to the user is different. The user, as well as being a user, is also a potential constructionist designer and developer who eventually will be able to create their own tools. So, the tools for exploring the system should be powerful and easily accessible. This is one of the features of Smalltalk. The ethic is one of mutability and simplicity. Every component of a system is open to be explored, investigated, modified and built upon. The tool / medium distinction is blurred and so is a lot of other false clarity. Rather than a world of reified “experts”, “engineers”, “designers”, “end-users”, “miracle workers” and “plain folks” it would be better to blur these boundaries, particularly for learning environments. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] FoodForce II Beta Release
On Friday 08 May 2009 03:24:30 pm Mohit Taneja wrote: > Hi, > > The Beta version of the FoodForce2 game has been developed for the XO. The > features that have been incorporated are : Congratulations! Looks great! I had a chance to see a presentation on this game last October in El Salvador and I was impressed with the work. May I ask what license is it under? > FoodForce2 Team -- Andrés ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [PATCH] add clock frame device
A few thoughts. 1. I think that we need to show the leading 0 when the hour is a one digit number, eg. 08:07. Otherwise everything in the Frame is going to shift depending on the time. 2. I find the radio buttons a little odd. I wonder if we could have a single menu item that either a) reads "Use 24 hour clock" and uses a checkmark to show its state or b) toggles between "Use 24 hour clock" and "Use 12 hour clock" when clicked. 3. We could expose some more useful info in the palette, both primary and secondary. The primary palette, for instance, could read: My Clock Friday, May 8, 2009 I'd put the date label in the secondary string, so we can retain the standard practice of listing the device name in the primary. Including the day of the week would be nice, and displaying the date in a human friendly manner will make it feel less cold & "computery". I also think (this is a future feature suggestion, and needn't be there in a first pass) that the secondary palette should have a nice little inline calendar as well. 4. This is another future suggestion: we've talked in the past about having an option on various devices which jumps directly to the corresponding section of settings. This device should have a "Show Date & TIme Settings" option when we add that capability. 5. Finally, I'd like to see if it's at all readable if we limit the clock to a single unit like the rest of the devices icons. I'll try to make some mockups of all of these thoughts before tomorrow's design meeting. Let me know your thoughts on the suggestions. Eben On Fri, May 8, 2009 at 7:51 PM, Martin Dengler wrote: > [ccing sugar-devel as well] > > On Sat, May 09, 2009 at 09:18:02AM +1000, fors...@ozonline.com.au wrote: >> > The below patch adds a clock device to the frame: >> Thanks Martin, I have wanted a clock for a long time. >> >> Can we please have an idiots guide for installation? > > Unfortunately, you can't yet in any released version of Sugar. The > purpose of my mail was not to give anyone besides a developer code > they could actually use (sorry for the disapointment - I should have > pointed this out very clearly). The purpose was both to solicit > another round of feedback on the design/behavior, and also to > demonstrate that I had actually written some code that did it (note I > do not say "the best code" nor "the code anyone believes should be > released"). > > If you have a moment to suggest any improvements you can think of that > would be most helpful. I can't guarantee to implement them all but I > (and the Sugar world) am listening seriously. The links again are: > > http://www.martindengler.com/tmp/screenshot_clock_device_frame-06_a6_a689bf1e-3f34-4da3-afed-aa910ab4f677.png > http://www.martindengler.com/tmp/screenshot_clock_device_frame-07_84_841da15d-9bd7-4fe4-aada-8e8ab723f806.png > http://www.martindengler.com/tmp/screenshot_clock_device_frame-08_4b_4ba1059e-4db9-4f22-8661-7916f6a167f8.png > > However, if you happen to be running SoaS, you can run the clock > "as-is". Start the Terminal activity and execute (cut & paste) these > commands: > > su - > cd /usr/share/sugar/extensions/deviceicon > wget http://www.martindengler.com/tmp/clock.py > > ...and then restart Sugar by pressing Control-Alt-Erase at the same > time. > > If there's enough interest someone (maybe I) may backport the clock to > the currently-released-but-very-old-in-developer-terms Sugar software. > > You may also be interested in my prior clock design, which I did > backport to the latest released OLPC build: > http://wiki.laptop.org/go/User:MartinDengler#Build_767_.2F_801_.28current_stable.29 > > Martin > > ___ > IAEP -- It's An Education Project (not a laptop project!) > i...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [PATCH] add clock frame device
[ccing sugar-devel as well] On Sat, May 09, 2009 at 09:18:02AM +1000, fors...@ozonline.com.au wrote: > > The below patch adds a clock device to the frame: > Thanks Martin, I have wanted a clock for a long time. > > Can we please have an idiots guide for installation? Unfortunately, you can't yet in any released version of Sugar. The purpose of my mail was not to give anyone besides a developer code they could actually use (sorry for the disapointment - I should have pointed this out very clearly). The purpose was both to solicit another round of feedback on the design/behavior, and also to demonstrate that I had actually written some code that did it (note I do not say "the best code" nor "the code anyone believes should be released"). If you have a moment to suggest any improvements you can think of that would be most helpful. I can't guarantee to implement them all but I (and the Sugar world) am listening seriously. The links again are: http://www.martindengler.com/tmp/screenshot_clock_device_frame-06_a6_a689bf1e-3f34-4da3-afed-aa910ab4f677.png http://www.martindengler.com/tmp/screenshot_clock_device_frame-07_84_841da15d-9bd7-4fe4-aada-8e8ab723f806.png http://www.martindengler.com/tmp/screenshot_clock_device_frame-08_4b_4ba1059e-4db9-4f22-8661-7916f6a167f8.png However, if you happen to be running SoaS, you can run the clock "as-is". Start the Terminal activity and execute (cut & paste) these commands: su - cd /usr/share/sugar/extensions/deviceicon wget http://www.martindengler.com/tmp/clock.py ...and then restart Sugar by pressing Control-Alt-Erase at the same time. If there's enough interest someone (maybe I) may backport the clock to the currently-released-but-very-old-in-developer-terms Sugar software. You may also be interested in my prior clock design, which I did backport to the latest released OLPC build: http://wiki.laptop.org/go/User:MartinDengler#Build_767_.2F_801_.28current_stable.29 Martin pgpGR6JNQ85k9.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Dictionary everywhere ?
On Sat, May 9, 2009 at 4:11 AM, Aleksey Lim wrote:
> On Thu, May 07, 2009 at 06:21:43PM +0530, Sayamindu Dasgupta wrote:
>> On Thu, May 7, 2009 at 6:12 PM, Samuel Klein wrote:
>> > I'd prefer to see all meanings for a word within the set of
>> > dictionaries chosen. If you are learning two langs, you should see
>> > relevant words in both languages when you select a string.
>> >
>> > SJ
>>
>>
>> Well - we can let the user choose multiple dictionaries if we want.
>> Does that make sense ?
> are you planing to reuse code of others projects like {Golden|Star|etc}Dict?
>
> I mean it should be a good idea to support the whole variety(as possible)
> of dictionary formats and let user download dicts for example from
> http://xdxf.revdanica.com/down/index.php
>
The dictionary database I used in the prototype code used the
dictionary format used by the dictd server.
Thanks,
Sayamindu
--
Sayamindu Dasgupta
[http://sayamindu.randomink.org/ramblings]
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Dictionary everywhere ?
On Thu, May 07, 2009 at 06:21:43PM +0530, Sayamindu Dasgupta wrote:
> On Thu, May 7, 2009 at 6:12 PM, Samuel Klein wrote:
> > I'd prefer to see all meanings for a word within the set of
> > dictionaries chosen. If you are learning two langs, you should see
> > relevant words in both languages when you select a string.
> >
> > SJ
>
>
> Well - we can let the user choose multiple dictionaries if we want.
> Does that make sense ?
are you planing to reuse code of others projects like {Golden|Star|etc}Dict?
I mean it should be a good idea to support the whole variety(as possible)
of dictionary formats and let user download dicts for example from
http://xdxf.revdanica.com/down/index.php
--
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] add clock frame device
The below patch adds a clock device to the frame:
http://www.martindengler.com/tmp/screenshot_clock_device_frame-06_a6_a689bf1e-3f34-4da3-afed-aa910ab4f677.png
http://www.martindengler.com/tmp/screenshot_clock_device_frame-07_84_841da15d-9bd7-4fe4-aada-8e8ab723f806.png
http://www.martindengler.com/tmp/screenshot_clock_device_frame-08_4b_4ba1059e-4db9-4f22-8661-7916f6a167f8.png
The patch incorporates almost all of the feedback already received.
Feedback welcome.
Martin
---
extensions/deviceicon/clock.py | 325
1 files changed, 325 insertions(+), 0 deletions(-)
create mode 100644 extensions/deviceicon/clock.py
diff --git a/extensions/deviceicon/clock.py b/extensions/deviceicon/clock.py
new file mode 100644
index 000..7d3647d
--- /dev/null
+++ b/extensions/deviceicon/clock.py
@@ -0,0 +1,325 @@
+# Copyright (C) 2008 Martin Dengler
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+
+from gettext import gettext as _
+
+import logging
+import math
+import time
+
+import gconf
+import gobject
+import gtk
+import gtk.gdk
+import pango
+import pangocairo
+
+import jarabe.frame
+
+from jarabe.frame.frameinvoker import FrameWidgetInvoker
+from sugar.graphics import style
+from sugar.graphics.palette import Palette
+from sugar.graphics.toolbutton import ToolButton
+from sugar.graphics.xocolor import XoColor
+
+
+
+DEFAULT_TEXT_FONT = "Bitstream Vera Sans"
+
+
+class TextIcon(gtk.Image):
+def __init__(self, *args, **kwargs):
+gtk.Image.__init__(self, *args, **kwargs)
+client = gconf.client_get_default()
+mycolor = XoColor(client.get_string('/desktop/sugar/user/color'))
+self._fill_rgba = style.Color(mycolor.fill).get_rgba()
+self._stroke_rgba = style.Color(mycolor.stroke).get_rgba()
+
+self.add_events(gtk.gdk.EXPOSURE_MASK)
+self.connect("expose-event", self.my_expose_event)
+
+self.add_events(gtk.gdk.VISIBILITY_NOTIFY_MASK)
+self.connect('event', self.__event_cb)
+
+def __event_cb(self, *args, **kwargs):
+logging.debug("DigitalClock TextIcon event args: %s; kwargs %s" %
(args, kwargs))
+
+def my_expose_event(self, widget_, event):
+cr = self.window.cairo_create()
+x, y, w_, h_ = self.allocation
+cr.translate(x, y)
+self.texticon_draw(cr)
+
+def draw_rounded_rectangle(self, cr, x, y, width, height, radius=9.0):
+"""Draw a rounded rectangle path based on Guillaume Seguin's code"""
+offset = radius / 3
+x0 = x + offset
+y0 = y + offset
+x1 = x + width - offset
+y1 = y + height - offset
+cr.new_path()
+
+pi = math.pi
+
+cr.arc (x0 + radius, y1 - radius, radius, pi / 2, pi)
+cr.line_to (x0, y0 + radius)
+cr.arc (x0 + radius, y0 + radius, radius, pi, 3 * pi / 2)
+cr.line_to (x1 - radius, y0)
+cr.arc (x1 - radius, y0 + radius, radius, 3 * pi / 2, 2 * pi)
+cr.line_to (x1, y1 - radius)
+cr.arc (x1 - radius, y1 - radius, radius, 0, pi / 2)
+
+cr.close_path()
+
+def write(self, cr, text, x=0, y=0, font=None, reverse_video=False):
+pcr = pangocairo.CairoContext(cr)
+layout = pcr.create_layout()
+if font is None:
+font = DEFAULT_TEXT_FONT
+layout.set_font_description(pango.FontDescription(font))
+layout.set_markup(text)
+
+padding = 10
+w, h = layout.get_pixel_size()
+w += 2 * padding
+
+fg = self._stroke_rgba
+bg = self._fill_rgba
+
+if reverse_video:
+fg, bg = bg, fg
+
+cr.save()
+cr.set_source_rgba(*fg)
+self.draw_rounded_rectangle(cr, x, y, w, h)
+cr.fill()
+cr.set_line_width(padding * 0.4)
+cr.set_source_rgba(*bg)
+self.draw_rounded_rectangle(cr, x, y, w, h)
+cr.stroke()
+cr.restore()
+
+cr.save()
+
+cr.move_to(x + padding, y)
+
+pcr.layout_path(layout)
+cr.set_source_rgba(*fg)
+cr.set_line_width(padding * 0.5)
+cr.stroke_preserve()
+cr.set_source_rgba(*bg)
+cr.fill()
+cr.restore()
+
+self.set_size_request(w, h)
+
+def texticon_draw(self, cr)
[Sugar-devel] FoodForce II Beta Release
Hi, The Beta version of the FoodForce2 game has been developed for the XO. The features that have been incorporated are : - The storyboard has been implemented in the game, which includes different scenarios, each of them is related to a particular key learning area or a social issue. - The game is playable over the mesh network, the trading scenario has been implemented over the mesh network. - The memory footprint of the game has been reduced. The issues over the game having memory leaks, submitted by the testing group has been resolved. - A major UI Redesign of the game has been done to make things more intuitive for the child. For more info about the game check : http://wiki.laptop.org/go/Food_ForceII The game can be downloaded from : http://code.google.com/p/foodforce/downloads/list We recently organized a hands-on session with the students and teachers of Delhi Police Public School in Safdarjung Delhi, India. For information related to the test methodology and test results : http://wiki.laptop.org/go/FoodForceII/FoodForce_II_Team_School_Visit The storyboard used in the game has been documented here : http://wiki.laptop.org/go/FoodForceII/Storyboard Regards, Mohit FoodForce2 Team ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Limiting Object Chooser to specified MIME types
On Fri, May 08, 2009 at 10:03:33AM -0500, James Simmons wrote: > Aleksey, I was interested in your comment about wrapping Object Chooser > for backward compatibility. Currently both of my Activities use Object > Chooser, but don't make any attempt to limit what Journal entries can be > chosen. I would like to limit Read Etexts to the MIME types text/plain > and application/zip, and View Slides to just application/zip. In > Sayamindu's code he is using mime.GENERIC_TYPE_IMAGE. There does not > seem to be anything comparable that would select what I want selected. > I'm looking at the code for sugar.mime here: > http://api.sugarlabs.org/sugar.mime-pysrc.html I'm wondering if I could > make my own filter in my own Activities that would limit the Object > Chooser to just plain text and Zip files. yup, there is a problem with custom mime types in ObjectChooser I've created http://dev.sugarlabs.org/ticket/834 for that reason > I would of course follow your > suggestion for backward compatibility. after fixing #834 I'll add custom mime types support to sugar-port (w/o breaking backwards compatibility) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Limiting Object Chooser to specified MIME types
PS. The upside-down Paint icon in that mockup is meant to indicate that there is some other activity which handles the SVG type, and this is a stand-in icon for that. Don't take it in a literal sense. Eben On Fri, May 8, 2009 at 11:53 AM, Eben Eliason wrote: > Actually, that's not entirely true. This was considered in the design > for the object chooser, as can be seen here: > http://wiki.sugarlabs.org/go/Design_Team/Designs/Object_Chooser#03 > > In addition to specifying the generic type, the intent was to also > allow a boolean which determined whether or not the "kind" menu > remained enabled, and the passing of an array of supported mime types. > This slide illustrates how images of a non-supported type are shown in > the list, but rendered inactive and therefore un-selectable. > > As a technical note, any mime types passed which are not a subset of > the generic type will simply be ignored. > > Eben > > > On Fri, May 8, 2009 at 11:41 AM, Tomeu Vizoso wrote: >> On Fri, May 8, 2009 at 17:35, Bert Freudenberg wrote: >>> On 08.05.2009, at 17:03, James Simmons wrote: >>> Aleksey, I was interested in your comment about wrapping Object Chooser for backward compatibility. Currently both of my Activities use Object Chooser, but don't make any attempt to limit what Journal entries can be chosen. I would like to limit Read Etexts to the MIME types text/plain and application/zip, and View Slides to just application/ zip. In Sayamindu's code he is using mime.GENERIC_TYPE_IMAGE. There does not seem to be anything comparable that would select what I want selected. I'm looking at the code for sugar.mime here: http://api.sugarlabs.org/sugar.mime-pysrc.html I'm wondering if I could make my own filter in my own Activities that would limit the Object Chooser to just plain text and Zip files. I would of course follow your suggestion for backward compatibility. James Simmons >>> >>> This was discussed several times, last I think in this thread: >>> >>> http://lists.sugarlabs.org/archive/sugar-devel/2008-October/009118.html >>> >>> IMHO it would be quite a bit more useful than the restricted interface >>> we have now. You could build such a chooser yourself using the >>> datastore.find(query) function. But adding a similar "query" parameter >>> to the object chooser was deemed too powerful, possibly unsupportable >>> once the datastore was rewrittten. Maybe a list of mime types would be >>> acceptable to add, though? >> >> A bigger problem than the DS support is the UI. You currently can only >> pass programatically a generic type such as Image instead of >> individual mime types because the UI has only a way to change the >> generic type. >> >> Ideas? >> >> Thanks, >> >> Tomeu >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel >> > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Limiting Object Chooser to specified MIME types
On 08.05.2009, at 17:41, Tomeu Vizoso wrote: > On Fri, May 8, 2009 at 17:35, Bert Freudenberg > wrote: >> On 08.05.2009, at 17:03, James Simmons wrote: >> >>> Aleksey, >>> >>> I was interested in your comment about wrapping Object Chooser for >>> backward compatibility. Currently both of my Activities use Object >>> Chooser, but don't make any attempt to limit what Journal entries >>> can be chosen. I would like to limit Read Etexts to the MIME types >>> text/plain and application/zip, and View Slides to just application/ >>> zip. In Sayamindu's code he is using mime.GENERIC_TYPE_IMAGE. >>> There does not seem to be anything comparable that would select what >>> I want selected. I'm looking at the code for sugar.mime here: >>> >>> http://api.sugarlabs.org/sugar.mime-pysrc.html >>> >>> I'm wondering if I could make my own filter in my own Activities >>> that would limit the Object Chooser to just plain text and Zip >>> files. I would of course follow your suggestion for backward >>> compatibility. >>> >>> James Simmons >> >> This was discussed several times, last I think in this thread: >> >> http://lists.sugarlabs.org/archive/sugar-devel/2008-October/009118.html >> >> IMHO it would be quite a bit more useful than the restricted >> interface >> we have now. You could build such a chooser yourself using the >> datastore.find(query) function. But adding a similar "query" >> parameter >> to the object chooser was deemed too powerful, possibly unsupportable >> once the datastore was rewrittten. Maybe a list of mime types would >> be >> acceptable to add, though? > > A bigger problem than the DS support is the UI. You currently can only > pass programatically a generic type such as Image instead of > individual mime types because the UI has only a way to change the > generic type. > > Ideas? Let the activity define more filters, similar to TEXT, AUDIO etc. filters that are there now. The activity provides a localized title for each entry, and an icon name (or possibly the activity icon would be used, or an icon meaning "custom filter"). The first custom filter should be selected by default and appear on top of the list, next to the generic filters. Something like this, an array of 3-tuples, using Python notation (D-Bus signature 'a(ssas)'): [ ( 'Localized filter name one', 'first-icon-name', ['first/mime-type', 'second/mime-type'] ), ( 'Localized filter name two', 'second-icon-name', ['some/mime-type', 'other/mime-type'] ) ] - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Limiting Object Chooser to specified MIME types
Actually, that's not entirely true. This was considered in the design for the object chooser, as can be seen here: http://wiki.sugarlabs.org/go/Design_Team/Designs/Object_Chooser#03 In addition to specifying the generic type, the intent was to also allow a boolean which determined whether or not the "kind" menu remained enabled, and the passing of an array of supported mime types. This slide illustrates how images of a non-supported type are shown in the list, but rendered inactive and therefore un-selectable. As a technical note, any mime types passed which are not a subset of the generic type will simply be ignored. Eben On Fri, May 8, 2009 at 11:41 AM, Tomeu Vizoso wrote: > On Fri, May 8, 2009 at 17:35, Bert Freudenberg wrote: >> On 08.05.2009, at 17:03, James Simmons wrote: >> >>> Aleksey, >>> >>> I was interested in your comment about wrapping Object Chooser for >>> backward compatibility. Currently both of my Activities use Object >>> Chooser, but don't make any attempt to limit what Journal entries >>> can be chosen. I would like to limit Read Etexts to the MIME types >>> text/plain and application/zip, and View Slides to just application/ >>> zip. In Sayamindu's code he is using mime.GENERIC_TYPE_IMAGE. >>> There does not seem to be anything comparable that would select what >>> I want selected. I'm looking at the code for sugar.mime here: >>> >>> http://api.sugarlabs.org/sugar.mime-pysrc.html >>> >>> I'm wondering if I could make my own filter in my own Activities >>> that would limit the Object Chooser to just plain text and Zip >>> files. I would of course follow your suggestion for backward >>> compatibility. >>> >>> James Simmons >> >> This was discussed several times, last I think in this thread: >> >> http://lists.sugarlabs.org/archive/sugar-devel/2008-October/009118.html >> >> IMHO it would be quite a bit more useful than the restricted interface >> we have now. You could build such a chooser yourself using the >> datastore.find(query) function. But adding a similar "query" parameter >> to the object chooser was deemed too powerful, possibly unsupportable >> once the datastore was rewrittten. Maybe a list of mime types would be >> acceptable to add, though? > > A bigger problem than the DS support is the UI. You currently can only > pass programatically a generic type such as Image instead of > individual mime types because the UI has only a way to change the > generic type. > > Ideas? > > Thanks, > > Tomeu > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Limiting Object Chooser to specified MIME types
On Fri, May 8, 2009 at 17:35, Bert Freudenberg wrote: > On 08.05.2009, at 17:03, James Simmons wrote: > >> Aleksey, >> >> I was interested in your comment about wrapping Object Chooser for >> backward compatibility. Currently both of my Activities use Object >> Chooser, but don't make any attempt to limit what Journal entries >> can be chosen. I would like to limit Read Etexts to the MIME types >> text/plain and application/zip, and View Slides to just application/ >> zip. In Sayamindu's code he is using mime.GENERIC_TYPE_IMAGE. >> There does not seem to be anything comparable that would select what >> I want selected. I'm looking at the code for sugar.mime here: >> >> http://api.sugarlabs.org/sugar.mime-pysrc.html >> >> I'm wondering if I could make my own filter in my own Activities >> that would limit the Object Chooser to just plain text and Zip >> files. I would of course follow your suggestion for backward >> compatibility. >> >> James Simmons > > This was discussed several times, last I think in this thread: > > http://lists.sugarlabs.org/archive/sugar-devel/2008-October/009118.html > > IMHO it would be quite a bit more useful than the restricted interface > we have now. You could build such a chooser yourself using the > datastore.find(query) function. But adding a similar "query" parameter > to the object chooser was deemed too powerful, possibly unsupportable > once the datastore was rewrittten. Maybe a list of mime types would be > acceptable to add, though? A bigger problem than the DS support is the UI. You currently can only pass programatically a generic type such as Image instead of individual mime types because the UI has only a way to change the generic type. Ideas? Thanks, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Limiting Object Chooser to specified MIME types
On 08.05.2009, at 17:03, James Simmons wrote: > Aleksey, > > I was interested in your comment about wrapping Object Chooser for > backward compatibility. Currently both of my Activities use Object > Chooser, but don't make any attempt to limit what Journal entries > can be chosen. I would like to limit Read Etexts to the MIME types > text/plain and application/zip, and View Slides to just application/ > zip. In Sayamindu's code he is using mime.GENERIC_TYPE_IMAGE. > There does not seem to be anything comparable that would select what > I want selected. I'm looking at the code for sugar.mime here: > > http://api.sugarlabs.org/sugar.mime-pysrc.html > > I'm wondering if I could make my own filter in my own Activities > that would limit the Object Chooser to just plain text and Zip > files. I would of course follow your suggestion for backward > compatibility. > > James Simmons This was discussed several times, last I think in this thread: http://lists.sugarlabs.org/archive/sugar-devel/2008-October/009118.html IMHO it would be quite a bit more useful than the restricted interface we have now. You could build such a chooser yourself using the datastore.find(query) function. But adding a similar "query" parameter to the object chooser was deemed too powerful, possibly unsupportable once the datastore was rewrittten. Maybe a list of mime types would be acceptable to add, though? - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Limiting Object Chooser to specified MIME types
Aleksey, I was interested in your comment about wrapping Object Chooser for backward compatibility. Currently both of my Activities use Object Chooser, but don't make any attempt to limit what Journal entries can be chosen. I would like to limit Read Etexts to the MIME types text/plain and application/zip, and View Slides to just application/zip. In Sayamindu's code he is using mime.GENERIC_TYPE_IMAGE. There does not seem to be anything comparable that would select what I want selected. I'm looking at the code for sugar.mime here: http://api.sugarlabs.org/sugar.mime-pysrc.html I'm wondering if I could make my own filter in my own Activities that would limit the Object Chooser to just plain text and Zip files. I would of course follow your suggestion for backward compatibility. James Simmons Message: 3 Date: Fri, 8 May 2009 02:39:41 + From: Aleksey Lim Subject: Re: [Sugar-devel] [RELEASE] [Sucrose 0.85] Imageviewer 10 To: sugar-devel@lists.sugarlabs.org Message-ID: <20090508023940.ga17...@antilopa-gnu> Content-Type: text/plain; charset=us-ascii On Fri, May 08, 2009 at 12:37:00AM +, Aleksey Lim wrote: > On Fri, May 08, 2009 at 01:50:44AM +0530, Sayamindu Dasgupta wrote: > > Hello all, > > I have released ImageViewer activity version 10. > > This release has support for sharing file sharing. > > > > This is a major new functionality (feature freeze break) so I'm > > releasing it as a part of 0.85. However, this works fine with 0.82 > > and above. > it doesn't work with XO-767(sugar-0.82 can't use mime types in object > chooser), so I marked it "only 0.84" on ASLO > > you can wrap object chooser code into try..except > and make it runnable on 0.82(and upload new version to ASLO) Just an option - you can use sugar-port[1] API for object chooser instead of native from sugar. In that case you should create "port" directory and place there chooser.py file from sugar-port project and use it according to [2]. On 0.84 it will open ObjectChooser with preselected mime type, on 0.82 just open ObjectChooser w/o errors. [1] http://wiki.sugarlabs.org/go/Development_Team/sugar-port [2] http://people.sugarlabs.org/~alsroot/sugar-port/port.chooser-module.html ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] versus, not
One of the real pleasures of this adventure we are on is that there has been thoughtful criticism of ideas. I cannot get away with vague or sloppy thinking. On Fri, May 8, 2009 at 4:37 AM, Bill Kerr wrote: > I'm not sure what is meant by a "big tent" > > Why do some people want a big tent for learning theory but not a big tent > which accepts both FOSS and proprietary software? Phrasing it that way is > intended to encourage people to think about what sort of thing is learning > and hopefully will not be interpreted as just being provocative for its own > sake. FOSS is a theory of learning. We don't need to reach consensus about either learning theory or FOSS, but to be members of this community, we must agree that we can progress from critique to making positive changes. > you can have a big tent where people don't discuss learning theory because > it's too hard to reach agreement > > you can have a big tent where people passionately argue about learning > theory but actually listen to what each is saying and argue rationally > > when I look at minsky's theory of mind I see that he supports multiple > models of thinking but also argues against models of thinking that he thinks > are incorrect or which emphasise only one way of doing things, eg. although > he helped create connectionism he now thinks it has too much influence As Martin points out, Sugar Labs is building tools. But we are not agnostic about how they are used. We are deliberately building affordances into our tools to encourage and promote learning activities that are "C" in their nature, because we believe that that is the principle means by which learners will reach a level of fluency as described by Alan. But the tools can be used in support of other learning theories and, to rephrase Minsky, "if you don't learn something more than one way, you don't learn it." > that suggests another version of a big tent which I favour - cherry picking > the best parts out of different learning theories / activities based on > criteria (not stated here) that are substantial I wear an engineer's hat: "What is the best solution I can build today?" not a scientist's hat: "What is the best possible solution?" Ergo, +1 for cherry picking. > > I don't believe that thinking people are agnostic about how people learn > > it seems to me that alan kay has presented a possibly strategic view of > progress on these questions (that learning about bricks will not > automatically lead to building arches, that we need more than just focusing > on building blocks) - but that for various reasons we are not in a position > to implement the learning materials based on that view in practice in the > activities > > for me to sit in the big tent holding a strategic view feels different to > "too hard basket", agnosticism or a tower of babble - teaching with an > underlying strategic view is very different to just going along with the > tide The analogy to "big tent" perhaps needs more of an explanation for those not living day-to-day in earshot of the US political dialog. Republican President Ronald Reagan referred to his party as a big tent in the days of his popular majority. The current party is being accused of (or admired for) being more fundamentalist in its ideology; this "either your are with us or against us" approach has arguably resulted in a greatly contracted constituency: there are more people who identify themselves as Independents than as Republicans. As a result, it is being asserted both from within and without that the Republicans have excluded themselves from the debate. We must engage teachers and learners even if we do not have consensus on all aspects of learning theories, FOSS, or Sugar. Without the engagement, we don't grow. Even more important, without the engagement, we don't learn. That doesn't mean we don't have opinions or direction. > > that would mean work to understand and implement that strategic view but > also accept that we are not there yet (it will take some time) and so it is > perfectably understandable and desirable that people will use and develop > whatever is at hand or which they think important to develop - no one can > stop that anyway accept by successful arguing someone out of a POV We have a long ways to go and we need to keep debating as we go. But also we need to continue "doing". And always be asking "Are there other ways to approach this?" and "How might we make this better?" > Does the "big tent" phrase add clarity to this conversation? > Perhaps not. But the discussion adds clarity to the overall mission of Sugar Labs. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.84-on-a-XO
tomeu wrote: > On Fri, May 8, 2009 at 14:03, Martin Dengler > wrote: > > > >> I was very heartened to hear on IRC two days ago that OLPC have a > >> kernel hacker (dsaxena) starting in June (to work on Gen 1.5), and > >> that one of the first thing on the todo list was to get the OLPC > >> patches applying to the linus kernel. > > This has just made me happy today. How much can we rely on this > happening? Any plans regarding mesh support in NM? i've not heard of any NM plans from OLPC. as for "relying" on the kernel patches getting upstream, i can't speak for deepak, or OLPC, or cjb, but as usual, i'd say that being ready and eager to test, package, etc in a very timely fashion would help a lot. i don't believe that getting these patches upstream is a primary goal (for OLPC) -- my feeling is that it's just a necessary step that's been nagging at the project, and the more quickly we can get past it, the better. (btw, i'll be back at olpc, too, for a couple of months, helping out with various pieces of 1.5 work: principally with the EC, but hopefully with other work as well.) paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.84-on-a-XO
On Fri, May 8, 2009 at 14:03, Martin Dengler wrote: > >> I was very heartened to hear on IRC two days ago that OLPC have a >> kernel hacker (dsaxena) starting in June (to work on Gen 1.5), and >> that one of the first thing on the todo list was to get the OLPC >> patches applying to the linus kernel. This has just made me happy today. How much can we rely on this happening? Any plans regarding mesh support in NM? Thanks, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.84-on-a-XO
Adam, I will help, and if we're lucky some of the sugarlabs experts will dive in as well. It'd be great to get more testers. One thing we need to work on fine-tuning is how cjb's rawhide-xo and SoaS-on-XO relate. Both groups are in very close contact but I think things are still evolving (of course nobody wants to duplicate work, but there's a lot to consider). Martin On Thu, May 07, 2009 at 04:09:04AM -0400, Adam Holt wrote: > If someone can help me document this within > http://wiki.laptop.org/go/Support_FAQ I'll help you out every step of > the way -- if we can make a stable/supportable process :) > --A! > > > Subject: Re: [Olpc-uk] OLPC UK Library Update 20090505 > Date: Thu, 7 May 2009 08:58:44 +0100 > From: Martin Dengler > To: Christoph Derndorfer > CC: olpc...@lists.laptop.org, h...@laptop.org > > > On Wed, May 06, 2009 at 07:00:57PM +0200, Christoph Derndorfer wrote: >> Martin Dengler schrieb: >>> - All laptops have developer keys, have been flashed to latest >>> firmware (Q2E41), and have the latest Sugar-on-a-Stick build >>> (Rawhide/Fedora 11 + OLPC kernel) installed. >> >> Interesting, any guides as to how that's done? > > Yes - there are a few guides that involve the "livecd-iso-to-xo" > script. One just runs that on an iso and it spits out a jffs2 image > suitable for copy-nand'ing on to the XO. Of course the > livecd-iso-to-disk can be used to make an SD card for booting off of > if one doesn't want to overwrite the NAND. > >> It was my understanding that Sugar-on-a-Stick isn't expected to run >> well on the XO before F12 gets released in autumn. But it looks like >> I missed something here... > > You haven't missed anything - I have my own definition of "well": > > "working well [enough for the Libary]" means: > > 1) having a version of Sugar and activities such that patches will be > trivial to review and accept > > 2) having working wireless, power management, XO keys (most), dcon > drivers > > 3) having development tools like pylint and git pre-installed > > 4) sound and mesh networking not working > > I'm not recommending it for deployments/pilots. But it's coming along > quite well for developer use. > >> Thanks, >> Christoph > > Martin > > > > Subject: Re: [Olpc-uk] OLPC UK Library Update 20090505 > Date: Thu, 7 May 2009 09:03:14 +0100 > From: Martin Dengler > To: Peter Robinson > CC: Christoph Derndorfer , > olpc...@lists.laptop.org, h...@laptop.org > > > On Thu, May 07, 2009 at 12:59:49AM +0100, Peter Robinson wrote: > > >> - All laptops have developer keys, have been flashed to latest > > >> firmware (Q2E41), and have the latest Sugar-on-a-Stick build > > >> (Rawhide/Fedora 11 + OLPC kernel) installed. > > > > > > Interesting, any guides as to how that's done? > > > > > > It was my understanding that Sugar-on-a-Stick isn't expected to run > well > > > on the XO before F12 gets released in autumn. But it looks like I > missed > > > something here... > > > > It runs I think SoaS has a custom kernel with added patches for > > camera/sound/suspend. > > SoaS is shipping with a standard F11/rawhide kernel. My custom > version installs the latest OLPC kernel (older, but with the OLPC > patches you mention). > > I was very heartened to hear on IRC two days ago that OLPC have a > kernel hacker (dsaxena) starting in June (to work on Gen 1.5), and > that one of the first thing on the todo list was to get the OLPC > patches applying to the linus kernel. > > > Peter > > Martin > pgpSSLhnZ1jT4.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] versus, not
On Fri, May 8, 2009 at 10:37 AM, Bill Kerr wrote: > I'm not sure what is meant by a "big tent" Personally, I am building tools so... ... > when I look at minsky's theory of mind I see that he supports multiple > models of thinking but also argues against models of thinking that he thinks > are incorrect or which emphasise only one way of doing things, Exactly. I try to work to build things that are open (and useful) to many users, many (most?) of which may not agree with me. If you ask me what do I think is best, I may have an opinion, but I am an adaptable person. My software[1] is adaptable too. A tiny bit opinionated perhaps ;-) , but flexibility is more important. After all, practitioners have enough trouble with real life, I am not going to add a small-mind-designed bit of software to their problems. [1] Note: Most of my education related work is on Moodle but I'm not its designer. So "my software" is "my sometimes interesting changes to Moodle". The mind behind Moodle is Martin Dougiamas, and it's from him that I've picked the "flexible" mantra. People use Moodle for teaching in very open ways... and other people use Moodle in incredible small-minded, beancounting-style corporate training. A very big tent indeed. Very glad to be reading Alan's posts in this thread too. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] versus, not
I'm not sure what is meant by a "big tent" Why do some people want a big tent for learning theory but not a big tent which accepts both FOSS and proprietary software? Phrasing it that way is intended to encourage people to think about what sort of thing is learning and hopefully will not be interpreted as just being provocative for its own sake. you can have a big tent where people don't discuss learning theory because it's too hard to reach agreement you can have a big tent where people passionately argue about learning theory but actually listen to what each is saying and argue rationally when I look at minsky's theory of mind I see that he supports multiple models of thinking but also argues against models of thinking that he thinks are incorrect or which emphasise only one way of doing things, eg. although he helped create connectionism he now thinks it has too much influence that suggests another version of a big tent which I favour - cherry picking the best parts out of different learning theories / activities based on criteria (not stated here) that are substantial I don't believe that thinking people are agnostic about how people learn it seems to me that alan kay has presented a possibly strategic view of progress on these questions (that learning about bricks will not automatically lead to building arches, that we need more than just focusing on building blocks) - but that for various reasons we are not in a position to implement the learning materials based on that view in practice in the activities for me to sit in the big tent holding a strategic view feels different to "too hard basket", agnosticism or a tower of babble - teaching with an underlying strategic view is very different to just going along with the tide that would mean work to understand and implement that strategic view but also accept that we are not there yet (it will take some time) and so it is perfectably understandable and desirable that people will use and develop whatever is at hand or which they think important to develop - no one can stop that anyway accept by successful arguing someone out of a POV Does the "big tent" phrase add clarity to this conversation? On Tue, May 5, 2009 at 4:59 PM, Martin Langhoff wrote: > On Tue, May 5, 2009 at 3:03 AM, Walter Bender > wrote: > > Fair enough. I agree that *most* people on the list agree that there > > is not just one right way. And to use a metaphor that has been > > oft-spoken in the US news of late, Sugar Labs has to have a "big > > tent." > > > > Sugar itself has affordances that can be used in support of many > > educational approaches and virtually any content area. > > Completely for the big tent, and wide ranging use models. It also > means I have to swallow hard when people use things I build in ways > that I consider... not particularly good. You might hear me mention > that "that's a practise that I don't emphasize" ;-) > > cheers, > > > > > m > -- > martin.langh...@gmail.com > mar...@laptop.org -- School Server Architect > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Server-devel] OpenID Authentication and the Browser
On Fri, May 8, 2009 at 5:48 AM, Benjamin M. Schwartz wrote: > People interested in $SUBJECT may enjoy > > http://almaer.com/blog/who-do-i-trust-with-my-identity-erm-how-about-me-openid-weaves-into-the-browser > > I haven't quite figured out what they're doing. Makes sense -- it is the step that people who actually understand security (that is _not_ the OpenID designers ;-) [1] ) all insist that is required for a secure scheme to work... IOWs, promising, but I'll wait for it to pass the Ben Laurie sniff test. cheers, m [1] - That's clearly unfair, after all the attention OpenID has gotten, I'm sure they've learned something about secuity. But surely they didn't know much when they designed it. -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
