Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
2010/6/9 Luke Faraone l...@faraone.cc -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/09/2010 08:11 PM, Bernie Innocenti wrote: As far as I know, Browse is still the only hulahop user on this planet, so it's not like we need to keep it around for API compatibility. Actually, hulahop is used by pyjamas[1], as evidenced by these bug reports[2][3] spawned when sugar-hulahop was removed from Ubuntu Lucid. An aside, according to upstream this is not an integral part of their project, but it might be a good idea to involve them in the discussion. These days, I do my work in pyjamas - on the cloud. I have never used pyjamas on the desktop, but for people who do, hulahoop* was the least painful way to get there, and its removal sparked indignation. *OK, it's called hulahop, but this way all the code names mesh more surreally. Seriously, though: the fact that pyjamas-desktop can exist without hulahop doesn't make it attractive to lose it. It may not be integral, but I don't see anybody in the pyjamas world who would be replacing it any time soon, so it is essential as a practical matter. Jameson ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Feature] [DESIGN] Enhanced Color Selector
Click to change stroke color: = Outline Click to change fill color: = Body These are OK (ie, I vote -0), but personally, I'd go with Outline and Fill. I think that kids understand fill just as well, and it has the advantage of being the more technically-correct term. Jameson ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [GSoC] progress report
2009/6/4 Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org On Wed, Jun 03, 2009 at 05:31:03PM -0400, Benjamin M. Schwartz wrote: I am not knowledgeable about the present state of D-Bus isolation in Rainbow, but if it is insufficient it should be fixed in Rainbow, not in the browser. The bigger problem is that there's no (working) rainbow support at all in Sugar 0.84 and currently nobody is working on it for 0.86 (I might do it, but the version stuff goes first). This is a big problem. But pushing security concerns down to the activity level clearly is no solution; it is multiplying the work two different times, once for doing it in the wrong place and again for doing it many times. So I'd agree, webify should not worry about DBus security. Jameson ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Re: Reviving Sugarbot
Realistically, Sugarbot and Develop should ideally be coordinated. I can't make a commitment to revive sugarbot, but I can say that if someone does the work to get Sugarbot working I'll do some work to integrate it with Develop. And I'll be appropriately impressed and grateful to whoever steps forward, too, and I'll try to help if I can, without repainting your bike shed. Jameson 2009/5/20 Bernie Innocenti ber...@codewiz.org Anyone wants to take it over? Original Message Subject:Re: Reviving Sugarbot Date: Wed, 20 May 2009 15:58:40 -0400 From: Zach Riggle zachrig...@gmail.com To: Bernie Innocenti ber...@codewiz.org CC: Titus Brown ti...@idyll.org Bernie I am extremely busy this summer, so I won't be able to assist with development. I would be very glad to help you figure everything out to continue development of Sugarbot, though :-). Something to get you started is available here: http://code.google.com/p/sugarbot/wiki/HowDoesSugarbotWork Let me know if you have any questions, and I'll go into more detail :-D Zach On May 20, 2009, at 2:52 PM, Bernie Innocenti wrote: Hello, your project seems just what we need to augment our testing infrastructure: http://buildbot.sugarlabs.org/ Would you like to work on integrating it with the current versions of Sugar? And if you're too busy, would you be interested in helping us figure it out? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] add clock to frame
Well, if the frame always auto-hid after 10 seconds, and the delay for idle-suspend was 15 seconds, then it would work. I personally believe that the frame should be hidden more agressively - whenever there's a user action that doesn't address it, and after a longish timeout around 10 seconds. In my experience with kids, hitting the frame key and then trying to interact with the activity and being unable to is one of the more common hangups. (I'm afraid I don't understand the latest on suspend, but it's my understanding that there are some kind of micro-suspend periods which are separate from longer-term idle suspend.) Jameson 2009/5/3 p...@laptop.org sascha wrote: On Sat, May 02, 2009 at 05:39:21PM +0100, Martin Dengler wrote: [Clock behaviour in suspend] But I take your point...the answer is: no, it's not easy (with my simple patch). I'm not sure what the behavior should be (hide on idle?!, come out of suspend once a minute?!), really. With the XO going into suspend automatically, it should at least indicate that the clock has stopped as well (and no, the pulsing power LED is not enough). Showing an old time is _much_ worse than not showing it at all. given martin's point about the battery level, wireless strength, etc, all becoming stale as well, perhaps the best fix would be to always hide the frame during idle suspend. as far as i know, however, there's currently no mechanism for apps to learn that idle suspend is imminent. paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] add clock to frame
Anything else is just hacks on top of hacks. I disagree. Personally, I think auto-hiding the frame after a delay is a clean solution that's desirable anyway. But I do agree that the decision of whether to hide the frame or not should not be based on stopped clocks. Jameson ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keyboard shortcuts
(note: I suggest below that we use caps-lock as the frame key) 2009/4/30 Gary C Martin g...@garycmartin.com Still think this is a tough, disruptive sell for very small gains. We should focus on getting activity authors (and sugar) using the now fully functioning accelerator feature to self document shortcuts. Which part? This is actually three separate proposals: discoverable (translucent letters), ubiquitous (auto-assignment), and consistent (rearranging). Your comments about consistent are below, but I don't know if the above refers to discoverable or ubiquitous. If you mean that ubiquity is a small gain, noted; if you mean discoverability, I disagree and would like to hear you elaborate your argument. Also, since I'm coding, tough is a weak criticism. Anyway, just some quick comments: and responses On 1 May 2009, at 03:28, Jameson Quinn wrote: I am interested in making our keyboard shortcuts discoverable, ubiquitous, and consistent. --- snip --- '0x93' : 'frame', 'Insert' : 'frame', #for SoaS '0x00' : 'frame', #for SoaS on Xephyr, see below. None of my 3 Mac laptops has an Insert key, and the standard keyboard that ships with iMac desktops also has no insert. Think all Macs currently ship with such keyboards, sans numeric pad, though you can make a custom order for Apple Keyboard with Numeric Keypad... actually, just checked that key layout as well and no insert key either – but hey, you get 19 function keys for your money ;-) --- snip --- I hadn't seen this, I only knew from wikipedia that if your keyboard does have insert Apple sees it as help. Looking at a few pictures of Macbook keyboards, I have to say I like the minimalism, but it leaves few options. F5-F8 should ideally IMO be available to individual activities. That leaves caps lock, or key combos (I'd favor close-up combos such as alt-right_arrow.) I'd vote for caps lock. This is, of course, somewhat more radical than most of my other suggestions, so needs discussion. 'altctrlEscape': 'close_window_discard_from_journal', Not sure what this one is. Close the activity but don't show the naming dialog. Delete the resulting journal entry. --- snip --- #... alt-numeral should be like the top row of the frame, so alt-5 would be journal #and alt-6 first running activity So is the reason behind this idea to help keyboards without any F keys? Should this not also include the F5 key being made to show the Journal (equiv. to open_search I think). This is for keyboards without F keys, but it also gives a natural way to get the journal and individual activities. alt-shift-N with N5 could be close activity N-5. I think that F5 should be available to individual activities, so I'd vote against F5/Journal. I'd accept the majority decision, though. --- snip --- # the following are intended for emulator users #'altshiftf': 'frame', #removed #'altshifto': 'open_search', #removed #'altshiftr': 'rotate', #removed Why the removals?? Now I would have no working keys at all for accessing the frame! Because they're inconsistent with the master plan, and highly-non-discoverable too. --- snip --- ... Also, ctrl-numeral would choose toolbars, and toolbar tabs would get little translucent numbers when you held control. So what happens to an activity that uses some ctrl-numerals already (labyrinth does)? could it use F5-F8? I don't know what it does with these. In practice, the activity could get them by assigning them before creating that toolbar; ideally, I'd like this to be a consistent standard. For my bike-shed, I'd be happy with F1-F4 as is, F5 can be Journal, F6 could be frame, then we could make little bits of printed card with icons on, and kids could sticky-tape them just above their F keys ;-) OK, that's a vote. I vote against you. May the best bike-shed win! (And since I don't understand what your position on discoverable and ubiquitous is, I can't count your vote there). Jameson ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keyboard shortcuts
Eben, I'd like your comments on the discoverable/floaty-letters idea too. 2009/5/1 Eben Eliason eben.elia...@gmail.com I'd vote for caps lock. This is, of course, somewhat more radical than most of my other suggestions, so needs discussion. Hmmm, not sure. It seems to me that if the zoom-level buttons live in the F-keys, then the Frame button should as well. This keeps it at the top of the keyboard, as on the XO, and keeps a consistent single-key path to a very important element of the UI. And, for what it's worth, I don't think that activities should need to mess around with the F keys. I'd just as soon have banished them entirely, as the caps lock key, were they not required for compatibility. I think that activities should be using, for the most part, the ctrl shortcuts. Perhaps F5 - F8 should be reserved so that they can serve for the middle slider on the XO, and we can make one of F9 - F12 the Frame key? OK, but what do we do with the volume/brightness controls that are currently in F9-12? The other issue is that keyboards are inconsistent with the high F keys - for instance, the classmate has F11/F12 on the same key (ie, F12 is fn-F11). I find the alt-shift-n suggestion to be highly confusing myself. It sounds like a good way to accidentally close things, and I'm not sure I see the need in the end. Just press alt-n to switch to the activity, followed by alt-esc... OK, that was just an offhand idea. # the following are intended for emulator users #'altshiftf': 'frame', #removed #'altshifto': 'open_search', #removed #'altshiftr': 'rotate', #removed Why the removals?? Now I would have no working keys at all for accessing the frame! Because they're inconsistent with the master plan, and highly-non-discoverable too. Could we map any of those that would be dropped in the F9 - F12 range? For consistency, I guess we should have an overlay key there next to the frame key. Could rotate and/or search live there as well? OK, the grand unified proposal for these, after discussion on IRC and the above is: f,j,r,s,v,p,o - frame, journal, rotate, say, view source, screenshot (print), overlay (unimplemented) altshift[fjrsvp] = deprecated, but kept for emulator users on MacOS. alt[fjrsvp] = preferred method for above, discoverable through holding alt and reading the cheat sheet. F9-F12 = frame, journal, overlay, view source This order is changed from the XO, because of netbook keyboards missing dedicated F11/F12 keys. I'm agnostic about view source needing a dedicated key. Insert = frame (redundant) xo keymaps revised so that the volume and brightness controls are NOT F9-F12, but XF86AudioLowerVolume etc. F9-F12 would not be available from the XO keyboard. --- snip --- ... Also, ctrl-numeral would choose toolbars, and toolbar tabs would get little translucent numbers when you held control. So what happens to an activity that uses some ctrl-numerals already (labyrinth does)? could it use F5-F8? I don't know what it does with these. In practice, the activity could get them by assigning them before creating that toolbar; ideally, I'd like this to be a consistent standard. Hmm, I can see ctrl-n being useful to many activitiesbut tab switching would be advantageous as well. Could we use relative navigation for tabs, in the form of alt-right and alt-left, or similar? This might be more intuitive for kids than counting, and would't eat up as much of the shortcut space. I'd prefer ctrl-something, as it would make it easier to find shortcuts while holding ctrl. I think arrow keys is dangerous, plenty of editors want ctrl-arrow to mean something. The options then are [ and ]; , and .; ; and '; or - and +. Of these, I think that , and . are the best combination of logical (think and ), non-obscure, and uncommon-as-existing-shortcuts (ctrl-bracket and ctrl-plus are too common). The floaty discoverable letters could show and on the next and previous tabs. This is a bit more work to code than just the numbers, but it's doable. The downside is keyboard layouts which move these keys around, but I don't see an easy solution for that (except to redundantly map ctr- and ctrl-). Jameson ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keyboard shortcuts
2009/5/1 Martin Dengler mar...@martindengler.com On Fri, May 01, 2009 at 10:48:08AM -0600, Jameson Quinn wrote: OK, the grand unified proposal for these, after discussion on IRC and the above is: f,j,r,s,v,p,o - frame, journal, rotate, say, view source, screenshot (print), overlay (unimplemented) altshift[fjrsvp] = deprecated, but kept for emulator users on MacOS. I'd say just emulator users. alt[fjrsvp] = preferred method for above, discoverable through holding alt and reading the cheat sheet. F9-F12 = frame, journal, overlay, view source This order is changed from the XO, because of netbook keyboards missing dedicated F11/F12 keys. I'm agnostic about view source needing a dedicated key. I don't see the need for alt[fjrsvp]: we have frame, journal, and view source available in one click via F9-F11 (IIUC your some-netbooks-share-F11-and-F12 comment), and we have the existing, ubiquitous fallbacks of altshift[...]. Why deprecate the existing combinations in favor of combinations that are more likely to clash with existing applications? Because the alt keys are more consistent and discoverable. That's also why I don't just say emulator users above; the new keys would be available to non-mac emulator users. Finally, note that if the alt keys never get to sugar in macOS emulation, then activities already should be avoiding them. Insert = frame (redundant) What about CapsLock for Macs (non-emulation)? Honestly, if we want a consistent and more-useful remapping of CapsLock, we should consider making it control_R. But I'm ready to let others decide this, it's not a big deal for me. Martin ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keyboard shortcuts
I don't see how the alt keys are more consistent - I'll have to re-read the proposal and the definition of consistency. ctrl (and all modifier combos including it): application shortcuts alt: global sugar shortcuts I don't see why they're more discoverable, either - and my point you quoted was trying to point out why they didn't have to be: you have a whole other set of keys that are *meant* to be the ones discovered and used. The idea is that holding alt shows a cheat sheet of global shortcuts. Also, even without implementing that, it is easier to find single-mod shortcuts by trial and error than it is to find multiple-mod ones. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keyboard shortcuts
Sorry, seemed to have missed a conversation here, what's with idea that alt keys are not getting through to Sugar for emulators/Macs? I run sugar-jhbuild here in F10 under VirtualBox on a Mac, and Soas images as well. No problem with alt keys that I'm aware of. I have no experience in this regard. If this is true, all the more reason IMO to move from alt-shift- to just alt- Jameson ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Keyboard shortcuts
I am interested in making our keyboard shortcuts discoverable, ubiquitous,
and consistent. This is especially important because of the approximately
half a million demon-possessed trackpads that OLPC has shipped (not blaming;
I thought that the resistive pad was a cool idea too, in fact, it's still a
cool idea and the XO had a pretty good batting average with its attempted
miracles).
The overall plan is outlined at
http://wiki.sugarlabs.org/go/Design_Team/Vision/Proposals/Keyboard_Action .
I've posted it here before, but since I combined it with another idea about
the home view, it didn't get discussed much. I'm starting to code it, so I
want to get some more consensus before I go too far. I'll start with vision,
then talk about implementation.
The vision is to provide software support for three desirable qualities.
*Discoverable*. Without discoverability, shortcuts are useless. And we have
pre-literate kids as a part of our user base, so including ctrl-x in our
popdowns isn't going to cut it. My basic idea is that when the user
presses/holds ctrl, the shortcuts show up as translucent letters in front of
the toolbar buttons. Some open questions:
Delay? My instinct is yes, so that fast typers aren't slowed down by UI
candy, but a pretty small one - around 300-700 ms. I'd rather not make this
configurable.
Non-ctrl shortcuts: My idea is to have two lines: the top third of the
toolbar button can say Alt or Shift, then the bottom two thirds has the
letter. F5 or Pause or whatever should just say the key name. The problem
is, how do you distinguish ctrl-alt-a from alt-a, and ctrl-F5 from F5. IMO
it's not actually a tragedy if you just don't make that distinction.
*Ubiquitous. *To me, this goal means increasing our software support for the
developer/translator team assigning shortcuts. It's true, it's really just
one line and one string per button (customButton.props.accelerator =
_('ctrlb')) but that's a big nuisance for translators, and programmers are
meant to be lazy. So I think you should be able to assign the accelerator
from within the translatable string. GTK already has a similar mechanism,
but it's inappropriate. Setting the label to go _next will, if the
use_underline property is true, set the mnemonic, a kind of shortcut that
works only if the control's visible, to alt-n, and draw the label with the n
underlined. Four problems: we care about tooltip, not label; we want the
shortcut to be available when you're on a different toolbar; we want ctrl,
not alt; and this doesn't seem to work in sugar, for reasons I've not
investigated. So I propose doing the same thing, but using the tooltip, a
real shortcut, ctrl, and the character u\u00ad which is soft hyphen, ie,
by nature an invisible typesetting mark. Issues: I haven't tested if you can
use the backslash escape to get this in Pootle, if not it's a problem.
*Consistent*. This means dealing with all the shortcuts in a unified
fashion. First principle is, ctrl for activity shortcuts, alt for
global/frame ones, ctrl-alt for modified ctrl shortcuts (ie, ctrl-alt-v is
paste-and-pop-clipboard), ctrl-shift or alt-shift is backwards (redo or
alt-shift-tab). Here's my list of global shortcuts/key assignments, copied
from keyhandler.py with my proposed changes in bold, please add anything
I've forgotten:
_actions_table = {
'F1' : 'zoom_mesh',
'F2' : 'zoom_group',
'F3' : 'zoom_home',
'F4' : 'zoom_activity',
'F9' : 'brightness_down',
'F10' : 'brightness_up',
'altF9' : 'brightness_min',
'altF10' : 'brightness_max',
'XF86AudioMute': 'volume_mute',
'F11' : 'volume_down',
'XF86AudioLowerVolume' : 'volume_down',
'F12' : 'volume_up',
'XF86AudioRaiseVolume' : 'volume_up',
'altF11' : 'volume_min',
'altF12' : 'volume_max',
'0x93' : 'frame',
'Insert'
'0xEB' : 'rotate',
'altTab' : 'next_window',
'altshiftTab' : 'previous_window',
'altEscape' : 'close_window',
'0xDC' : 'open_search',
# the following are intended for emulator users
'altshiftf': 'frame',
'altshiftq': 'quit_emulator',
'XF86Search' : 'open_search',
'altshifto': 'open_search',
'altshiftr': 'rotate',
'altshifts': 'say_text',
-SOAS
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keyboard shortcuts
Oops. Sorry, I didn't know that tab was send in this gmail's keyboard
shortcuts. Resend, more complete at bottom.
-- Forwarded message --
From: Jameson Quinn jameson.qu...@gmail.com
Date: 2009/4/30
Subject: Keyboard shortcuts
To: sugar-devel sugar-devel@lists.sugarlabs.org
I am interested in making our keyboard shortcuts discoverable, ubiquitous,
and consistent. This is especially important because of the approximately
half a million demon-possessed trackpads that OLPC has shipped (not blaming;
I thought that the resistive pad was a cool idea too, in fact, it's still a
cool idea and the XO had a pretty good batting average with its attempted
miracles).
The overall plan is outlined at
http://wiki.sugarlabs.org/go/Design_Team/Vision/Proposals/Keyboard_Action .
I've posted it here before, but since I combined it with another idea about
the home view, it didn't get discussed much. I'm starting to code it, so I
want to get some more consensus before I go too far. I'll start with vision,
then talk about implementation.
The vision is to provide software support for three desirable qualities.
*Discoverable*. Without discoverability, shortcuts are useless. And we have
pre-literate kids as a part of our user base, so including ctrl-x in our
popdowns isn't going to cut it. My basic idea is that when the user
presses/holds ctrl, the shortcuts show up as translucent letters in front of
the toolbar buttons. Some open questions:
Delay? My instinct is yes, so that fast typers aren't slowed down by UI
candy, but a pretty small one - around 300-700 ms. I'd rather not make this
configurable.
Non-ctrl shortcuts: My idea is to have two lines: the top third of the
toolbar button can say Alt or Shift, then the bottom two thirds has the
letter. F5 or Pause or whatever should just say the key name. The problem
is, how do you distinguish ctrl-alt-a from alt-a, and ctrl-F5 from F5. IMO
it's not actually a tragedy if you just don't make that distinction.
*Ubiquitous. *To me, this goal means increasing our software support for the
developer/translator team assigning shortcuts. It's true, it's really just
one line and one string per button (customButton.props.accelerator =
_('ctrlb')) but that's a big nuisance for translators, and programmers are
meant to be lazy. So I think you should be able to assign the accelerator
from within the translatable string. GTK already has a similar mechanism,
but it's inappropriate. Setting the label to go _next will, if the
use_underline property is true, set the mnemonic, a kind of shortcut that
works only if the control's visible, to alt-n, and draw the label with the n
underlined. Four problems: we care about tooltip, not label; we want the
shortcut to be available when you're on a different toolbar; we want ctrl,
not alt; and this doesn't seem to work in sugar, for reasons I've not
investigated. So I propose doing the same thing, but using the tooltip, a
real shortcut, ctrl, and the character u\u00ad which is soft hyphen, ie,
by nature an invisible typesetting mark. Issues: I haven't tested if you can
use the backslash escape to get this in Pootle, if not it's a problem.
*Consistent*. This means dealing with all the shortcuts in a unified
fashion. First principle is, ctrl for activity shortcuts, alt for
global/frame ones, ctrl-alt for modified ctrl shortcuts (ie, ctrl-alt-v is
paste-and-pop-clipboard), ctrl-shift or alt-shift is backwards (redo or
alt-shift-tab). Here's my list of global shortcuts/key assignments, copied
from keyhandler.py with my proposed changes in bold, please add anything
I've forgotten:
_actions_table = {
'F1' : 'zoom_mesh',
'F2' : 'zoom_group',
'F3' : 'zoom_home',
'F4' : 'zoom_activity',
'F9' : 'brightness_down',
'F10' : 'brightness_up',
'altF9' : 'brightness_min',
'altF10' : 'brightness_max',
'XF86AudioMute': 'volume_mute',
'F11' : 'volume_down',
'XF86AudioLowerVolume' : 'volume_down',
'F12' : 'volume_up',
'XF86AudioRaiseVolume' : 'volume_up',
'altF11' : 'volume_min',
'altF12' : 'volume_max',
'0x93' : 'frame',
*'Insert' : 'frame', #for SoaS
'0x00' : 'frame', #for SoaS on Xephyr, see below.*
'0xEB' : 'rotate',
'altTab' : 'next_window',
'altshiftTab' : 'previous_window',
'altEscape' : 'close_window',
*'altctrlEscape': 'close_window_discard_from_journal',*
'0xDC' : 'open_search',
*'alt1' : **'zoom_mesh',
#... alt-numeral should be like the top row of the frame, so alt-5 would be
journal
#and alt-6 first running activity
'altEnter' : 'hide-toolbar', #if implemented by activity
'altv' : 'view-source
Re: [Sugar-devel] Keyboard shortcuts
A few more little things which I didn't include in messages 0.9 and 1.0 -Insert key as frame key would not currently work in Xephyr. Xephyr hears keycode 0 when you hit insert, which should be invalid. You cannot set 0x00 as an accelerator because eggaccelerators.c lines 350-352 explicitly catch that error. I propose simply removing this useless error-checking, which would allow us to workaround the stupid xephyr bug on that one issue without affecting anyone else. The rest of the following ideas are on the wiki proposal but I didn't mention them because don't plan on implementing in this round. -Holding alt should bring up a popup window explaining the global shortcut keys. Which also suggests the idea of help and context-sensitive-help keys; perhaps alt itself? -modifiers should be sticky for a configurable time delay or until the first keystroke, whichever is first. Except that sticky-ctrl would differ from normal-ctrl when it modified a global key combo: sticky-ctrlF1 would not be ctrlF1 but just F1 to the activity instead of to sugar. and-one-more-thing-ly y'rs, Jameson ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Kartik - internship outside GSoC
Regarding my interests, it has always been towards networking and as much away from UI as I can :). The areas I am interested in working includes communication or any other background improvements sugar requires. I was particularly impressed by Groupthink because it solves a core problem for sugar and I will definitely like to do some thing of this sort (research+implementation). I guess a lot of work will be done on Groupthink as a part of this year's Gsoc. Another research oriented project I found here http://wiki.sugarlabs.org/go/DevelopmentTeam/ProjectIdeas is the Toolkit for dissimilar activity collaboration idea. Can someone please update me on this and whether this will be an appropriate project to start for me and if I will have a mentor to assist me on this (high priority). My own, completely personal opinion on dissimilar activity collaboration is that it is a solution searching for a problem. I understand that there are real use cases, but I haven't seen one that's nearly as compelling as the viral-activity idea (idea 2 of the ones I sent). This is just me commenting, I hope that others with opposing viewpoints will also comment. As to Groupthink, I think that it would be ill-advised to try to force you and Bemasc to work together without a very clear delineation of responsibility which minimizes dependencies. I also think it would be very hard to draw such a line, though you're welcome to prove me wrong on this latter point. Regarding the two ideas listed in the earlier mail I will be more inclined towards the second one, but my priority will go towards the one I mentioned above. One thing which I will prefer to be their in my project is that it should fall completely within Sugar and will require less dependence on any other organization. Please take this factor in consideration too when you comment on any project idea. I think that the viral activity idea could be a good fit for you. It certainly looks as if it falls entirely inside Sugar, relying on only existing functionality from Telepathy. Thanks for this gesture, I seriously appreciate this. The least we could do, in the circumstances. Jameson On Sun, Apr 26, 2009 at 8:34 PM, Jameson Quinn jameson.qu...@gmail.com wrote: I hope we can do this for you, and would be really happy if it comes through. However, as much as it pains me, I think you will have to go through some of the application process over again. We don't need to interview you again, once is plenty and you did well. But we do need a specific proposal, with clear deliverables - which could easily take a week or more for you to create - and then at least a few days for us to evaluate the merits of such a proposal and our ability to support it. Otherwise, how can we meaningfully evaluate whether you've completed your internship? I suspect that we'd be ready to accommodate whatever reasonable calendar you set up for those steps. Jameson 2009/4/26 kartik rustagi kashes...@gmail.com Hi David, I talked to few of my seniors and the Training and Placement Cell at my school and they told me that the only official letter I will be needing are: 1) 'Joining Letter' which will state the date I will be starting my internship and my supervisor (mentor) at the organization. This letter should preferably on the letter head of the organization or should have some other kind of authentication. 2) And at the end of training I will need a completion certificate. I will scan and mail you the format of these documents, that will be more convenient. The official period of the internship will start from the last week of May after the university exams (going on right now). Delhi College of Engineering : www.dce.ac.in, www.dce.edu Regards Kartik Rustagi On Fri, Apr 24, 2009 at 8:28 AM, David Farning dfarn...@sugarlabs.org wrote: On Thu, Apr 23, 2009 at 4:10 PM, Jameson Quinn jameson.qu...@gmail.com wrote: Kartik, I think we can definitely find a useful way for you to contribute and fulfill your internship requirements. You should write more about what kind of project would interest you; the suggestions below focus more on communications, because that's what I know as your expertise, but if you are interested in UI, security, graphics, or something else, there are probably other ideas for you. I'm not really the person to talk to about communications. I was talking with bemasc (benjamin schwartz, copied on this email) and we had two ideas: Some way of completing your original project idea without involving Collabora/Telepathy too much. For instance, Bemasc mentioned Webdav, but said The problem is that it has no (standardized or otherwise) connection to XMPP, so Collabora isn't much interested in shoving it into Salut in some ad-hoc way So it would have to live outside of Salut, but still ask
Re: [Sugar-devel] Print Support (journal vs activity)
OK, we just had an animated conversation on IRC in which almost nothing was generally agreed-on. Here's my refined proposal based on that conversation. Print preview option in journal Uses cups filters to convert to PDF Set of cups filters available is distribution dependent. An officially print enabled distribution would have a certain limited set of filters installed (the obvious ones). Filters outside this set would be mildly discouraged to avoid inconsistent behaviour. filters would NOT be part of sugar-platform, to leave maximum flexibility for deployments if you had anything but the exact, limited set of print-enabled filters, printing behaviour would be officially undesigned and unsupported but nevertheless probably sane enforcement would be social, not digital the PDF thus created would have special print-me tag To add to print queue, or any other queue management, you'd use Browse there are several options for streamlining the workflow. the moodle form could have metadata in the tag for the upload control to tell sugar to please filter for print-me tag this means making sugar understand this kind of metadata - independently useful you could make a print activity, a spin of browse, which handles PDFs it would open the PDF using a pdf-viewer plugin it would have an enqueue menu item choosing this menu item would go to moodle and put the pdf in the upload tag (using some greasemonkey-like trick) You could modify sugar to know when to use Print instead of Read by default, based on print-me tag using something in activity.info this functionality would be independently useful Activities which wanted printing but did not naturally produce a format within our basic filter list, could have a print preview menu item and use gtkprint to export to pdfs with a print-me tag gtkprint would be a dependency of sugar ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support (journal vs activity)
Ooops, I forgot. In my proposal, local printing would be done by a separate activity which handled only PDFs. Many deployments would never install this separate activity. On Tue, Apr 21, 2009 at 11:58 AM, Jameson Quinn jameson.qu...@gmail.comwrote: OK, we just had an animated conversation on IRC in which almost nothing was generally agreed-on. Here's my refined proposal based on that conversation. Print preview option in journal Uses cups filters to convert to PDF Set of cups filters available is distribution dependent. An officially print enabled distribution would have a certain limited set of filters installed (the obvious ones). Filters outside this set would be mildly discouraged to avoid inconsistent behaviour. filters would NOT be part of sugar-platform, to leave maximum flexibility for deployments if you had anything but the exact, limited set of print-enabled filters, printing behaviour would be officially undesigned and unsupported but nevertheless probably sane enforcement would be social, not digital the PDF thus created would have special print-me tag To add to print queue, or any other queue management, you'd use Browse there are several options for streamlining the workflow. the moodle form could have metadata in the tag for the upload control to tell sugar to please filter for print-me tag this means making sugar understand this kind of metadata - independently useful you could make a print activity, a spin of browse, which handles PDFs it would open the PDF using a pdf-viewer plugin it would have an enqueue menu item choosing this menu item would go to moodle and put the pdf in the upload tag (using some greasemonkey-like trick) You could modify sugar to know when to use Print instead of Read by default, based on print-me tag using something in activity.info this functionality would be independently useful Activities which wanted printing but did not naturally produce a format within our basic filter list, could have a print preview menu item and use gtkprint to export to pdfs with a print-me tag gtkprint would be a dependency of sugar ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Print Support (journal vs activity)
Vamsi, for your reference, here is the discussion on IRC in which nobody agreed on anything, but we all wanted to take over design of your project. We're just being enthusiastic, and there's some significant degree of bike-shedding http://en.wikipedia.org/wiki/Parkinson%27s_Law_of_Trivialityhere. In the end, you are the engineer, and aa is the manager; anything you design that's OK with him is fine. Your job right now is to listen to and participate in the discussion, but set a strict time limit (a few days, I'd say). When the time is up, you write up your design, get aa's OK, and then ignore us from then on :). (the IRC discussion below is tangled and confusing. At the end we agree to do it on this mailing list, so if you want to skip reading below, that's fine. I'm just posting it in case you want to see the sausage being made.) [11:08] tomeu homunq: have some problems following your last email about printing [11:09] tomeu what means default action from journal for print-me pdfs? [11:09] -- satellitFbe-74c6 has joined this channel (n= u...@208-100-132-172.bendbroadband.com). [11:12] homunq tomeu: there would be some metadata besides mime-type, something like sub-type [11:12] homunq all pdfs created for printing would have a specific sup-type. This would make them print-me pdfs. [11:12] tomeu ok, what would that metadata be? which component would use that new property? [11:13] homunq sugar, when choosing which activity to use as a default, when several activities handle a given mime-type, would give preference to activities which have the same sub-type metadata. [11:14] homunq does that make sense? [11:14] tomeu why do activities other than Read need to open those pdfs? [11:14] homunq so both print and read would handle pdfs. [11:15] homunq print would be, within GSoC scope, an activity with no UI - just enqueue and terminate. [11:15] -- eben has left this server (Read error: 110 (Connection timed out)). [11:15] homunq eben, we hardly knew ye. [11:16] homunq is that clear? And should I make the same clarifications on ML? [11:16] tomeu homunq: why do we need an activity with no UI? [11:17] tomeu homunq: enqueue should be pretty easy to do in the journal by using gtkprint [11:17] homunq um, because that's the work flow? [11:17] tomeu just like we don't have an activity for copying files from a usb stick to the journal [11:17] tomeu homunq: which workflow? [11:17] homunq I mean, there would be several versions/updates of the activity possible. [11:18] tomeu by sending a file to the print queue is quite trivial in pygtk [11:18] homunq the no-UI version is just alpha, for GSoC. [11:18] tomeu s/by/but [11:18] homunq what print queue? [11:18] tomeu and about the preview UI, why not just use Read? [11:18] homunq the moodle queue on the XS? [11:18] tomeu homunq: cups, lpr, whatever [11:18] tomeu the moodle queue, I think it's enough with file uploading in browse for now [11:19] tomeu that gives us authentication and is already done [11:19] homunq OK, so print activity is a spin of browse. [11:19] tomeu printing from the journal means for me to just submit a file to the local printing queue [11:19] homunq the local printing queue is meaningless. [11:20] tomeu homunq: well, it's the same thing you have in windows when you send documents to print [11:20] tomeu in most cases won't make sense, but it's stuff that it's already done [11:20] homunq yes but the moodle queue is the whole point of this GSoC [11:20] tomeu and will be important for a teacher printing from sugar to an attached printer, for example [11:21] tomeu homunq: ok, I don't think it's needed to implement local printing in this gsoc [11:21] -- J5 has joined this channel (n= quint...@c-24-91-155-241.hsd1.ma.comcast.net). [11:21] homunq but we don't want to give every kid UI that only the teacher will use. Much confusion results. [11:21] tomeu so for uploading the file to moodle, can we just let the user use browse like would do for any other moodle-related stuff? [11:21] tomeu homunq: sugar will be used out from classrooms [11:22] tomeu homunq: want it or not, we are being asked to be able to directly print from sugar, and it's quite cheap to implement [11:22] tomeu homunq: but I would prefer if the gsoc project focused on moodle [11:22] tomeu don't worry about this now [11:22] homunq OK. So the workflow is: print to pdf. Resulting pdf has some print-me tag. Browse to upload - can search for print-me tag for easier upload. [11:23] homunq print to pdf is from inside journal, to journal. [11:24] tomeu not sure I understand the importance of that print-me tag [11:25] *** nubae1 is now known as Nubae. [11:25] homunq future enhancement is to do a spin of browse that handles PDF, and has a print-me menu item which will pre-fill the upload form with the given pdf. [11:25] tomeu but on the other hand, I think it may be good to start tagging entries automatically as we do stuff with entries, if it doesn't become cumbersome for the user [11:25] aa me neither...
Re: [Sugar-devel] A bot activity for sugar
I definitely like this idea. It is a fun way for kids to provide information services such as technical support. I would give it a simple eliza-like engine and let the kids go crazy with it. Of course, should you be accepted for GSoC, your primary responsibility would be to your project... Jameson On Tue, Apr 14, 2009 at 5:47 AM, Vamsi Krishna Davuluri vamsi.davul...@gmail.com wrote: Hello, So I have been working on an IRC bot for a while, and an idea had occurred, what if we have a graphical bot with a few limited animations for now, make it an activity, and feed it with help and documentation on every other activity and itself ofcourse. In the future a language dictionary and such can be embedded into this bot. The bot's graphical features can be coded with pygtk(for the widget frame, text input), some pyglet/pygame for animations http://pyglet.org This will be most entertaining/ fun for any kid. As I remember my own experiences with such bots from a particular os. Kids love interaction, graphical interaction is by far the fastest way to plant knowledge about anything. Give me your opinions on this, maybe this will be something I will work on for sugar in the near future ;) Thank you Vamsi Krishna Davuluri ___ 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] Fwd: Proposal of Google Summer of Code
Your mistake was that you created a document instead of a proposal in google's web app. I have forwarded your message and explained the situation to google's GSoC administrator to see what we can do. There's nothing else I can do to help you. Sincerely, Jameson On Sun, Apr 5, 2009 at 11:00 AM, Nathalia Sautchuk Patrício nathalia.sautc...@gmail.com wrote: Jameson, I did understand. I put my proposal in the Google's web app before the deadline. But, I checked now and it is not there anymore. I am desperate since I put a lot of effort on getting writing my proposal and everybody saw it during the last days. There are someting that could be done? I really want to participate in this GSoC and I can't understand why my proposal is not there Also, I put my proposal in the documents list inside the GSoC web, which you can check in the attached screenshot. It's is a copy of my proposal, and it is not modified after the deadline. Could Google consider this copy? Regards, Nathalia Sautchuk Patrício http://febracev.wordpress.com/ Antes de imprimir, pense em sua responsabilidade social e com o MEIO AMBIENTE. On Sat, Apr 4, 2009 at 4:47 AM, Jameson Quinn jameson.qu...@gmail.comwrote: Nathalia, I am truly sorry, but since you did not get your application into Google's web app by the deadline, we are unable to consider you for Google Summer of Code. However, we would be happy if you are still interested in doing the project, and could probably assign you an unofficial mentor (I'll have to see how many slots Google assigns us before I can say that definitely though). I tried to make this clear, and it was clearly stated in several places on the mailing list, wiki, and google's site. I am sorry that I did not manage to get this message to you. Thanks, Jameson 2009/4/3 Nathalia Sautchuk Patrício nathalia.sautc...@gmail.com Thanks a lot for all the feedbacks. It is very important. I improve my proposal, if anyone could read it I'm pleased. Regards Nathalia Sautchuk Patrício http://febracev.wordpress.com/ Antes de imprimir, pense em sua responsabilidade social e com o MEIO AMBIENTE. On Thu, Apr 2, 2009 at 10:07 PM, Eben Eliason e...@laptop.org wrote: I had this idea when I was making the very first mockups of Paint, and I think it's a great idea! Check out the mockup: it's the brush with the little gear next to it, which I always referred to as the behavior brush. http://wiki.laptop.org/go/Image:Activity_paint_tools.jpg The secondary palette for the brush would offer a list of different behaviors (which should be object which can be copied, shared, installed, etc., ideally). More importantly, the behaviors would be defined by simple scripts which took some basic pre-defined parameters (or maybe even allowed the creator of the behavior to define new parameters, linked to sliders or checkboxes or what have you...not sure), offered some predefined ways to size the brush, set colors, draw shapes, and make brush strokes, and thus allowed creation of behaviors with some simple syntax. As an example, you could have a mirror behavior which read in the current coordinates, and then made two marks with the brush mirrored across the middle of the canvas. A custom parameter could define which axis (or axes) were mirrored. You could have brushes which added randomness to the position making squiggly lines; or a brush which set the color based on the time to draw rainbow strokes; or a brush that worked like an airbrush of star shapes. The possibilities are endless, I think. Anyway, as Ben said, focus isn't on activities; but I wanted to chime in since I think this is truly a fantastic idea and I'd love to see it happen. Eben PS. I also had plans to allow behavior shapes, as well: http://wiki.laptop.org/go/Image:Activity_paint_shapes_polygon.jpg On Thu, Apr 2, 2009 at 8:28 PM, Nathalia Sautchuk Patrício nathalia.sautc...@gmail.com wrote: Hello everybody, I put my GSoC Proposal here: http://wiki.sugarlabs.org/go/Summer_of_Code/2009/Oficina If somebody has a feedback send me an e-mail (personally or in this list) or put in the discussion page in wiki. Thanks a lot... Regards Nathalia Sautchuk Patrício http://febracev.wordpress.com/ Antes de imprimir, pense em sua responsabilidade social e com o MEIO AMBIENTE. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Proposal of Google Summer of Code
Nathalia, I am truly sorry, but since you did not get your application into Google's web app by the deadline, we are unable to consider you for Google Summer of Code. However, we would be happy if you are still interested in doing the project, and could probably assign you an unofficial mentor (I'll have to see how many slots Google assigns us before I can say that definitely though). I tried to make this clear, and it was clearly stated in several places on the mailing list, wiki, and google's site. I am sorry that I did not manage to get this message to you. Thanks, Jameson 2009/4/3 Nathalia Sautchuk Patrício nathalia.sautc...@gmail.com Thanks a lot for all the feedbacks. It is very important. I improve my proposal, if anyone could read it I'm pleased. Regards Nathalia Sautchuk Patrício http://febracev.wordpress.com/ Antes de imprimir, pense em sua responsabilidade social e com o MEIO AMBIENTE. On Thu, Apr 2, 2009 at 10:07 PM, Eben Eliason e...@laptop.org wrote: I had this idea when I was making the very first mockups of Paint, and I think it's a great idea! Check out the mockup: it's the brush with the little gear next to it, which I always referred to as the behavior brush. http://wiki.laptop.org/go/Image:Activity_paint_tools.jpg The secondary palette for the brush would offer a list of different behaviors (which should be object which can be copied, shared, installed, etc., ideally). More importantly, the behaviors would be defined by simple scripts which took some basic pre-defined parameters (or maybe even allowed the creator of the behavior to define new parameters, linked to sliders or checkboxes or what have you...not sure), offered some predefined ways to size the brush, set colors, draw shapes, and make brush strokes, and thus allowed creation of behaviors with some simple syntax. As an example, you could have a mirror behavior which read in the current coordinates, and then made two marks with the brush mirrored across the middle of the canvas. A custom parameter could define which axis (or axes) were mirrored. You could have brushes which added randomness to the position making squiggly lines; or a brush which set the color based on the time to draw rainbow strokes; or a brush that worked like an airbrush of star shapes. The possibilities are endless, I think. Anyway, as Ben said, focus isn't on activities; but I wanted to chime in since I think this is truly a fantastic idea and I'd love to see it happen. Eben PS. I also had plans to allow behavior shapes, as well: http://wiki.laptop.org/go/Image:Activity_paint_shapes_polygon.jpg On Thu, Apr 2, 2009 at 8:28 PM, Nathalia Sautchuk Patrício nathalia.sautc...@gmail.com wrote: Hello everybody, I put my GSoC Proposal here: http://wiki.sugarlabs.org/go/Summer_of_Code/2009/Oficina If somebody has a feedback send me an e-mail (personally or in this list) or put in the discussion page in wiki. Thanks a lot... Regards Nathalia Sautchuk Patrício http://febracev.wordpress.com/ Antes de imprimir, pense em sua responsabilidade social e com o MEIO AMBIENTE. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GSoC Proposal: Multimedia Broadcasting
It sounds as if your proposal is not so much an activity as the ability to screencast whatever you're doing on the XO, p2p. And it would be even better if the watchers had the ability to participate. Chris Ball has already made a prototype of something like thishttp://blog.printf.net/articles/2009/01/26/multi-pointer-remote-desktop. It would be an excellent GSoC project to take this prototype and get it closer to where it could be a part of sugar for all activities. Just how close you think you can get it, is something you'd have to research - perhaps with the help of IRC. If you can come up with the beginnings of a workable proposal for this, and get it submitted before the deadline, you definitely deserve to be on our GSoC team! Get busy... Jameson On Thu, Apr 2, 2009 at 4:52 PM, Geza Kovacs gkov...@mit.edu wrote: Hi all, I am proposing a Multimedia Broadcasting activity for GSoC 2009, and would appreciate any feedback or potential mentors. The idea is described at: http://wiki.sugarlabs.org/go/Multimedia-broadcasting This proposal is somewhat a variation on the standard audio-video chatting concept; rather than having students audio-video chat one-on-one, which would be redundant in a classroom where the person is physically nearby, I believe broadcasting audio and video streams displaying presentations or live experiments locally to the masses via streaming on their laptops, thereby replacing the need to use projectors, would be a good usage of the available video and audio capture sources, in a classroom setting. For full details please read the proposal. Regards, Geza ___ 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] ideal flash activity to be remade as karma activity
3 months is a very short period to bring not only 2 but 4 people to work together across multiple time zones. I brought this up on #gsoc yesterday, and LH (the top authority) was somewhat skeptical about any coordination. I said we would leave it up to the students involved, and she said that sounded good, but Google would have to approve any final plan, and they wanted to avoid any dependencies, whether implicit or explicit, on the future work of anyone besides the mentor and the student. Jameson ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ideal flash activity to be remade as karma activity
Subzero http://wiki.sugarlabs.org/go/Karma, you have competitionhttp://wiki.sugarlabs.org/go/Webified_Toolkit . Lucian, you should check out the mailing list threads for talk between Bryan and Felipe; they are talking about much the same ideas you are. Bryan, you should include Lucian in your forwards. This is not intended to endorse either Lucian or Subzero. This is one of our highest-priority projects for GSoC, and it is even conceivable that we could even accept both of your proposals, to be attempted independently. Both of you, feel free to take ideas from each other's proposals, but remember, we're assuming that you are doing that, and we'd like to see you give fair attribution. You're also both welcome to submit a backup proposal on another idea, either from the ideas list or of your own invention; it seems clear that you are both good applicants, and having a backup proposal will help us do you both justice in case you both make the cut. We will not let the presence or absence of backup proposals bias us in which one of you we choose to do the Karma idea. Good luck, may the best proposal win! Jameson 2009/3/24 Bryan Berry br...@olenepal.org http://hg.olenepal.org/6_Maths_CoOrdinates_22_swf/ Subzero, I think this might be a great flash activity to redo for Karma. Let me know if you have trouble running it on your regular machine. It is in Nepali but I think you will be able to figure it out. I really like how it demonstrates the concepts of coordinates and lets kids play w/ those concepts. You can also download our latest stable monster E-Paath bundle from here (224 MB) http://dev.olenepal.org/E-Paath-2/STABLE/ -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ideal flash activity to be remade as karma activity
Keep in mind that we have no idea how many students we'll get from Google. So you are not only competing against those who submit a proposal for the same idea, you are competing against all the other project ideas as well. OTOH, the more applicants we get, the more slots we are likely to get. So in a way you are also cooperating with the other proposals (and with any friends whom you convince to apply) to increase our slot allotment. It's not all about competition. Cheers, Jameson ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ideal flash activity to be remade as karma activity
If the projects can be made to work 100% independently and yet still complement each other, then we are good. That was the idea of my suggestion. 20% redundancy, 80% separate; with a step of choose whichever version of the redundant stuff is better on day X. If one side flakes out, the other side is not hurt; the only thing that can happen is you can have to switch to presumably a better version of what you already have after 2 weeks. For this to work, you would not want the redundancy to be more than 10-20% at the start; but I think it is consistent with Google's mandate. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] GSoC applications open until April 3 - Please continue to promote Sugarlabs GSoC
The Google Summer of Code applications period is open now, for both Sugar Labs http://socghop.appspot.com/org/show/google/gsoc2009/sugarlabs and other participating organizationshttp://socghop.appspot.com/program/accepted_orgs/google/gsoc2009, and runs until 3 April at 19:00 UTC. We have had a fair number of interested students in IRC and on the mailing lists, and last I checked we had 4 generally strong applications in the wiki categoryhttp://wiki.sugarlabs.org/go/Category:2009_GSoC_applications. However, we have over 13 mentors signed up;* the more applications we get, the more slots we will be assigned*; and there are no applications yet in some of our important project ideashttp://wiki.sugarlabs.org/go/DevelopmentTeam/ProjectIdeas. So please, use your blogs, your tweets, and even your actual mouth, to promote GSoC and encourage more high-quality students (at any level, as long as they're 18 or over) to apply; and of course, feel free to apply yourself. The sooner you start to apply, the more time you'll have to refine your idea. The steps to apply are: 1. write out an idea in the wiki categoryhttp://wiki.sugarlabs.org/go/Category:2009_GSoC_applications 2. get comments on that idea by discussing it on these mailing lists and/or IRC 3. repeat steps 1 and 2 to refine your idea as many times as possible 4. sign up on google's webapp http://socghop.appspot.com/ and submit your application to sugarlabs there, preferably by April 1 5. You can continue to refine your idea until the deadline on April 3. Cheers, Jameson Quinn ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] jhbuild hangs
It seems you are missing some undeclared dependencies. Try adding
libpopt-dev, zip, unzip, python-gnome2, python-gnome2-desktop; I found these
in an old version of the jhbuild page,
http://wiki.sugarlabs.org/index.php?title=Development_Team/Jhbuildoldid=21330#Dealing_with_dependencies
Jameson
On Tue, Mar 24, 2009 at 5:56 PM, Edward Cherlin echer...@gmail.com wrote:
On Tue, Mar 24, 2009 at 12:49 PM, Sascha Silbe
sascha-ml-ui-sugar-de...@silbe.org wrote:
On Tue, Mar 24, 2009 at 11:19:33AM -0700, Edward Cherlin wrote:
1237918544.817512 STARTUP: Starting the shell
moku...@mokurai-laptop:~/dev/jhbuild/sugar-jhbuild$ XIO: fatal IO
error 11 (Resource temporarily unavailable) on X server :0.0
after 452 requests (452 known processed) with 0 events remaining.
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server
:100.0
after 496 requests (496 known processed) with 0 events remaining.
Are the last few lines the result of you killing Xephyr manually or did
they
appear immediately?
Manual kill.
If the latter, sugar-emulator isn't hanging but finishing
immediatly (you can see the shell prompt buried in there). This might
sound
like nitpicking, but is an important distinction (as the possible causes
are
different).
Right.
The first thing to do is to check ~/.sugar/default/logs/shell.log for
errors.
Thanks. I didn't know where to start. So is it the gconf problem? I
have the Ubuntu gconf2 package installed.
---
GErrorTraceback (most recent call last)
/home/mokurai/dev/jhbuild/sugar-jhbuild/install/bin/sugar-session in
module()
171 print 'Ctrl+C pressed, exiting...'
172
-- 173 main()
global main = function main at 0x2f91488
174
175
/home/mokurai/dev/jhbuild/sugar-jhbuild/install/bin/sugar-session in main()
135 logger.start('shell')
136
-- 137 intro.check_profile()
global intro.check_profile = function check_profile at 0x2f88488
138
139 client = gconf.client_get_default()
/home/mokurai/dev/jhbuild/sugar-jhbuild/install/lib/python2.5/site-packages/jarabe/intro/__init__.pyc
in check_profile()
18 path = os.path.join(env.get_profile_path(), 'config')
19 if os.path.exists(path):
--- 20 profile.convert_profile()
21
22 if not profile.is_valid():
/home/mokurai/dev/jhbuild/sugar-jhbuild/install/lib/python2.5/site-packages/sugar/profile.pyc
in convert_profile(self=sugar.profile.Profile object at 0x2f8cad0)
133 # decode nickname from ascii-safe chars to unicode
134 nick = name.decode(utf-8)
-- 135 client.set_string(/desktop/sugar/user/nick, nick)
136 if cp.has_option('Buddy', 'Color'):
137 color = cp.get('Buddy', 'Color')
GError: Failed to contact configuration server; some possible causes
are that you need to enable TCP/IP networking for ORBit, or you have
stale NFS locks due to a system crash. See
http://www.gnome.org/projects/gconf/ for information. (Details - 1:
Could not send message to gconf daemon: Method GetIOR with signature
on interface org.gnome.GConf doesn't exist
)
1237919620.178716 DEBUG root: _cleanup_temp_files
CU Sascha
--
http://sascha.silbe.org/
http://www.infra-silbe.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iQEcBAEBAgAGBQJJyTleAAoJELpz82VMF3DayqIIAIfYEkwIFpWL/xzbvuBBvfPh
gbd3eKbwepp1VJf0J/3Lu6sA+aD35JME52Jf3VAIPjgtKNb42gA+Gk971+k5AF9O
tObVeu4TtU+PdLEv5yQRcstQ+S0AYmiTUantQbKFWCdHd9DpEChpUKXRcfXeyTWU
72nBbGFlb5oJfVMBFHPaW4Nw+scPsuJs8TAy4Q7CfSYC4aOLRiA7X4GmL0Wo30Ol
uSsrJeXwKWDhsvij0HdGSzPJz/oBibVW6yTA4bPxAVFO82AED+09aSzRh3u8EQCA
lAaq8/DWzIQjCU2HQNO7mcFP2BNOgsod4UKD/xSXi0L58ooK2Nm9tn1NP3J2wzg=
=dzWU
-END PGP SIGNATURE-
--
Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name
And Children are my nation.
The Cosmos is my dwelling place, The Truth my destination.
http://earthtreasury.net/ (Edward Mokurai Cherlin)
___
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] SWF Sugar
I know very little about AJAX, and less about Flash. But I was under the impression that Actionscript was somewhat compatible with Javascript, especially if you're talking about non-UI aspects such as file and disk access. Would this not mean that much of the effort to create datastore and collaboration hooks would be reusable between AJAX and SWF? Ignorantly y'rs, Jameson ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GSoC idea: Chart/graph-making activity
On Mon, Mar 23, 2009 at 8:44 AM, Garrison Benson benson.garri...@gmail.comwrote: Jameson Quinn wrote: Implementing a whole spreadsheet is a big enough chore. We do really care about collaboration, but I would advise you to limit your ambitions to something achievable, so worrying too much about collaboration right now is not vital. I don't plan to create a spreadsheet, just a graph/chart tool. Obviously a full-featured spreadsheet (with functions, formulas, etc.) would be great for Sugar, but I think a simple, user-friendly charting activity would be much more feasible and more likely to actually be used in a primary school/middle school environment. (Full spreadsheet applications are pretty daunting to learn.) I was just throwing out the idea of a spreadsheet-style interface as the most obvious (but not necessarily best) type of interface for this kind of program. OK, understood. I think that you're right, a spreadsheet-style interface is best - when you're doing charts by hand, you start with data tables. Still, I recommend that you plan your main deliverable as something that is polished but without collaboration, and keep collaboration as something that you'll work on if you have the time. Collaboration is actually harder to get right than formulas, IMO. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Labs
I think that for a GSoC project, we care less about development kits/IDEs like aptana, than about desktop-apps-with-AJAX solutions like Appcelerator Titanium, Mozilla Prism (and in closed-source world, Adobe AIR and Curl). I think it would be a great project to take Titanium or Prism and make a generic sugar-like hello-world which used Javascript to save to the journal, set some tags, open a file, coexist with Rainbow, and have a sugary toolbar. Whether you worked on that activity with Aptana or whatever is a separate issue. Disclaimer: I know nothing under the hood about any of the products mentioned here, so I could be totally wrong. Jameson On Wed, Mar 18, 2009 at 4:14 AM, Bryan Berry br...@olenepal.org wrote: They don't compare currently but they are developing rapidly, particularly aptana http://www.aptana.com. The great thing about aptana is that there is for-profit company behind it that seems to do a good job of sponsoring open-source development. Also, Apple, Palm, and maybe Android are pushing for js+html5 for all apps place of flash. On Wed, 2009-03-18 at 10:47 +0100, Tomeu Vizoso wrote: 2009/3/18 Bryan Berry bryan.be...@gmail.com: Felipe, never bet against the browser is absolutely true However, gnash is roughly 2-3 developer years behind macromedia flash. the big hurdle is adding support for ActionScript3 to Gnash. I don't think that better integrating Gnash into Sugar would be the best use of your time. The better bet is to integrate activities created with javascript + html5 into Sugar. I earlier advocated a framework called Karma for integrating flash swfs into Sugar. I now believe that javascript + html5 is a much better bet because it better adheres to our common belief in open-source and allows View Source. Also, there are far more javascript developers out there than flash developers. This new rework of Karma could take advantage of projects like jquery-UI and new javascript animation libraries like processing.js and GX. That looks very interesting, but what about authoring tools for javascript+html5? Are any that compare to the flash authoring tools? Regards, Tomeu You could start out by trying to recreate some of OLE Nepal's existing flash activities as javascript + html5. You can find some here: http://www.pustakalaya.org/external-content/static/epaath/E-Paath-2.activity/activity/Activity/MenuStage.html If you are interested in such a project, I am definitely be interested in mentoring you. I have to warn you though that I am professionally a project manager and not a software engineer. In fact my software development skills are extremely limited beyond writing broken python scripts. -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org On Tue, 2009-03-17 at 15:37 -0600, Jameson Quinn wrote: Flash is still not open source, and that creates issues when distributing it (Adobe does not let you include it pre-installed in images for download). Bryan Berry from OLE Nepal (cc:ed on this mail) has some good ideas about how that idea should work, though he's not signed up as a mentor. You should think about your design, and then discuss it with him AND on the sugar-devel mailing list. Jameson 2009/3/17 Felipe López Toledo zer.subz...@gmail.com Thanks. I'm interested: SWF Sugar * Integrate SWF (Flash/Gnash) applications into Sugar. * Ideally, develop a demo activity which could be used as a template for sugarizing Flash/Gnash activities. * Priority for Sugar: Very High (never bet against the browser) * Difficulty (as a GSoC project): hard * Skills needed: SWF/Python integration why Gnash?, there is already a stable version of adobe player for linux. really have very good ideas. Interesting! Greetings. On Sun, Mar 15, 2009 at 4:09 PM, Jameson Quinn jameson.qu...@gmail.com wrote: http://sugarlabs.org/go/DevelopmentTeam/ProjectIdeas Good hunting :) Jameson On Sun, Mar 15, 2009 at 12:18 PM, Felipe López Toledo zer.subz...@gmail.com wrote: Hi. I'm Felipe López Toledo, a university student I read your message ( http://groups.google.com/group/google-summer-of-code-discuss/browse_thread/thread/0cf911eb31087cd7?hl=en ) I visited
Re: [Sugar-devel] idea for gsoc 2009
Hey Divya, I guess your email fell through the cracks. Sorry about that. We would welcome you to apply for GSoC this year, assuming we get in. We'll know about that in about 4 hours. Meanwhile, you can look at our ideas list: http://wiki.sugarlabs.org/go/DevelopmentTeam/ProjectIdeas Good luck, Jameson 2009/3/1 Divya divya...@gmail.com Hello I am into python development for last two and half years and looking forward to participate in gsoc 2009. I successfully participated in gsoc 2008 under GNU Project developed gnome-gnowserhttp://code.google.com/soc/2008/gnu/appinfo.html?csaid=F834885142E69883. I used PyGTK pydot for the development of gnome-gnowser and currently I am in the process of porting my application i.e gnome-gnowser onto OLPC. Finding that I posses all the required skill sets to be sugar developer, I look forward to it. So can anyone guide on that as where to start from and if there is already any Ideas list of sugar-labs for gsoc 2009. http://code.google.com/soc/2008/gnu/appinfo.html?csaid=F834885142E69883 -- Regards Divya ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] graphical scaling decision?
Currently, there are only two graphical scales for Sugar: 72 (smaller elements) and 100 (larger elements). I guess that there is still enough bitmaps or hand-tuning that you can't just scale your whole gtk theme with impunity. The choice between these scales is made with $SUGAR_SCALING , which is set by the startup script (bin/sugar or bin/sugar-soas). How should we decide? There are three (well, 4) relevant variables: dpi (technically, v and h are separate, but these are typically close), screen width in cm, screen height in cm. The combination of these gives screen width in pixels, screen height in pixels. The possibilities of [pixels, correct $SUGAR_SCALING] as I see them are in the table below: min(width in cm/4,height in cm/3): low high dpi low [few,72] [normal,100] high [normal,100] [many,100] in other words, we should choose 72 when there are few pixels. I've submitted a patch to do this (when hres900 or vres 700) to http://dev.sugarlabs.org/ticket/39. The patch covers sugar, but not sugar-soas, which uses a dpi cutoff. Please discuss. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] idea for GSoC project
I'm going to link this thread from the ideas page, so I wanted to copy from the other thread: On Wed, Mar 18, 2009 at 4:14 AM, Bryan Berry br...@olenepal.org wrote: [Javascript+html5 dev tools] don't compare [with Flash] currently but they are developing rapidly, particularly aptana http://www.aptana.com. The great thing about aptana is that there is for-profit company behind it that seems to do a good job of sponsoring open-source development. Also, Apple, Palm, and maybe Android are pushing for js+html5 for all apps place of flash. On Wed, Mar 18, 2009 Jameson Quinn jameson.qu...@gmail.com wrote: I think that for a GSoC project, we care less about development kits/IDEs like aptana, than about desktop-apps-with-AJAX solutions like Appcelerator Titanium, Mozilla Prism (and in closed-source world, Adobe AIR and Curl). I think it would be a great project to take Titanium or Prism and make a generic sugar-like hello-world which used Javascript to save to the journal, set some tags, open a file, coexist with Rainbow, and have a sugary toolbar. Whether you worked on that activity with Aptana or whatever is a separate issue. Disclaimer: I know nothing under the hood about any of the products mentioned here, so I could be totally wrong. Jameson ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Sugar Labs in GSoC (Fwd: Congratulations!)
Sugar Labs has been accepted into Google Summer of Code 2009http://socghop.appspot.com/org/show/google/gsoc2009/sugarlabs. Yay! Now we have work to do. Remember: the more students apply to our program, the better our chances of getting more actual slots assigned, so both publicity and making a good impression count. Go ahead, blog it, tweet it, tell your friends. -We can expect most of those students to check out at least the pages linked to directly by our organization profilehttp://socghop.appspot.com/org/show/google/gsoc2009/sugarlabs. That is: http://sugarlabs.org/ , http://wiki.sugarlabs.org/go/Summer_of_Code/Student_application_template , and http://wiki.sugarlabs.org/go/DevelopmentTeam/ProjectIdeas . Go look at those pages, pretending you're a GSoC student who's never heard of Sugar Labs. Do they answer your questions? -We need to be ready to answer student questions on IRC, sugar-devel, and iaep. -If you would like to be a mentor, we can still add mentors. Please sign up. -If you are already signed up as a mentor, please set up your profile on http://socghop.appspot.com/ and then privately email your link_id to walter bender, mel chua, and(or) me. -Random answers: right now we have 11 mentors signed up; OLPC did not get in :( ; new organizations are usually limited to 2 slots but it is all discretionary by LH and other GSoC admins, and she is very reasonable, so I suspect we may inherit OLPC's history; otherwise, slots are generally proportional to student applications (more FAQ on slot allocationshttp://socghop.appspot.com/document/show/program/google/gsoc2009/studentallocations); list of accepted orgshttp://socghop.appspot.com/program/accepted_orgs/google/gsoc2009; timelinehttp://socghop.appspot.com/document/show/program/google/gsoc2009/timeline: student applications from March 23 through April 3, then we madly decide, then acceptances are announced April 15th. Hooray! Jameson -- Forwarded message -- From: socghop.nore...@gmail.com Date: Wed, Mar 18, 2009 at 11:48 AM Subject: Congratulations! To: jameson.qu...@gmail.com Hi Jameson Quinn, Your Sugar Labs (a member of the Software Freedom Conservancy) organization application for Google Summer of Code 2009 has been accepted. ... For full instructions on how to create a home page and best practices for creating it, please see our User's Guide at http://socghop.appspot.com/document/show/program/google/gsoc2009/userguide It is worth taking a look at the in-depth documentation for tips even if you are familiar with the program or a past participant. You will now also be able to review and accept mentor applications for your organization. Congratulations! We look forward to having you with us for Google Summer of Code 2009. Best regards, Google Open Source Programs ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Priorities and Ideas (for GSoC)
It's true that most new organizations are capped at two slots, and that there are 20% fewer slots overall this year than last. On the other hand, we are not most new organizations, and generally number of slots is proportional to number of applicants. If everybody on this list helps get people to apply in Sugarlabs, we will have plenty of applications, and can (tentatively) hope to get more than two slots. I think that sugar has a kind of altruistic appeal, and a variety of tasks, that many projects lack. All we have to do is make sure people don't just think oh, OLPC, didn't they switch to Windows? The bottom line is that we will be getting at most two students from GSoC this year. (We have 5-1 ratio of mentors to mentees.) So I would propose that we think of your taxonomy and what ever framework we put into place as something to apply more broadly across all the sources of students coming to Sugar Labs with project ideas. -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] Google summer of Code?
On Fri, Mar 13, 2009 at 1:56 AM, Mel Chua m...@melchua.com wrote: 2009/3/8 Jameson Quinn jameson.qu...@gmail.com: No definite agreement has been made, but in preliminary chats, it seems that both organizations agree that anything for XS or specific to XO hardware should go in OLPC, and everything else (general Sugar improvements, frameworks, or activities) should go in Sugarlabs. We discussed this at XO camp, and people from Sugar Labs were considering not supporting activity development and focusing on core sugar development. This is correct. Has this changed? In general, do you expect that priorities for toolchain and activity development will be the same? In general, sugar-core and toolchain development is a higher priority than generative Activity development (Activities that lower the barrier to Activity development). It's highly unlikely that non-generative Activity development will be supported. Honestly, this is news to me. (and I am the co-administrator of the Sugarlabs program). If I had to articulate my view of our priorities, it would be something like the following: 7-10 points: Key sugar core improvements. Long-standing, important gaps like versioning or unit-tests at the high end of this. 6-9 points: Activity frameworks to open new forms of activity development (in descending priority: javascript/AJAX, swf, improved PyGTK tools such as Develop activity, mono or java) 4-8 points: Core activities: For instance, Nepal has expressed the need for an improved Read. 3-6 points: Quality non-core educational activities: a physics sim or other creative idea. 0-8 points: Proposal quality. In other words, an excellent proposal from a highly-qualified student could very well make the cut, even if it were a non-core activity. Jameson (whose daughter likes colors) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Google summer of Code?
On Fri, Mar 13, 2009 at 7:24 AM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jameson Quinn wrote: Honestly, this is news to me. (and I am the co-administrator of the Sugarlabs program). If I had to articulate my view of our priorities, it would be something like the following: 7-10 points: Key sugar core improvements. Long-standing, important gaps like versioning or unit-tests at the high end of this. As others have pointed out many times, the SoC projects that are least likely to produce useful results are the ones that are the most ambitious. In particular, it is difficult to find SoC applicants who are ready to make deep modifications to an existing codebase, or will be able to architect complex software. Remember, SoC applicants are mostly current undergrads, so most have never participated in multi-person development effort, or written anything larger than 1000 lines. Agreed. However, I think that a relatively-skilled GSoC student could take on one of the tasks I mentioned. Versioning could build on CScott's OLPCFS2, which AFAIK works remarkably well; it really only needs an interface and maybe a converter. Unit tests require a harness (and Sugarbot already exists) and a couple of demo self-tests of the harness; the tests themselves would be a separate story. Yet it is true, both of these would still be ambitious, and would probably be scored down because of it. 0-8 points: Proposal quality. Maybe this problem is wrapped up in Proposal quality. If I were designing a system to reflect my own internal judgment structure, I would probably add another /multiplying/ factor, the estimated probability of success (although I hope we can do selection without resorting to numerical scores.) I agree. The numbers are only a way of communicating, not a proposed system for choosing. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Priorities and Ideas (for GSoC)
My fourth priority is other educational activities. There are hundredshttp://wiki.laptop.org/go/Category:Software_ideas of http://wiki.laptop.org/go/Educational_activity_ideas goodhttp://wiki.laptop.org/go/Category:GSoC_proposals ideas http://sugarlabs.org/go/ActivityTeam/ProjectIdeas out there. Just to clarify: this is not to denigrate activities. In the end, Sugar will stand or fall on its activities. But my attitude here is if you build it, they will come; we have to take care of the other priorities, so that people are motivated to make/bring more activities. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] GSoC application about to be sent in: last call for checks
Just to add to what Mel said: a good application also means a good ideas page http://sugarlabs.org/go/DevelopmentTeam/ProjectIdeas. Jameson On Wed, Mar 11, 2009 at 3:44 PM, Mel Chua m...@melchua.com wrote: We're going to be submitting our organization's GSoC application in ~24 hours, so this is a last call for edits and sanity checks. Many thanks to Jameson and Walter for their constant reminders and for writing and editing our org app! http://sugarlabs.org/go/Summer_of_Code/SL_application --Mel ___ 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
[Sugar-devel] Sugar GSoC meeting- wed 17:00 UTC/12:00 EST
Mentoring organization applications for GSoC are due Mar 9-13, so Sugarlabs have got to get our $#!* together. We need more than 4 mentorshttp://sugarlabs.org/go/Summer_of_Code/Mentors, a better list of project ideashttp://sugarlabs.org/go/DevelopmentTeam/ProjectIdeas, ideas for how to bring people into the community in a lasting way, and general process details. Let's have a quick meeting this Wednesday in #sugar-meeting at 17:00 UTC/ 12:00 EST. All are invited. This stuff is fun - who among us doesn't have a list of projects we'd love to do if we had the time? You do not have to be a hotshot coder to be a mentor, either; you just have to know how to [help people] get unstuck. Jameson ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] GSoC mentors. Also ideas for projects and community-cementing processes.
We now have about 3 weeks (until March 13th) to get together a Sugarlabs application to be a mentoring organization for Google Summer of Code. As the FAQhttp://code.google.com/opensource/gsoc/2009/faqs.html#0_1_org_app_08250740394219425_says, the application consists of the following parts (emphasis mine, the rest is mostly filler): In addition to anything else your organization would like to submit as an application, Google will be asking (at least) the following questions as part of the application process: 1. Describe your organization. 2. Why is your organization applying to participate in GSoC 2009? What do you hope to gain by participating? 3. Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation. 4. If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)? 5. What license(s) does your project use? 6. What is the URL for your* ideas page*? 7. What is the main development mailing list or forum for your organization? 8. What is the main IRC channel for your organization? 9. Does your organization have an *application template* you would like to see students use? If so, please provide it now. 10. Who will be your backup organization administrator? Please include Google Account information. 11. *Who will your mentors be?* Please include Google Account information. 12. *What criteria did you use to select these individuals as mentors?*Please be as specific as possible. 13. *What is your plan for dealing with disappearing students?* 14. *What is your plan for dealing with disappearing mentors?* 15. *What steps will you take to encourage students to interact with your project's community before, during and after the program?* 16. *What will you do to ensure that your accepted students stick with the project after GSoC concludes? * As you can see, much of the quality of the application hinges on the quality of the ideas page and mentors list; the rest is primarily quality of community-building and follow-up. I propose that we require two mentors per project, but allow especially committed people to act as double-mentors (preferably across two projects). Main mentoring responsibilities should be clearly split up beforehand between co-mentors (ie, alternating weeks), but both should keep read up with all communication and be ready to cover for each other (or just add extra advice) should the need become clear. A single mentoring commitment should expect to be able to handle an average of at least several hours per week of GSoC-related work; let's say, 4 hours/week minimum available time. So, our most important need right now is for quality mentors. If you (or someone you know) would make a good mentor, please nominate yourself (or them), both here on the ML and on the wikihttp://sugarlabs.org/go/Summer_of_Code/Mentors(if you can't handle a little redundant paperwork, you're probably not a good candidate :). Include relevant information such as: Name/contact Timezone What kind of projects could/would you mentor? How much time could you devote to mentoring? Can you make the especially solid commitment of being a double-mentor? What are your other commitments over the summer? What relevant coding experience do you have (very briefly, two sentences at most)? What relevant mentoring (or related) experience do you have? Anything else you think is relevant. ...Aside from mentoring applications, our needs are for [more detail in the] project ideas http://sugarlabs.org/go/DevelopmentTeam/ProjectIdeas and community-building ideas http://sugarlabs.org/go/Summer_of_Code#Community-building_ideas(questions 1516 above). For those, or for discussion of how mentoring can work, you can just reply in this thread, we'll put it on the wiki when discussion winds down. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugarlabs and GSOC
Assuming you are accepted as a mentoring organization, your number of student slots would be based on overall popularity as with all other organizations. There's full documentation available here that may be helpful to you: http://groups.google.com/group/google-summer-of-code-announce/web/notes-on-student-allocations Just to let you know, this link is broken right now. And the same link on http://groups.google.com/group/google-summer-of-code-announce/web is, of course, also broken. Thanks, Jameson ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
