Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.

[Jameson Quinn]

2010/6/9 Luke Faraone 

> -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

[Jameson Quinn]

> >> 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

[Jameson Quinn]

2009/6/4 Sascha Silbe 

> 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

[Jameson Quinn]

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 

> Anyone wants to take it over?
>
>  Original Message 
> Subject:Re: Reviving Sugarbot
> Date:   Wed, 20 May 2009 15:58:40 -0400
> From:   Zach Riggle 
> To: Bernie Innocenti 
> CC: Titus Brown 
>
>
>
> 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

[Jameson Quinn]

>
> 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] [PATCH] add clock to frame

[Jameson Quinn]

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 

> 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

[Jameson Quinn]

+2 to having a clock
+0 to being able to place it in any of the 8 corners of the frame by a
one-line code change
-1 to those two pieces of code being in the same patch

In other words, IMO this should be two patches: a clock device icon; and the
ability to put device icons in lower left, lower right, or upper right.

now-I-can-go-back-to-building-my-own-bikeshed-ly y'rs,
Jameson

2009/5/2 

> martin wrote:
>  > On Sat, May 02, 2009 at 10:28:06AM +0200, Tomeu Vizoso wrote:
>  > > Hi Martin,
>  > >
>  > > I was hoping the frame clock could be implemented as a device icon
>  > > extension, so people could add it, remove it and customize it more
>  > > easily. Why is it inside the shell instead?
>  >
>  > The code (clock.py) is in fact a device icon, and if you drop it in
>  > /usr/share/sugar/extensions/deviceicon it'll Just Work.
>  >
>  > It's in the shell because it's in the upper-right corner of the frame,
>  > where I found it looks a lot better:
>  >
>  > http://www.xades.com/proj/clock_frame_767_screenshot.png
>
> sounds like there is, but to be sure:  it's easy for people to
> remove or disable if they don't like having a stopped clock on
> their screen during idle suspend on an XO?
>
> 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] Keyboard shortcuts

[Jameson Quinn]

Martin:

> 1. What I think we're talking about:


You're right. While I actually think that, with a cheatsheet, alt-f is
slightly *more* discoverable (though less convenient/accessible) than F9,
your point is good. Let's stop fighting for now and see what others say.




I do have a question about implementation, though:

 I can use a custom gtk signal from the top level window to send
"show-shortcuts" and "hide-shortcuts" signals. But I don't know if this is
the right design. Is there a way to register a custom signal for all
top-level windows, even non-pygdk ones? Is there a way for non-pygdk ones to
ever hear it?
[13:13]  Or do I have to take a detour through DBUS and then back to
gdk? (it would just be a detour I think; I'd still alert individual controls
through the same signalling mechanism)
[13:15] * homunq would welcome even non-expert opinions on this question,
because I have little idea.



Jameson
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Keyboard shortcuts

[Jameson Quinn]

> Sorry, seemed to have missed a conversation here, what's with idea that
>  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  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

Re: [Sugar-devel] Keyboard shortcuts

[Jameson Quinn]

>
> I don't see how the  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

[Jameson Quinn]

2009/5/1 Martin Dengler 

> 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)
>
> > [fjrsvp] = deprecated, but kept for emulator users on
> > MacOS.
>
> I'd say just "emulator users".
>
> > [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 [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 [...].  Why deprecate the existing
> combinations in favor of combinations that are more likely to clash
> with existing applications?


Because the  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  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

[Jameson Quinn]

Eben, I'd like your comments on the discoverable/floaty-letters idea too.

2009/5/1 Eben Eliason 
>
>
> > 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
> >>> #'f': 'frame', #removed
> >>> #'o': 'open_search', #removed
> >>> #'r': '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)
[fjrsvp] = deprecated, but kept for emulator users on MacOS.
[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

[Jameson Quinn]

(note: I suggest below that we use caps-lock as the frame key)

2009/4/30 Gary C Martin 

> 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.



>
>
> 'Escape': '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 N>5 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
>> #'f': 'frame', #removed
>> #'o': 'open_search', #removed
>> #'r': '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

[Jameson Quinn]

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: F1 would not
be F1 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] Keyboard shortcuts

[Jameson Quinn]

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 
Date: 2009/4/30
Subject: Keyboard shortcuts
To: sugar-devel 


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 =
_('b')) 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',
'F9'  : 'brightness_min',
'F10' : 'brightness_max',
'XF86AudioMute': 'volume_mute',
'F11'  : 'volume_down',
'XF86AudioLowerVolume' : 'volume_down',
'F12'  : 'volume_up',
'XF86AudioRaiseVolume' : 'volume_up',
'F11' : 'volume_min',
'F12' : 'volume_max',
'0x93' : 'frame',
*'Insert'   : 'frame', #for SoaS
'0x00' : 'frame', #for SoaS on Xephyr, see below.*
'0xEB'

[Sugar-devel] Keyboard shortcuts

[Jameson Quinn]

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 =
_('b')) 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',
'F9'  : 'brightness_min',
'F10' : 'brightness_max',
'XF86AudioMute': 'volume_mute',
'F11'  : 'volume_down',
'XF86AudioLowerVolume' : 'volume_down',
'F12'  : 'volume_up',
'XF86AudioRaiseVolume' : 'volume_up',
'F11' : 'volume_min',
'F12' : 'volume_max',
'0x93' : 'frame',
'Insert'
'0xEB' : 'rotate',
'Tab' : 'next_window',
'Tab'  : 'previous_window',
'Escape'  : 'close_window',
'0xDC' : 'open_search',
# the following are intended for emulator users
'f': 'frame',
'q': 'quit_emulator',
'XF86Search'   : 'open_search',
'o': 'open_search',
'r': 'rotate',
's': 'say_text',

-SOAS
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Kartik - internship outside GSoC

[Jameson Quinn]

>
>
> 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 
> 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 
> >>
> >> 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 
> >> 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

[Sugar-devel] Kartik - internship outside GSoC

[Jameson Quinn]

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
   Salut for the IP address associated with a given contact, etc Maybe it
   could get its own Telepathy connection manager, but now this is really
   getting out of control." In other words, you'd have to have some serious
   conversations with him to redesign how this would work.
   - One part of the original sugar design that has never been realized is
   the ability to share in activities without previously installing them on
   your machine. That would mean that whenever you joined a shared activity,
   your copy of sugar would automatically download, install, and run a copy of
   the host's version of the activity. It would require having a way to hash
   activities; the ability to have more than one version of the same activity
   simultaneously installed and running; some policy for garbage collecting old
   installed activity versions; and teaching Sugar to appropriately use the
   existing file transfer mechanisms in telepathy. I suspect that this project
   would be more under your own control than your original proposal, and I
   think that the time is ripe for Sugar to grow this functionality.


As to the paperwork for your internship requirements at your school, Walter
Bender (also copied on this mail) has said he could probably help you with
that. Talk to him.

Hope this helps, and good luck!
Jameson

On Wed, Apr 22, 2009 at 11:46 AM, kartik rustagi wrote:

> Hi Jameson,
>
> Sorry for the late reply, I was out of station. First of all thanks a
> lot for showing this gesture towards me, it really meant a lot. It
> would have been had I got through Gsoc but none the less my  passion
> towards contributing to Sugar and open source in general still
> remains. Yes resume building was one of the reason for me to apply for
> Gsoc, but along with that it would have served as an internship that
> we must do in the coming months of June and July. I will have to talk
> to college authority whether working for Sugar will do the job or not.
> In the mean time can you please let me know the projects that have
> recently started or are yet to start and where I can fit in.
>
> --
> Regards
> Kartik Rustagi
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Print Support (journal vs activity)

[Jameson Quinn]

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 
here.
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]  homunq: have some problems following your last email about
printing
[11:09]  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]  tomeu: there would be some metadata besides mime-type,
something like "sub-type"
[11:12]  all pdfs created for printing would have a specific
sup-type. This would make them "print-me" pdfs.
[11:12]  ok, what would that metadata be? which component would use
that new property?
[11:13]  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]  does that make sense?
[11:14]  why do activities other than Read need to open those pdfs?
[11:14]  so both "print" and "read" would handle pdfs.
[11:15]  "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]  eben, we hardly knew ye.
[11:16]  is that clear? And should I make the same clarifications on
ML?
[11:16]  homunq: why do we need an activity with no UI?
[11:17]  homunq: enqueue should be pretty easy to do in the journal
by using gtkprint
[11:17]  um, because that's the work flow?
[11:17]  just like we don't have an activity for copying files from a
usb stick to the journal
[11:17]  homunq: which workflow?
[11:17]  I mean, there would be several versions/updates of the
activity possible.
[11:18]  by sending a file to the print queue is quite trivial in
pygtk
[11:18]  the no-UI version is just alpha, for GSoC.
[11:18]  s/by/but
[11:18]  what print queue?
[11:18]  and about the preview UI, why not just use Read?
[11:18]  the moodle queue on the XS?
[11:18]  homunq: cups, lpr, whatever
[11:18]  the moodle queue, I think it's enough with file uploading in
browse for now
[11:19]  that gives us authentication and is already done
[11:19]  OK, so "print" activity is a spin of browse.
[11:19]  printing from the journal means for me to just submit a file
to the local printing queue
[11:19]  the local printing queue is meaningless.
[11:20]  homunq: well, it's the same thing you have in windows when
you send documents to print
[11:20]  in most cases won't make sense, but it's stuff that it's
already done
[11:20]  yes but the moodle queue is the whole point of this GSoC
[11:20]  and will be important for a teacher printing from sugar to
an attached printer, for example
[11:21]  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]  but we don't want to give every kid UI that only the
teacher will use. Much confusion results.
[11:21]  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]  homunq: sugar will be used out from classrooms
[11:22]  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]  homunq: but I would prefer if the gsoc project focused on
moodle
[11:22]  don't worry about this now
[11:22]  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]  print to pdf is from inside journal, to journal.
[11:24]  not sure I understand the importance of that print-me tag
[11:25] *** nubae1 is now known as Nubae.
[11:25]  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]  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]  me neither...
[11:25]  homunq: I dont think we'll use browse to upload
[11:26]  aa: neither did I but tomeu just convinced me.
[11:26]  now I'm confused again.
[11:26]  what I like about uploading the file with browse to moodle
is: it alre

Re: [Sugar-devel] Print Support (journal vs activity)

[Jameson Quinn]

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 wrote:

> 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)

[Jameson Quinn]

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)

[Jameson Quinn]

My point of view is that, ideally, printing should be from the journal (or
even from a separate "print" activity), for both security and UI reasons.
The UI reason is that conceptually separating "edit document" and "preview /
print document" is a workflow that will likely save resources.

So the workflow I'd propose is the following. In grey are items that I'd
consider optional for this GSoC, in yellow are ones that I'd consider
clearly outside the scope of this GSoC.

"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.
the PDF thus created would have special "print-me" metadata
in other words, sugar would use metadata to choose which of several
activities which handle a mime-type to use as default
"send to print queue" option for pdfs
default action from journal for "print-me" pdfs
provided by an activity which handles only pdf mime type
in GSoC time-frame, this could be an activity with NO UI, just send to queue
and terminate
later, this activity could first show a preview and allow send-to-queue as
an option
there could be an alternate version of this activity which actually printed
directly, over USB or wirelessly
Obviously, these pdfs could also be viewed using "open with"-"Read".
All queue management besides enqueue would be done through browse/moodle
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 "print-me" pdfs.
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] [Gsoc] Congratulations to the accepted Gsoc applications.

[Jameson Quinn]

On Mon, Apr 20, 2009 at 5:48 PM, Rafael Enrique Ortiz Guerrero <
dir...@gmail.com> wrote:

> Student Title Mentor Status
> Lucian Branescu 
> Mihaila<http://socghop.appspot.com/student_project/show/google/gsoc2009/sugarlabs/t124025001233>
> Webified
> walter bender
> accepted
>
> Sascha 
> Silbe<http://socghop.appspot.com/student_project/show/google/gsoc2009/sugarlabs/t124025001821>
> Version support for Sugar data store / Journal
> Jameson Quinn
> accepted
>
> felipe lopez 
> toledo<http://socghop.appspot.com/student_project/show/google/gsoc2009/sugarlabs/t124025002631>
> Karma + Activities
> bryan berry
> accepted
>
> vamsi krishna 
> davuluri<http://socghop.appspot.com/student_project/show/google/gsoc2009/sugarlabs/t124025003408>
> Adding Print Support to the XOs
> andres ambrois
> accepted
>
> Benjamin 
> Schwartz<http://socghop.appspot.com/student_project/show/google/gsoc2009/sugarlabs/t124025004103>
> Decentralized Asynchronous Collision-free Editing with Groupthink
> assim deodia
> accepted
>
>
> These were some of the best applications both for Sugar and SugarLabs
> community development
>
>
>
> Rafael Ortiz
>

These were, indeed, justly accepted. But I have to take a minute to thank
the applicants who were not accepted. There were at least 5 or 6 unaccepted
applications which showed serious dedication, creativity, and practicality.
The competition to get into GSoC is always very tough, and this year was no
exception. I have reason to hope that a few of the better applicants are
still interested in contributing to Sugar Labs, and I hope to see them
participating through the year, and then winning slots next year. (And since
I'm pretty darn sure we can do a great job with the applicants who were
accepted, I hope that Google will reward us with more slots next year).

Thanks, all the applicants, and thank you to Google as well. This is a great
program from all sides, and it's humbling to be a part of it.

Jameson
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Screenshot attached. Very rudimentary and will change with introduction of activity widgets

[Jameson Quinn]

Thanks, I'm forwarding this to sugar-devel.

To respond: This gives me an idea of the student view. What about the
teacher view? Can the teacher view multiple responses, or a random response,
in real time? Is there some way to let (some) students see each other's
answers, to promote discussion? This kind of feature would be the real
value-add for me. Of course, on the other hand, you want to keep your plan
for GSoC as simple as possible. Seeing a table-napkin-level prototype UI for
this would help us understand how you'd resolve this tension.

Jameson

On Wed, Apr 15, 2009 at 12:05 PM, Deepank Gupta wrote:

>
> http://deepank.blogspot.com
>
<>___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] A bot activity for sugar

[Jameson Quinn]

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

[Sugar-devel] GSoC mentors: we have work to do

[Jameson Quinn]

All GSoC mentors, please subscribe to the "Google Summer of Code @ Sugarlabs
list" .

We have a meeting scheduled for 1500 UTC on Tuesday. Please be there if at
all possible. I'm sorry, I cannot be there.

There is also an ongoing
discussionon
melange. You have to be logged in to see it. Please participate.
___
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

[Jameson Quinn]

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 wrote:
>
>> 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 
>>
>> 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  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
>>>>  wrot

Re: [Sugar-devel] Fwd: Proposal of Google Summer of Code

[Jameson Quinn]

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 

> 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  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
>>  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

[Jameson Quinn]

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
this.
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  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

[Jameson Quinn]

>
> 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

[Jameson Quinn]

>
> 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

Re: [Sugar-devel] ideal flash activity to be remade as karma activity

[Jameson Quinn]

> 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

[Jameson Quinn]

Subzero , you have
competition
.

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 

> 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] jhbuild hangs

[Jameson Quinn]

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/Jhbuild&oldid=21330#Dealing_with_dependencies

Jameson

On Tue, Mar 24, 2009 at 5:56 PM, Edward Cherlin  wrote:

> On Tue, Mar 24, 2009 at 12:49 PM, Sascha Silbe
>  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
> ()
>171 print 'Ctrl+C pressed, exiting...'
>172
> --> 173 main()
>global main = 
>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 = 
>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=)
>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

[Sugar-devel] GSoC applications open until April 3 - Please continue to promote Sugarlabs GSoC

[Jameson Quinn]

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 
organizations<http://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
category<http://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
ideas<http://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
category<http://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] GSoC idea: Chart/graph-making activity

[Jameson Quinn]

On Mon, Mar 23, 2009 at 8:44 AM, Garrison Benson
wrote:

>
>
> 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] GSoC idea: Chart/graph-making activity

[Jameson Quinn]

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.

Your job right now is to look under the hood and ask questions about the
three approaches Benjamin Schwarz (bemasc) mentioned, decide which one you'd
prefer to work with, and figure out a plan of work. We'd be happy to answer
questions, but you're going to have to get your hands dirty and use your own
judgement, I think. When you choose your plan of attack, that will help you
get a mentor who shares similar interests.

Cheers,
Jameson

On Mon, Mar 23, 2009 at 8:05 AM, Garrison Benson
wrote:

>
> Would someone be interested in mentoring me in this project?
>
> Also, a thought about collaboration:
> I think it would be quite useful to allow a group of students to share data
> and edit it collaboratively in real time. Students working on an experiment
> in class could each be assigned to collect a portion of the data, then they
> could watch the whole data set be populated piece by piece by their peers.
> (We do this kind of thing all the time in my networking class, where we get
> response times, packet sizes, whatever, and each fill in one row of a table
> using DyKnow.)
> --
> View this message in context:
> http://n2.nabble.com/GSoC-idea%3A-Chart-graph-making-activity-tp2517796p2521249.html
> Sent from the Sugar Development mailing list archive at Nabble.com.
>
> ___
> 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

[Jameson Quinn]

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 project proposal

[Jameson Quinn]

Hi Ishara.

One quick recommendation: you'll probably get more comments if you post your
proposal on the wiki and in email directly, rather than as an included file.
This is especially true when you use semi-proprietary data formats like
microsoft .doc, which many people in the open source community take a dim
view of.

As to your actual proposal, it is interesting in terms of the use cases, but
pretty weak in terms of technical detail. Particularly as you refer to
postgresql, and yet it is not clear where this would be running. Your
diagram seems to indicate that the database exists in copies both on the
teacher's machine and on the school server. Remember, Sugar activities
should try to avoid assuming good connectivity, and should work with very
limited computational resources (processor, disk, and ram). We will consider
proposals relating to the "XS" or school server, which would have slightly
higher resources; but if your idea will ony run on the XS, then how is it
different from Moodle?

Cheers,
Jameson

2009/3/21 Ishara Gunathilake 

> hi,
>
> I'm applicant of GSoC. here I attached my project proposal for a sugar
> project
> idea. please be kind enough to consider those documents and reply.
>
> thanx
>
> ___
> 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] Sugar Labs in GSoC (Fwd: Congratulations!)

[Jameson Quinn]

Sugar Labs has been accepted into Google Summer of Code
2009<http://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
profile<http://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
allocations<http://socghop.appspot.com/document/show/program/google/gsoc2009/studentallocations>);
list of accepted
orgs<http://socghop.appspot.com/program/accepted_orgs/google/gsoc2009>;
timeline<http://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: 
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] idea for GSoC project

[Jameson Quinn]

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  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  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

Re: [Sugar-devel] Sugar Labs

[Jameson Quinn]

Croquet (squeak virtual worlds) or seaside (smalltalk web apps) would be
fine projects, if croquet isn't too 3d-resource-hungry. But IMO they do not
have the same high priority as work on AJAX.

2009/3/18 Frederick Grose 

> How about something in Croquet,
> http://www.opencroquet.org/index.php/Main_Page, or  Seaside,
> http://www.seaside.st/, that would create a Sugar environment for the web,
> say Honeycomb?
>
> I, too, need to spend more time under those hoods or in those
> hoods.      --Fred
>
>
> 2009/3/18 Jameson Quinn 
>
> 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  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 :
>>> > > 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).
>>> > >>

[Sugar-devel] graphical scaling decision?

[Jameson Quinn]

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 hres<900 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 2009

[Jameson Quinn]

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 

> 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-gnowser.
> 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.
>  
> --
> 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

Re: [Sugar-devel] Sugar Labs

[Jameson Quinn]

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  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 :
> > > 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 
> > >> 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
> 

Re: [Sugar-devel] [IAEP] Priorities and Ideas (for GSoC)

[Jameson Quinn]

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] Priorities and Ideas (for GSoC)

[Jameson Quinn]

>
> My fourth priority is other educational activities. There are 
> hundreds
> of  
> good
> ideas  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

[Sugar-devel] Priorities and Ideas (for GSoC)

[Jameson Quinn]

I will link to this thread (in IAEP) on the GSoC project
ideaspage. This
page is the primary location where prospective GSoC students will
come to learn about out project, and so I want them to get a feel for our
community discussion of priorities. So please, in this thread, try to be a
little bit more explicit and foot-noted than you would be otherwise, so they
can understand what we're talking about.

The primary purpose of GSoC, as others have pointed out, is NOT to do the
things we're too busy to get around to. It is primarily a community-building
exercise: to get students engaged in helping Sugar, and get mentors engaged
in passing on knowledge to new community members. If somebody develops an
educational game that only blind 3-year-olds use, but FINISHES it, has a
great time doing it, and becomes a long-term contributing community member,
then that would be a total GSoC success. However, that being said, we'd
still prefer projects that help acheive our highest priorities for Sugar.

There is no absolute ordering of Sugarlabs' priorities. Different members
will not agree perfectly on what steps will do more to help our educational
mission. So the list below is just my version. Community: Please respond
with your thoughts. Students: I'll link what I can in the list, but I can't
find good links, or even any links, for everything. If one of these ideas
intrigues you, please, come ask in IRC (#sugar on freenode) - we'd love to
try to point you in the right direction, and help you cut your ideas down to
a reasonable GSoC size.

My first priority is things that will have a strong effect on the long-term
rate of development of Sugar. I'd put just 2 things in that category: easier
sugarizing (primarily from
AJAX,
Flash , and
legacy Linux); and a structure for sugar unit tests (IMO we will never get
good enough software quality for wide adoption, running on multiple
distribution without automated
testing
).

My second priority is things that will improve on sugar's key promises. An
easier and better way to handle files: versioned
datastore,
improvements in creating and
usingtags for the
journal, file picker dialogs, and home
view . A
simpler and safer security model: getting Rainbow into the Sugar
platformand
improving
it's coverage of the Bitfrost
ideals.
A simple and discoverable, yet powerful, UI overall: improved accessibility,
discoverable keyboard shortcuts. Ubiquitous connectivity and collaboration:
multi-pointer sharing, auto-collaborating data
structures,
viral/peer-to-peer activity
distribution,
shared journals. Useful in the classroom: a one-click workflow for getting
AND turning in 
homework
.

My third priority is activities to better cover the core functions. Reading:
an improved 
Read,
which handles true ebook formats. (PDF is made for printing, and deployments
have asked for this.) Writing: Write is pretty good. Communication: an email
activity. Math: a good spreadsheet/graphing utility (spreadsheets are not
the best back-end for graphs, but they are very very flexible).

My fourth priority is other educational activities. There are
hundreds
of 
good
ideas  out there.

Let me repeat, the best project is the one that gets done. The highest
priorities on my list are also the hardest. An achievable idea for an
educational activity is better than pie in the sky. And if you want to take
on a bigger task, ask us in IRC - we will help guide you.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Google summer of Code?

[Jameson Quinn]

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] Google summer of Code?

[Jameson Quinn]

On Fri, Mar 13, 2009 at 1:56 AM, Mel Chua  wrote:

>
> 2009/3/8 Jameson Quinn :
>> > 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] yet another corrected screenshot image!

[Jameson Quinn]

I agree that we should drop freeform, and choose one, iconic, layout. Then
we could plan for easy searching - using tags, names, or recentness - which
greyed out the unselected apps.

If we did this, my vote would be: ring up to 16 activities, then a single
(non-sunflower) spiral.

On Thu, Mar 12, 2009 at 10:12 AM, Walter Bender wrote:

> I haven't studied it in any scientific way, but I have never seen
> anyone use freeform in the field. I can also make a strong case for
> its inappropriateness in the classroom and the additional support
> overhead. For simplicity-sake, if for no other reason, we should drop
> it.
>
> That said, I cannot argue with your observation that an overloaded
> ring is problematic as well. For 0.86, we should consider some of
> spiral options, such as the sunflower, which are much more space
> efficient. At the same time, I think the real answer lies in better
> use the idea that groups of activities can be selected for the ring: a
> teacher might say to the child, this week, I want everyone to put
> Browse, Write, and Turrtle Art on their desktops. At home, a different
> collection might be available. So maybe we can explore the notion of
> collections rather than layouts?
>
> -walter
>
> On Wed, Mar 11, 2009 at 10:54 PM, Christian Marc Schmidt
>  wrote:
> > I fully understand your confusion, this issue has been going back and
> > forth for too long.
> >
> > We should probably talk this over more thoroughly before deciding
> > either way. Nicholas had (and I'm assuming still has) very strong
> > reservations about the ring, which caused us to reconsider it, but at
> > the time it was too late to change and it made it into the build. As
> > you know I was initially in favor of the ring (which I think has a
> > strong iconic presence), but when I began seeing screenshots of
> > overloaded rings it seemed like the favorites model perhaps wasn't
> > working as well as we had hoped.
> >
> > This is a case where it would really help to do observations and see
> > how children are using the Home view, and which of the two views they
> > prefer using... Or do we have any findings and observations we can
> > already draw from?
> >
> > For now, the question remains which view (freeform/ring) we use to
> > represent Sugar. Or perhaps at least in the interim it would make
> > sense to avoid Home altogether and use the Neighborhood view as the
> > "signature" shot?
> >
> > I agree that we would ideally keep either the ring or freeform, but
> > not both, for simplicity...
> >
> > More discussion ahead, I sense.
> >
> >
> > Christian
> >
> >
> > On Wed, Mar 11, 2009 at 10:31 PM, Walter Bender 
> wrote:
> >> On Wed, Mar 11, 2009 at 10:22 PM, Christian Marc Schmidt
> >>  wrote:
> >>> Hi Sean
> >>>
> >>>
> >>> We are currently debating moving to freeform view as the default
> >>> (maybe even the only) view in Home. To be on the safe side, should we
> >>> use that view here instead, seeing as it already exists in the UI?
> >>> CC'ing Walter for his thoughts as well...
> >>>
> >>
> >> Boy am I ever confused. I thought (and hoped) that we were going to
> >> get rid of the freeform view, not the ring view.
> >>
> >> -walter
> >>
> >> --
> >> Walter Bender
> >> Sugar Labs
> >> http://www.sugarlabs.org
> >>
> >
> >
> >
> > --
> > anyth...@christianmarcschmidt.com
> >
> > http://www.christianmarcschmidt.com
> >
> > 917/ 575 0013
> >
>
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [IAEP] GSoC application about to be sent in: last call for checks

[Jameson Quinn]

Just to add to what Mel said: a good application also means a good ideas
page .

Jameson

On Wed, Mar 11, 2009 at 3:44 PM, Mel Chua  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

[Jameson Quinn]

Mentoring organization applications for GSoC are due Mar 9-13, so Sugarlabs
have got to get our $#!* together. We need more than 4
mentors,
a better list of project
ideas,
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.

[Jameson Quinn]

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
FAQsays,
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
wiki(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 
and community-building
ideas 
(questions
15&16 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

[Jameson Quinn]

>
> 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

[Sugar-devel] Sugarlabs and GSOC

[Jameson Quinn]

Last year, OLPC handled the sugar educational environment in GSOC. This
year, that responsibility could be split. Sugarlabs, a more traditional
open-source government org, handles Sugar; and OLPC only in one platform
version of that, for Fedora on the XO. It is not clear to me what, if any,
interest in GSOC OLPC will have (they are undergoing some serious
belt-tightening right now, so it's not the best time to ask). Some of last
years' OLPC mentors for GSOC are now associated with Sugarlabs instead.

LH, I've been delegated to ask you what implications that has for what range
of numbers of slots Sugarlabs might reasonably expect. It is emphatically
not our intention to take any slots from OLPC which OLPC can legitimately
use, but it is our impression that OLPC might have a lower number of
interesting applicants this year due to the much-smaller code base that is
still strictly "theirs". There are rumors that GSOC puts "new" organizations
at the end of the line for slots, and we hope that some of OLPC's track
record might rub off on us. In fact, we dare hope that, as a less
heierarchical organization than OLPC, we may actually do a better job than
they did with open source community tasks like GSOC.

Sincerely,
Jameson
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Fwd: Google Summer of Code 2009 is a go!

[Jameson Quinn]

Actually she said that not all the same orgs will be returning. Not the same
as saying a smaller number of orgs total. I read it as meaning that there
are ways to fail out, not that they are being any pickier than last year.

On Fri, Jan 9, 2009 at 10:41 AM, Wade Brainerd  wrote:

> I would ask around in #gsoc on FreeNode to see if anyone has heard of
> similar hard limits.
>
> According to LH's post to the soc mailing list 2 days ago, GSoC will
> support a smaller number of organizations this year, so OLPC and SL
> may be lucky to be accepted.
>
> Cheers,
> Wade
>
> On Fri, Jan 9, 2009 at 11:31 AM, Mel Chua  wrote:
> > That depends on what OLPC's GSoC focus is - it may *not* be Sugar at
> > all, in which case the organizational intern allocations should be (and
> > they should be, anyway!) independent of each other.
> >
> > Marcin, do you recall where you heard/saw that rule? Googling for things
> > like "gsoc limit of 2 students" isn't getting me anywhere - I want to
> > have a few moments to read through all the docs and historical paperwork
> > before emailing Leslie (likely tomorrow, as there will be time to catch
> > my breath then).
> >
> > Is anybody here, aside from SJ, a former GSoC coordinator who can chime
> > in / fill in details / help? I am *completely *swamped for the next 24
> > hours wrapping up the "becoming a volunteer again" process.
> >
> > --Mel
> >
> > Jameson Quinn wrote:
> >>
> >>
> >> OTOH the last year there was a rule that new organizations can get
> not
> >> more than two students in GSOC.
> >>
> >> Marcin
> >>
> >>
> >> This is something on which we should get clarification ASAP. To me, it
> >> would be logical for OLPC to have around 2 slots and Sugarlabs to get
> >> OLPC's (presumably larger) allocation. This is not based on any
> >> judgement of the relative importance or capacities of the two
> >> organizations, just on the fact that the majority of projects will
> >> probably be applicable in the broader sugar context.
> >>
> >> Jameson
> > ___
> > 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: Google Summer of Code 2009 is a go!

[Jameson Quinn]

>
> OTOH the last year there was a rule that new organizations can get not
> more than two students in GSOC.
>
> Marcin


This is something on which we should get clarification ASAP. To me, it would
be logical for OLPC to have around 2 slots and Sugarlabs to get OLPC's
(presumably larger) allocation. This is not based on any judgement of the
relative importance or capacities of the two organizations, just on the fact
that the majority of projects will probably be applicable in the broader
sugar context.

Jameson
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] possible additional talks for XOCamp2?

[Jameson Quinn]

Sorry, can I request that at least the nepal notes be rescheduled? I can not
get there until Tuesday, and would like to be there for this talk. Some
talks I would not mind missing as much are Fedora and power issues.

Thanks,
Jameson

On Mon, Jan 5, 2009 at 9:27 AM, Greg Smith  wrote:

> Hi Bryan,
>
> Both sound like very good subjects.
>
> I have you down for two hours Monday afternoon:
> http://wiki.laptop.org/go/XOcamp_2#Monday_January_12.2C_2009
>
> My goal for the first day is to give an overview of the challenges faced
> by deployments and how we hope to address them in release 9.1.0.
> Hopefully your slot Monday can address Nepal's experience and next stage
> plans.
>
> After you on Monday afternoon, is a working meeting to define how we
> ensure the latest Sugar is stable and how we include it in 9.1.0.
>
> Then we cover the technical details of each 9.1 area Tues. and Wed.
>
> Thursday and Friday are more open. John Gilmore is confirmed for
> Thursday afternoon but otherwise those meetings are mostly open and can
> be changed.
>
> Do you want to take Friday AM 10AM - Noon or Thursday afternoon 3PM - 5PM?
>
> Pick a slot and fill it in. Add a section below with more detail and
> link to it from the calendar if you want to give people a chance to see
> the agenda in advance.
>
> I'm not sure how many sugar focused people will be there late in the
> week but I expect you can get all the regulars from OLPC HQ at a minimum.
>
> Thanks,
>
> Greg S
>
> Bryan Berry wrote:
> > I would like to give the following talks at XOCamp2 if there is space in
> > the schedule for them and others are interested. Please let me know if
> > you would be interested
> >
> > 1. Evolution of a deployment organization.
> >
> > About the challenges of building a deployment team from scratch and
> > lesson learned along the way. Not a very technical talk.
> >
> > 2. Karma - Not for Hackers, for Designers
> >
> > Talk about my still evolving ideas for a flash-based activity framework
> > called Karma
> >
> >
> ___
> 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] [PATCH] Allow view-source to launch external activities

[Jameson Quinn]

This patch has been smoke-tested, but I would like another day to test it
properly. Unfortunately, since that day is Wednesday, I am sending a
preliminary version now.

Jameson
From abb44f339fdaf4893f8b37e9a93917fc6bcac87f Mon Sep 17 00:00:00 2001
From: chema <[EMAIL PROTECTED](none)>
Date: Fri, 5 Dec 2008 18:51:49 -0600
Subject: [PATCH] Allow view source to launch external activity to allow editing.

---
 extensions/globalkey/viewsource.py |  161 +---
 src/jarabe/journal/misc.py |   13 +--
 src/jarabe/model/bundleregistry.py |8 ++
 3 files changed, 143 insertions(+), 39 deletions(-)

diff --git a/extensions/globalkey/viewsource.py b/extensions/globalkey/viewsource.py
index 7a6e37d..06c2305 100644
--- a/extensions/globalkey/viewsource.py
+++ b/extensions/globalkey/viewsource.py
@@ -17,6 +17,7 @@
 import os
 import logging
 import traceback
+from tempfile import gettempdir
 from gettext import gettext as _
 
 import gobject
@@ -28,9 +29,18 @@ import dbus
 from sugar.graphics import style
 from sugar.graphics.toolbutton import ToolButton
 from sugar.graphics.radiotoolbutton import RadioToolButton
+from sugar.graphics.menuitem import MenuItem
+from sugar.activity.bundlebuilder import XOPackager, Config, Builder
 from sugar import mime
+from sugar import profile
+from sugar.activity import activityfactory
+from sugar.activity.activity import SCOPE_PRIVATE
+from sugar.datastore import datastore
 
 from jarabe.model import shell
+from jarabe.model import bundleregistry
+
+VERSION_1 = 1
 
 BOUND_KEYS = ['0xEC', 'v']
 
@@ -39,10 +49,62 @@ _SOURCE_FONT = pango.FontDescription('Monospace %d' % style.zoom(6))
 _logger = logging.getLogger('ViewSource')
 map_activity_to_window = {}
 
+ACTIVITY_MIME = "application/vnd.olpc-sugar"
+
+def _bundle_activity(path):
+builder = XOPackager(Builder(Config(path, gettempdir(), None)))
+builder.package()
+
+jobject = datastore.create()
+
+metadata = {
+'title': _('%s Bundle') % builder.config.activity_name,
+'title_set_by_user': '1',
+'suggested_filename': '%s-%d.xo' % (builder.config.bundle_name, 
+builder.config.version),
+'icon-color': profile.get_color().to_string(),
+'mime_type': 'application/vnd.olpc-sugar',
+'activity' : builder.config.bundle_id,
+'share-scope' : SCOPE_PRIVATE,
+'preview' : '',
+'source' : path,
+}
+for k, v in metadata.items():
+jobject.metadata[k] = v # dict.update method is missing =(
+jobject.file_path = builder.package_path
+datastore.write(jobject)
+#jobject.destroy()
+os.remove(builder.package_path)
+return jobject.object_id
+
+class DocumentData():
+"""The data for initialization should be (version,contents).
+
+if version is 1, contents == (mime_type, title, path, human_readable)"""
+def __init__(self, data):
+if len(data) != 2:
+logging.error("Activity returned malformed data on "
+  "current document")
+
+version, contents = data
+if version == VERSION_1:
+if len(data) != 4:
+logging.error("Activity returned misversioned data on "
+  "current document")
+ 
+self.mime_type, self.title, self.path, self.human_readable \
+= contents
+else:
+self.mime_type = self.title = self.path = self.human_readable \
+= None
+_logger.debug('Current document data in unknown version')
+
 def handle_key_press(key):
 shell_model = shell.get_model()
 activity = shell_model.get_active_activity()
+bundle_path = activity.get_bundle_path()
 
+_logger.debug('Starting to handle viewsource keypress...')
 service = activity.get_service()
 if service is not None:
 try:
@@ -66,12 +128,10 @@ def handle_key_press(key):
 (window_xid, bundle_path))
 return
 
-bundle_path = activity.get_bundle_path()
-
-document_path = None
+document_data = None
 if service is not None:
 try:
-document_path = service.GetDocumentPath()
+document_data = DocumentData(service.GetDocumentData())
 except dbus.DBusException, e:
 expected_exceptions = ['org.freedesktop.DBus.Error.UnknownMethod',
 'org.freedesktop.DBus.Python.NotImplementedError']
@@ -80,22 +140,22 @@ def handle_key_press(key):
 except Exception:
 logging.error(traceback.format_exc())
 
-if bundle_path is None and document_path is None:
-_logger.debug('Activity without bundle_path nor document_path')
+if bundle_path is None and document_data.path is None:
+_logger.debug('Activity without bundle_path nor document path')
 return
 
-view_source = ViewSource(window_xid, bundle_path, document_path,
- 

[Sugar-devel] View source redesign

[Jameson Quinn]

I am in the process of writing a patch to make the view source key extension
able to open source in an appropriate activity. The basic scheme is:


   1. user presses view source
   2. extension asks activity (over dbus) if it wants to handle this one by
   itself
   3. if not, it asks activity if there is a local document it wants to give
   as a source option. activity replies with mime type, path, title, and human
   readable flag (whether to try to show it in the window)
   4. extension brings up a window, which has buttons at top for activity
   and document
   5. those buttons show the thing in the window (if possible). If path is a
   file, the file; if it is a dir, a list view/ file viewer combo.
   6. Dropdowns from these buttons allow you to open the {activity,
   document} in external editor which handles the mime type
   7. If path is a dir and external editor is launched, extension asks
   current activity to bundle it up for the external activity, and gets back a
   jobject id.

My one question is whether there will ever be a case where an activity will
want to give the option to see two or more different kinds of "source"
besides the activity source. I think not; I think one "document" at a time
is plenty.

As an example: if you're in basicbrowse activity, you press view source, you
have option of seeing python source of basicbrowse, or html of current page.
If you're in superbrowse, you get options of seeing superbrowse source or (a
bundle with html, css, svg, gif, jpg, subframe html, etc.). I think making
each of those things available separately as independent entities just leads
to a more complicated API for activity programmers with nearly no real gain.
Do others agree?

Jameson
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Activityfactory: rename activity_id to instance_id

[Jameson Quinn]

I had a brief chat with marco on IRC about activity_id. This is stored in
the datastore, unpacked to activityhandle data structure, and used to
identify an instance in a way that persists across resumes. I think
instance_id is a much better name for such a thing, and would be willing to
make the patch (basically just a global search-and-replace).

Marco says that the this is part of a larger mess, and so he seemed more
interested in redesign than in such small tinkering. I think that it's not
an either/or choice: tinkering helps redesign, it doesn't get in the way. He
suggested I discuss it on the ML, so here I am. The other possible issue is
if this is API which is used by any activities: I really think not, and I'll
do my best to check, but if you know of anything please say so.

If you want to use this thread to talk about the larger issues, please do,
it is an important discussion. But don't forget to opine on whether I should
do this one little patch.

Jameson
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel