Re: [sugar] what matters
> In its early days (based on what I read in the media), the project went > to Microsoft, Apple, Dell, etc. for assistance, only to be either turned > down or ridiculed, or some promise of help without commitment. FOSS came > in much later. So, my take on this timeline is that FOSS came into the > picture later. This is not really an accurate retelling. Nicholas did go to Intel early on, only to be rebuffed. We (Nicholas, Jim, Mako, and me) went to Microsoft in January of 2006, but already with a commitment to FOSS. -walter ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] what matters
Edward Cherlin wrote: > On Thu, Apr 24, 2008 at 9:25 AM, Sameer Verma <[EMAIL PROTECTED]> wrote: > >> Albert Cahalan wrote: >> > It's clear that we aren't all here for the same thing. >> > Some wish to help all kids, or poor kids, or non-Western >> > kids. Some wish to advance freedom of speech, freedom from >> > EULA slavery, or freedom to learn heretical ideas. >> > >> > Some of us are, assuming good intentions, extremely innocent >> > regarding Microsoft. The historical record shows that those >> > who partner with Microsoft will be betrayed in the worst way. >> > Read "The Scorpion and the Frog" to understand Microsoft. >> > > He who sups with the Devil must e'en have a long spoon. > > >> > To a very limited extent, I agree with the idea that we should >> > not be pedantic about free software. >> > > The community seems to be agreed that Microsoft can spend as much > money as it likes trying to get Sugar running on Windows, but OLPC > shouldn't divert resources from Linux to Windows unless perhaps > Microsoft chooses to pay whoever is willing, and fund the project more > broadly. As if! > > >> For what its worth, here's something that might help in analyzing the >> situation some more. Its an analytical approach called "mission and core >> competencies (MCC) matrix". >> > > Thanks. I don't think that we have such a complex problem. My main reason for providing a pointer to the Mission and Core Competencies matrix was not for addressing complexity, but to perhaps help in clarifying the issue at hand. Some decisions are strategic, while others are tactical. If you look at the mission of OLPC at http://laptop.org/vision/mission/ you'll notice that it talks about education, "learning learning" the XO, constructionism, but nowhere does it mention Free and Open Source Software. In its early days (based on what I read in the media), the project went to Microsoft, Apple, Dell, etc. for assistance, only to be either turned down or ridiculed, or some promise of help without commitment. FOSS came in much later. So, my take on this timeline is that FOSS came into the picture later (perhaps Walter was instrumental in this) and http://wiki.laptop.org/go/OLPC_on_free/open_source_software was added around early 2006. So, going back to the MCC structure (a better picture is at http://www.cipher-sys.com/HofHelp/Mcc/subsequent_adaptations_improvements.htm), the mission of OLPC is to further the education agenda, learning learning, etc. via the XO, and the OS to do all this does not look like a strategic decision, but a tactical one. They did not have the core competency to write an entire software stack for this purpose, so they outsourced it, just like they outsourced the 802.11s stuff. The major difference is that the software stack got outsourced not to a private firm, but to the FOSS community, which contributed to the project as a public commons effort. The GPL provides an exit strategy for the "community" to take it and run if the ship sinks...minus the XO, of course. Once you add the trojan horse angle, things start to look different. We now have many stakeholders and many different missions intersect. Ed Cherlin/Earth Treasury has its own mission for example, (as he stated below), and Earth Treasury has to align with OLPC for competencies that it does not have (such as the XO). We all have our reasons. I'd like to see the journal in my everyday computing platform some day. Its a terrific feature. I'd also like for villages in India to have computers for education. The project has had its problems. Update.1 is way behind schedule. The layout of the zooming interfaces have changed significantly, and that to me (personally) is troubling. But, these are managerial issues, that can be addressed by good communication. Oh, and communication goes both ways, doesn't it? I still think that the implementation of the ideas put forth by OLPC into Sugar running on top of a Linux platform is by far the best option. Apart from the public commons aspect, it provides tremendous technological value. However, for FOSS to become a strong undercurrent in this project, the decision to use FOSS will have to be strategic, and not a tactical one. > The > questions appear to be > > * Should we sell in developed countries? Nicholas--Doesn't contribute > to mission; me--Of course, to build a political base for foreign > educational aid, to address our own poor, and to finance our other > work. > > * Should we ally with Microsoft? Nicholas--It's such a brilliant > strategy, and so obvious when I point it out; me--no way. > > * Should Nicholas discuss these matters with the community? > Nicholas--What for?; me--Yes, unless you want to see the rest of us > walk out and fork Sugar. > > To me, these questions don't appear mission-like. They sound more tactical. > Anyway, nothing happens unless Nicholas decides to talk the the whole > community. Then we can di
Re: [sugar] Sugar\Windows won't ship
On Sat, Apr 26, 2008 at 3:14 PM, Ivan Krstić <[EMAIL PROTECTED]> wrote: > On Apr 26, 2008, at 4:55 PM, Albert Cahalan wrote: > > Microsoft will never cooperate with dual-boot. They haven't > > ever even bothered with false promises. Forget about it. > > > Actually, this is the last epic battle I fought at OLPC. To my > knowledge, it's a battle I won. You've either said too much or too little. Please explain who said what to whom. The rest of us have no context for your statement. I do recall your earlier statement that the XO would not suffer Windows lock-in on your watch. http://radian.org/notebook/paradox-of-choice And Microsoft has made it quite clear that it has no interest in dual-boot. http://news.zdnet.co.uk/software/0,100121,39292078,00.htm I have no idea where Nicholas gets the notion > -- > Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org > > > > ___ > Devel mailing list > [EMAIL PROTECTED] > http://lists.laptop.org/listinfo/devel -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ "The best way to predict the future is to invent it."--Alan Kay ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar\Windows won't ship
On Sat, Apr 26, 2008 at 3:46 PM, Joshua N Pritikin <[EMAIL PROTECTED]> wrote: > As I have posted before, I am not distressed by the inclusion of Windows > on the XO laptop, perhaps in a dual-boot configuration or whatever. What > would distress me is if Windows was not sold as an option. If laptops > could only be purchased with Windows, raising the price by the Microsoft > tax, that would be a cause for complaint. > > I don't think OLPC intends to go that way. Windows is about more choice, > not less, right? You're kidding I hope. Please don't. Microsoft will never cooperate with dual-boot. They haven't ever even bothered with false promises. Forget about it. Dual-boot is obviously not in Microsoft's interest. Microsoft will vigorously fight "sold as an option". Most likely they will win any such fight. The retail version will be more expensive than the bundled version. Bundling will be pushed as a way to save money. Sugar\Windows may help get a camel into the tent, but will not actually ship. Small trials may use it, but some excuse will be found to prevent actual Sugar\Windows deployments. Microsoft has a **long** history of far worse tactics. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar\Windows won't ship
On Sat, Apr 26, 2008 at 03:27:21PM -0400, [EMAIL PROTECTED] wrote: > As for Windows, the problem is that you can't scale large > installations without going bankrupt with the annual fees that > Microsoft charges.? This works out to about $100 per computer per year > in many US schools, and is one of the reasons that Brazil moved to > Linux. As I have posted before, I am not distressed by the inclusion of Windows on the XO laptop, perhaps in a dual-boot configuration or whatever. What would distress me is if Windows was not sold as an option. If laptops could only be purchased with Windows, raising the price by the Microsoft tax, that would be a cause for complaint. I don't think OLPC intends to go that way. Windows is about more choice, not less, right? ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar\Windows won't ship
I generally just lurk on this list, but this is an important topic. First, as one of the original team at Xerox PARC in the 1970's, I'm astounded that the desktop metaphor was ever imposed on kids in the first place - it is about nouns, and kids are about verbs.? Sugar gets it, and is (IMHO) the strongest part of the OLPC project.? As for kids not being able to adapt to a windows-like OS when they grow up, we fail to grasp the ease with which kids master new interfaces all the time. The fact is that Sugar is the first serious attempt I've seen to create a user interface that is based on both cognitive and social constructivism, and on Papert's constructionist thinking.? It deserves to be in the hands of millions of kids.? Kids are not miniature adults. As for Windows, the problem is that you can't scale large installations without going bankrupt with the annual fees that Microsoft charges.? This works out to about $100 per computer per year in many US schools, and is one of the reasons that Brazil moved to Linux. Yesterday, Brazil announced that, this year, 32 million kids will be using KDE on a Debian core.? It would be trivial to replace KDE with Sugar. Warmly, David Thornburg, PhD Director, Global Operations Thornburg Center Recife, Brazil | Chicago, USA -Original Message- From: Mitch Bradley <[EMAIL PROTECTED]> To: Albert Cahalan <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED]; sugar@lists.laptop.org Sent: Sat, 26 Apr 2008 2:17 pm Subject: Re: [sugar] Sugar\Windows won't ship Sugar could run inside a window or as a full-screen app with a hot key to switch. I have run Windows and Linux on the same machine for many years with that sharing style. In such a model, Sugar will be used to the extent that users prefer it. Albert Cahalan wrote: > Let's imagine this several ways, and see why it won't happen. > First consider what a faithful Sugar\Windows system would be like. > > a. the familiar "Start" menu is gone > b. regular Windows programs like Word can't run > c. OS config GUI stuff is (must be) rewritten from scratch > > I doubt anybody wants that. Stand up and shout if you do. > It is pointless, because Windows compatibility has been lost. > > If Nicolas Nigroponte takes that to a potential buyer, the first > complaint will be that Sugar\Windows isn't "real" Windows. > The edutainment junk won't run, the kids wouldn't learn the > normal Windows interface used in business, and regular Windows > users won't be able unable to support the strange mess. > > The next demand is obvious: eliminate Sugar. > > Not that many wouldn't jump for joy, but the price isn't worth it. > (price: loss of localization, loss of trojan protection, loss of > educational value, loss of nearly all volunteer support and nearly > all volunteer development help, power management problems, etc.) > > Given how the Sugar\Windows idea seems to just assume compatiblity > with regular Windows stuff, it is entirely unfair to Sugar/Linux. > Sugar/Linux could easily have compatibility with regular Linux stuff, > but this has been denied despite strong demand. > > Somebody is getting a bait-and-switch. I'm not sure who, but I would > bet that it is the Sugar fans rathar than the Windows fans. One may > even note that Sugar\Windows is a political way to ditch Sugar. > ___ > Devel mailing list > [EMAIL PROTECTED] > http://lists.laptop.org/listinfo/devel > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar\Windows won't ship
Sugar could run inside a window or as a full-screen app with a hot key to switch. I have run Windows and Linux on the same machine for many years with that sharing style. In such a model, Sugar will be used to the extent that users prefer it. Albert Cahalan wrote: > Let's imagine this several ways, and see why it won't happen. > First consider what a faithful Sugar\Windows system would be like. > > a. the familiar "Start" menu is gone > b. regular Windows programs like Word can't run > c. OS config GUI stuff is (must be) rewritten from scratch > > I doubt anybody wants that. Stand up and shout if you do. > It is pointless, because Windows compatibility has been lost. > > If Nicolas Nigroponte takes that to a potential buyer, the first > complaint will be that Sugar\Windows isn't "real" Windows. > The edutainment junk won't run, the kids wouldn't learn the > normal Windows interface used in business, and regular Windows > users won't be able unable to support the strange mess. > > The next demand is obvious: eliminate Sugar. > > Not that many wouldn't jump for joy, but the price isn't worth it. > (price: loss of localization, loss of trojan protection, loss of > educational value, loss of nearly all volunteer support and nearly > all volunteer development help, power management problems, etc.) > > Given how the Sugar\Windows idea seems to just assume compatiblity > with regular Windows stuff, it is entirely unfair to Sugar/Linux. > Sugar/Linux could easily have compatibility with regular Linux stuff, > but this has been denied despite strong demand. > > Somebody is getting a bait-and-switch. I'm not sure who, but I would > bet that it is the Sugar fans rathar than the Windows fans. One may > even note that Sugar\Windows is a political way to ditch Sugar. > ___ > Devel mailing list > [EMAIL PROTECTED] > http://lists.laptop.org/listinfo/devel > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] fix #4646 - replace/normalize some keyboard shortcuts
---
src/view/keyhandler.py | 14 ++
1 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/src/view/keyhandler.py b/src/view/keyhandler.py
index 38f8a22..b10ee60 100644
--- a/src/view/keyhandler.py
+++ b/src/view/keyhandler.py
@@ -47,19 +47,17 @@ _actions_table = {
'F11' : 'volume_min',
'F12' : 'volume_max',
'1' : 'screenshot',
-'f' : 'frame',
'0x93' : 'frame',
'0xEB' : 'rotate',
-'r' : 'rotate',
-'q' : 'quit_emulator',
'Tab' : 'next_window',
-'n' : 'next_window',
-'Tab' : 'previous_window',
-'p' : 'previous_window',
+'Tab': 'previous_window',
'Escape' : 'close_window',
-'q': 'close_window',
'0xDC' : 'open_search',
-'s' : 'say_text'
+# the following are intended for emulator users, not XO deployment kids
+'f' : 'frame',
+'q' : 'quit_emulator',
+'r' : 'rotate',
+'s' : 'say_text',
}
J_DBUS_SERVICE = 'org.laptop.Journal'
--
1.5.4.1
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar\Windows won't ship
> Sugar/Linux could easily have compatibility with regular Linux stuff, > but this has been denied despite strong demand. Albert, saying that this has been "denied" is overstated. Was it a priority in the beginning? No. Were some decisions made that make it more difficult? Yes. But are people working towards this goal? Yes. -walter On Sat, Apr 26, 2008 at 11:15 AM, Albert Cahalan <[EMAIL PROTECTED]> wrote: > Let's imagine this several ways, and see why it won't happen. > First consider what a faithful Sugar\Windows system would be like. > > a. the familiar "Start" menu is gone > b. regular Windows programs like Word can't run > c. OS config GUI stuff is (must be) rewritten from scratch > > I doubt anybody wants that. Stand up and shout if you do. > It is pointless, because Windows compatibility has been lost. > > If Nicolas Nigroponte takes that to a potential buyer, the first > complaint will be that Sugar\Windows isn't "real" Windows. > The edutainment junk won't run, the kids wouldn't learn the > normal Windows interface used in business, and regular Windows > users won't be able unable to support the strange mess. > > The next demand is obvious: eliminate Sugar. > > Not that many wouldn't jump for joy, but the price isn't worth it. > (price: loss of localization, loss of trojan protection, loss of > educational value, loss of nearly all volunteer support and nearly > all volunteer development help, power management problems, etc.) > > Given how the Sugar\Windows idea seems to just assume compatiblity > with regular Windows stuff, it is entirely unfair to Sugar/Linux. > Sugar/Linux could easily have compatibility with regular Linux stuff, > but this has been denied despite strong demand. > > Somebody is getting a bait-and-switch. I'm not sure who, but I would > bet that it is the Sugar fans rathar than the Windows fans. One may > even note that Sugar\Windows is a political way to ditch Sugar. > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] emulator-useful shortcuts back as ctrl-alt-som ething
Ugh - can you tell I use jhbuild? Any suggestions? - original message - Subject:Re: [sugar] [PATCH] emulator-useful shortcuts back as ctrl-alt-something From: "Benjamin M. Schwartz" <[EMAIL PROTECTED]> Date: 2008-04-26 15:33 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Dengler wrote: | added back emulator-required keyboard shortcuts, but with additional modifier key (in front of ) to make them much less likely to interfere with acti\ | vity shortcuts. Unfortunately, this achieves almost precisely the opposite of what you are trying to achieve. Under Qemu, pressing "Ctrl+Alt" breaks out of the emulation entirely. Thus, with the standard Qemu configuration this patch renders those shortcuts completely nonfunctional. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIE0tNUJT6e6HFtqQRAm9KAJ9nOi21wz1ZyDuFGs8AUMSk63kHVwCeJ93N H8LYij70n6ahtbFVhroT/n4= =mDIW -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] emulator-useful shortcuts back as ctrl-alt-something
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Dengler wrote: | added back emulator-required keyboard shortcuts, but with additional modifier key (in front of ) to make them much less likely to interfere with acti\ | vity shortcuts. Unfortunately, this achieves almost precisely the opposite of what you are trying to achieve. Under Qemu, pressing "Ctrl+Alt" breaks out of the emulation entirely. Thus, with the standard Qemu configuration this patch renders those shortcuts completely nonfunctional. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIE0tNUJT6e6HFtqQRAm9KAJ9nOi21wz1ZyDuFGs8AUMSk63kHVwCeJ93N H8LYij70n6ahtbFVhroT/n4= =mDIW -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] remove non-contentious keyboard shortcuts
Spoke too soon. I retract the emulator comments having now seen your
next patch. I guess my only suggestion, then, is to fix the 'previous
activity' modifiers.
- Eben
On Sat, Apr 26, 2008 at 11:31 AM, Eben Eliason <[EMAIL PROTECTED]> wrote:
> Hmmm, isn't this going to pose problems with emulation of Sugar? When
> testing, for instance, the only way I can activate the Frame is alt-F,
> and alt-Q is the only way to release the display when closing the
> emulator window. Clearly alt-n and alt-p should go, since they are
> redundant anyway. The rotate shortcut certainly isn't needed on an
> XO, but perhaps emulating the rotation would be useful for testing as
> well. Is there any way to map some of these keys when we detect
> emulation, and not otherwise?
>
> As much as ctrl-q makes sense to me personally, I suppose that there's
> no sense in having redundancy there. ctrl-escape is, at least,
> semantically appropriate it seems.
>
> Finally, it seems that the 'previous activity' shortcut should be
> alt-shift-tab instead, which is consistent with the semantics defined
> for the modifier keys.
>
> - Eben
>
>
>
>
> On Sat, Apr 26, 2008 at 11:10 AM, Martin Dengler
> <[EMAIL PROTECTED]> wrote:
> > Interpret Eben's reply to bemasc on #4646:
> >
> > > > My primary concern is that activities be able to override and
> > > > deactivate shortcuts, for whatever bizarre uses they desire. Only
> > > > a handful of special keys should be trapped by Sugar, to ensure
> > > > minimal functionality like the ability to exit the activity.
> > >
> > > This is fair enough. The ability to override the defaults could be a
> > > reasonable option.
> >
> > ...as:
> >
> > 1) NOT allowing removal of any keyboard shortcut involving a keyboard
> > key that has an XO-specific image/glyph (this reserves all the F-keys,
> > and the XO-only keys on the keyboard and monitor like search, overlay,
> > rotate, dpad, etc.) and/or are obviously required for minimal sugar
> > functionality (this reserves ctrl-esc for exit/quit activity and
> > alt-tab and ctrl-alt-tab for obvious window-switching features) - this
> > is all justified, IMHO, by eben agreeing with bemacs's
> > "only a handful of special keys should be trapped by sugar, to ensure
> > minimal functionality . . ."; and
> >
> > 2) allowing removal of any keyboard shortcut that is not required by
> > minimal sugar functionality - this is all justified both as the
> > converse of what eben's agreement with bemasc means and also as a
> > consequence of eben explictly not objecting to removing the Ctrl-O
> > shortcut ("I wouldn't be sad if [the ctrl-o/open] shortcut went away").
> >
> > The only contentiousness I can possibly see (if I've interpreted
> > eben/bemasc sympathetically) with this patch is that non-XO users of
> > sugar could lose access to the functionality now only available with
> > the XO-only keys (e.g., rotate, overlay). I argue 1) this is not a
> > concern for any deployment; and 2) this can easily be addressed by
> > choosing different, less likely-to-interfere shortcuts. As I'm less
> > comfortable choosing these shortcuts and without these shortcuts all
> > deployments can still make full use of Sugar/XO, I will defer any
> > choice of these alternates to a different patch so this patch can
> > easily be cherry-picked.
> > ---
> > src/view/keyhandler.py |7 ---
> > 1 files changed, 0 insertions(+), 7 deletions(-)
> >
> > diff --git a/src/view/keyhandler.py b/src/view/keyhandler.py
> > index 38f8a22..132eb7c 100644
> > --- a/src/view/keyhandler.py
> > +++ b/src/view/keyhandler.py
> > @@ -47,19 +47,12 @@ _actions_table = {
> > 'F11' : 'volume_min',
> > 'F12' : 'volume_max',
> > '1' : 'screenshot',
> > -'f' : 'frame',
> > '0x93' : 'frame',
> > '0xEB' : 'rotate',
> > -'r' : 'rotate',
> > -'q' : 'quit_emulator',
> > 'Tab' : 'next_window',
> > -'n' : 'next_window',
> > 'Tab' : 'previous_window',
> > -'p' : 'previous_window',
> > 'Escape' : 'close_window',
> > -'q': 'close_window',
> > '0xDC' : 'open_search',
> > -'s' : 'say_text'
> > }
> >
> > J_DBUS_SERVICE = 'org.laptop.Journal'
> > --
> > 1.5.4.1
> >
> > ___
> > Sugar mailing list
> > Sugar@lists.laptop.org
> > http://lists.laptop.org/listinfo/sugar
> >
>
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] remove non-contentious keyboard shortcuts
Hmmm, isn't this going to pose problems with emulation of Sugar? When
testing, for instance, the only way I can activate the Frame is alt-F,
and alt-Q is the only way to release the display when closing the
emulator window. Clearly alt-n and alt-p should go, since they are
redundant anyway. The rotate shortcut certainly isn't needed on an
XO, but perhaps emulating the rotation would be useful for testing as
well. Is there any way to map some of these keys when we detect
emulation, and not otherwise?
As much as ctrl-q makes sense to me personally, I suppose that there's
no sense in having redundancy there. ctrl-escape is, at least,
semantically appropriate it seems.
Finally, it seems that the 'previous activity' shortcut should be
alt-shift-tab instead, which is consistent with the semantics defined
for the modifier keys.
- Eben
On Sat, Apr 26, 2008 at 11:10 AM, Martin Dengler
<[EMAIL PROTECTED]> wrote:
> Interpret Eben's reply to bemasc on #4646:
>
> > > My primary concern is that activities be able to override and
> > > deactivate shortcuts, for whatever bizarre uses they desire. Only
> > > a handful of special keys should be trapped by Sugar, to ensure
> > > minimal functionality like the ability to exit the activity.
> >
> > This is fair enough. The ability to override the defaults could be a
> > reasonable option.
>
> ...as:
>
> 1) NOT allowing removal of any keyboard shortcut involving a keyboard
> key that has an XO-specific image/glyph (this reserves all the F-keys,
> and the XO-only keys on the keyboard and monitor like search, overlay,
> rotate, dpad, etc.) and/or are obviously required for minimal sugar
> functionality (this reserves ctrl-esc for exit/quit activity and
> alt-tab and ctrl-alt-tab for obvious window-switching features) - this
> is all justified, IMHO, by eben agreeing with bemacs's
> "only a handful of special keys should be trapped by sugar, to ensure
> minimal functionality . . ."; and
>
> 2) allowing removal of any keyboard shortcut that is not required by
> minimal sugar functionality - this is all justified both as the
> converse of what eben's agreement with bemasc means and also as a
> consequence of eben explictly not objecting to removing the Ctrl-O
> shortcut ("I wouldn't be sad if [the ctrl-o/open] shortcut went away").
>
> The only contentiousness I can possibly see (if I've interpreted
> eben/bemasc sympathetically) with this patch is that non-XO users of
> sugar could lose access to the functionality now only available with
> the XO-only keys (e.g., rotate, overlay). I argue 1) this is not a
> concern for any deployment; and 2) this can easily be addressed by
> choosing different, less likely-to-interfere shortcuts. As I'm less
> comfortable choosing these shortcuts and without these shortcuts all
> deployments can still make full use of Sugar/XO, I will defer any
> choice of these alternates to a different patch so this patch can
> easily be cherry-picked.
> ---
> src/view/keyhandler.py |7 ---
> 1 files changed, 0 insertions(+), 7 deletions(-)
>
> diff --git a/src/view/keyhandler.py b/src/view/keyhandler.py
> index 38f8a22..132eb7c 100644
> --- a/src/view/keyhandler.py
> +++ b/src/view/keyhandler.py
> @@ -47,19 +47,12 @@ _actions_table = {
> 'F11' : 'volume_min',
> 'F12' : 'volume_max',
> '1' : 'screenshot',
> -'f' : 'frame',
> '0x93' : 'frame',
> '0xEB' : 'rotate',
> -'r' : 'rotate',
> -'q' : 'quit_emulator',
> 'Tab' : 'next_window',
> -'n' : 'next_window',
> 'Tab' : 'previous_window',
> -'p' : 'previous_window',
> 'Escape' : 'close_window',
> -'q': 'close_window',
> '0xDC' : 'open_search',
> -'s' : 'say_text'
> }
>
> J_DBUS_SERVICE = 'org.laptop.Journal'
> --
> 1.5.4.1
>
> ___
> Sugar mailing list
> Sugar@lists.laptop.org
> http://lists.laptop.org/listinfo/sugar
>
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
[sugar] Sugar\Windows won't ship
Let's imagine this several ways, and see why it won't happen. First consider what a faithful Sugar\Windows system would be like. a. the familiar "Start" menu is gone b. regular Windows programs like Word can't run c. OS config GUI stuff is (must be) rewritten from scratch I doubt anybody wants that. Stand up and shout if you do. It is pointless, because Windows compatibility has been lost. If Nicolas Nigroponte takes that to a potential buyer, the first complaint will be that Sugar\Windows isn't "real" Windows. The edutainment junk won't run, the kids wouldn't learn the normal Windows interface used in business, and regular Windows users won't be able unable to support the strange mess. The next demand is obvious: eliminate Sugar. Not that many wouldn't jump for joy, but the price isn't worth it. (price: loss of localization, loss of trojan protection, loss of educational value, loss of nearly all volunteer support and nearly all volunteer development help, power management problems, etc.) Given how the Sugar\Windows idea seems to just assume compatiblity with regular Windows stuff, it is entirely unfair to Sugar/Linux. Sugar/Linux could easily have compatibility with regular Linux stuff, but this has been denied despite strong demand. Somebody is getting a bait-and-switch. I'm not sure who, but I would bet that it is the Sugar fans rathar than the Windows fans. One may even note that Sugar\Windows is a political way to ditch Sugar. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] emulator-useful shortcuts back as ctrl-alt-something
added back emulator-required keyboard shortcuts, but with additional
modifier key (in front of ) to make them much less likely to interfere
with acti\
vity shortcuts.
---
src/view/keyhandler.py |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/src/view/keyhandler.py b/src/view/keyhandler.py
index 132eb7c..9b24ab0 100644
--- a/src/view/keyhandler.py
+++ b/src/view/keyhandler.py
@@ -53,6 +53,13 @@ _actions_table = {
'Tab' : 'previous_window',
'Escape' : 'close_window',
'0xDC' : 'open_search',
+'0xDC' : 'screenshot',
+# the following are intended for emulator users, not XO deployment kids
+'f' : 'frame',
+'o' : 'overlay',
+'r' : 'rotate',
+'q' : 'quit_emulator',
+'s' : 'say_text',
}
J_DBUS_SERVICE = 'org.laptop.Journal'
--
1.5.4.1
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] remove non-contentious keyboard shortcuts
Interpret Eben's reply to bemasc on #4646:
> > My primary concern is that activities be able to override and
> > deactivate shortcuts, for whatever bizarre uses they desire. Only
> > a handful of special keys should be trapped by Sugar, to ensure
> > minimal functionality like the ability to exit the activity.
>
> This is fair enough. The ability to override the defaults could be a
> reasonable option.
...as:
1) NOT allowing removal of any keyboard shortcut involving a keyboard
key that has an XO-specific image/glyph (this reserves all the F-keys,
and the XO-only keys on the keyboard and monitor like search, overlay,
rotate, dpad, etc.) and/or are obviously required for minimal sugar
functionality (this reserves ctrl-esc for exit/quit activity and
alt-tab and ctrl-alt-tab for obvious window-switching features) - this
is all justified, IMHO, by eben agreeing with bemacs's
"only a handful of special keys should be trapped by sugar, to ensure
minimal functionality . . ."; and
2) allowing removal of any keyboard shortcut that is not required by
minimal sugar functionality - this is all justified both as the
converse of what eben's agreement with bemasc means and also as a
consequence of eben explictly not objecting to removing the Ctrl-O
shortcut ("I wouldn't be sad if [the ctrl-o/open] shortcut went away").
The only contentiousness I can possibly see (if I've interpreted
eben/bemasc sympathetically) with this patch is that non-XO users of
sugar could lose access to the functionality now only available with
the XO-only keys (e.g., rotate, overlay). I argue 1) this is not a
concern for any deployment; and 2) this can easily be addressed by
choosing different, less likely-to-interfere shortcuts. As I'm less
comfortable choosing these shortcuts and without these shortcuts all
deployments can still make full use of Sugar/XO, I will defer any
choice of these alternates to a different patch so this patch can
easily be cherry-picked.
---
src/view/keyhandler.py |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/src/view/keyhandler.py b/src/view/keyhandler.py
index 38f8a22..132eb7c 100644
--- a/src/view/keyhandler.py
+++ b/src/view/keyhandler.py
@@ -47,19 +47,12 @@ _actions_table = {
'F11' : 'volume_min',
'F12' : 'volume_max',
'1' : 'screenshot',
-'f' : 'frame',
'0x93' : 'frame',
'0xEB' : 'rotate',
-'r' : 'rotate',
-'q' : 'quit_emulator',
'Tab' : 'next_window',
-'n' : 'next_window',
'Tab' : 'previous_window',
-'p' : 'previous_window',
'Escape' : 'close_window',
-'q': 'close_window',
'0xDC' : 'open_search',
-'s' : 'say_text'
}
J_DBUS_SERVICE = 'org.laptop.Journal'
--
1.5.4.1
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Fix appearance of activity bundles (in Journal)
After much ado, here is the resulting patch.
- Eben
On Fri, Apr 25, 2008 at 2:17 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote:
>
> On Wed, Apr 23, 2008 at 10:05 PM, Eben Eliason <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, Apr 23, 2008 at 3:52 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote:
> > > On Wed, Apr 23, 2008 at 9:45 PM, Eben Eliason <[EMAIL PROTECTED]> wrote:
> > > > Hmm, you mean:
> > > >
> > > >
> > > > if jobject.metadata.get('title', ''):
> > > > title_text = jobject.metadata.get('title', '')
> > > > else
> > > > title_text = _('Untitled')
> > > >
> > > > title.props.text = title_text
> > > > ...
> > > >
> > > > Do I not need to declare title_text outside the scope of the
> condition
> > > > first? For that matter, is the null string always treated as False
> in
> > > > conditions, even though it's distinct from None type?
> (Sorry...didn't
> > > > play in Python much before.)
> > >
> > > Sorry, didn't meant that as a literal solution.
> > >
> > >
> > > > I supposed there's also:
> > > >
> > > > title_text = _('Untitled')
> > > >
> > > > if jobject.metadata.get('title', ''):
> > > > title_text = jobject.metadata.get('title', '')
> > > >
> > > > title.props.text = title_text
> > >
> > > This I don't like much, the person that reads needs to make more
> > > effort to see that you are overriding the var.
> > >
> > > This is what I would do:
> > >
> > >
> > > if jobject.metadata.get('title', ''):
> > >title.props.text = jobject.metadata['title']
> > > else
> > >title.props.text = _('Untitled')
> >
> >
> > I'm not sure I like that much either, since I have to set two things
> > to the values.
> >
> >
> > if jobject.metadata.get('title', ''):
> > self._title.props.text = jobject.metadata['title']
> > self._title_entry.props.text = jobject.metadata['title']
> > else
> >
> >
> > self._title.props.text = _('Untitled')
> > self._title_entry.props.text = _('Untitled')
> >
> > Hence, the reason to use a variable instead. Do you prefer this?
>
> Yes, a 'title' variable is better in this case.
>
>
> if jobject.metadata.get('title', ''):
> title = jobject.metadata['title']
> else
> title = _('Untitled')
> self._title.props.text = title
> self._title_entry.props.text = title
>
> Tomeu
>
From c2e1c3fc756550d9ce3b2d609ee499a6314780b7 Mon Sep 17 00:00:00 2001
From: Eben Eliason <[EMAIL PROTECTED]>
Date: Thu, 24 Apr 2008 05:00:18 -0400
Subject: [PATCH] Fix appearance of activity bundles
---
collapsedentry.py | 22 +-
expandedentry.py | 10 ++
palettes.py |2 +-
3 files changed, 12 insertions(+), 22 deletions(-)
diff --git a/collapsedentry.py b/collapsedentry.py
index c99208a..1abc7de 100644
--- a/collapsedentry.py
+++ b/collapsedentry.py
@@ -192,12 +192,6 @@ class CollapsedEntry(hippo.CanvasBox):
buddies = []
return buddies
-def _format_title(self):
-if self.jobject.metadata.has_key('title'):
-return '%s' % self.jobject.metadata['title']
-else:
-return '%s' % _('Untitled')
-
def _update_visibility(self):
in_process = self._is_in_progress()
@@ -323,21 +317,23 @@ class CollapsedEntry(hippo.CanvasBox):
self._icon.props.file_name = misc.get_icon_name(jobject)
if jobject.is_activity_bundle():
self._icon.props.fill_color=style.COLOR_TRANSPARENT.get_svg()
-self._icon.props.stroke_color=style.COLOR_BLACK.get_svg()
-self._title.props.text = self._format_title() + _(' Activity')
-self._title_entry.props.text = self._format_title() + _(' Activity')
+self._icon.props.stroke_color=style.COLOR_BUTTON_GREY.get_svg()
else:
if jobject.metadata.has_key('icon-color') and \
jobject.metadata['icon-color']:
self._icon.props.xo_color = XoColor( \
jobject.metadata['icon-color'])
else:
-self._icon.props.xo_color = None
-self._title.props.text = self._format_title()
-self._title_entry.props.text = self._format_title()
+self._icon.props.xo_color = None
-self._icon.set_palette(ObjectPalette(jobject))
+if jobject.metadata.get('title', ''):
+title_text = jobject.metadata['title']
+else:
+title_text = _('Untitled')
+self._title.props.text = title_text
+self._title_entry.props.text = title_text
+self._icon.set_palette(ObjectPalette(jobject))
self._buddies_list.set_model(self._decode_buddies())
if jobject.metadata.has_key('progress'):
diff --git a/expandedentry.py b/expandedentry.py
index 693a41c..9534c4d 100644
--- a/expandedentry.py
+++ b/expandedentry.py
@@ -160,7 +160,7 @@ class ExpandedEntry(hippo.
Re: [sugar] what matters
On Thu, Apr 24, 2008 at 9:25 AM, Sameer Verma <[EMAIL PROTECTED]> wrote: > > Albert Cahalan wrote: > > It's clear that we aren't all here for the same thing. > > Some wish to help all kids, or poor kids, or non-Western > > kids. Some wish to advance freedom of speech, freedom from > > EULA slavery, or freedom to learn heretical ideas. > > > > Some of us are, assuming good intentions, extremely innocent > > regarding Microsoft. The historical record shows that those > > who partner with Microsoft will be betrayed in the worst way. > > Read "The Scorpion and the Frog" to understand Microsoft. He who sups with the Devil must e'en have a long spoon. > > To a very limited extent, I agree with the idea that we should > > not be pedantic about free software. The community seems to be agreed that Microsoft can spend as much money as it likes trying to get Sugar running on Windows, but OLPC shouldn't divert resources from Linux to Windows unless perhaps Microsoft chooses to pay whoever is willing, and fund the project more broadly. As if! > For what its worth, here's something that might help in analyzing the > situation some more. Its an analytical approach called "mission and core > competencies (MCC) matrix". Thanks. I don't think that we have such a complex problem. The questions appear to be * Should we sell in developed countries? Nicholas--Doesn't contribute to mission; me--Of course, to build a political base for foreign educational aid, to address our own poor, and to finance our other work. * Should we ally with Microsoft? Nicholas--It's such a brilliant strategy, and so obvious when I point it out; me--no way. * Should Nicholas discuss these matters with the community? Nicholas--What for?; me--Yes, unless you want to see the rest of us walk out and fork Sugar. Anyway, nothing happens unless Nicholas decides to talk the the whole community. Then we can discuss the other two points. It isn't a question of who has which competencies, except for Nicholas to realize that he can't outsmart Microsoft, and that he has tried to over-optimize one variable out of an entire equation. And we should hire more programmers, a doc team, and a few others that Nicholas and the community generally agree on, and discuss what to do after that. Then maybe Walter and Ivan and a few other valuable contributors would be willing to discuss coming back. -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ "The best way to predict the future is to invent it."--Alan Kay ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add speaker device and icon by default
On Sat, Apr 26, 2008 at 06:07:45AM -0400, Wade Brainerd wrote: > On Fri, Apr 25, 2008 at 1:56 PM, Eben Eliason <[EMAIL PROTECTED]> wrote: > > On Fri, Apr 25, 2008 at 1:46 PM, Martin Dengler > > > self._mute_item.get_child().set_text(_(mute_item_text)) > > > > Oh, I missed that. I would wrap the localization around the string > > literal, so the connection is clear. (Yes, you have to use it twice > > instead of oncebut it was imported as _ for a reason. ;) ) > > Won't gettext fail to pick these up when generating the .pot file, the > way it's written now? > > I was under the impression it just looks blindly through the source > for _() when building the translation files... Yes -- I didn't know this at the time. Thanks for pointing it out. Others pointed it out to me on IRC, too, and my most recent patch addresses the point. Thanks again for the time/feedback. > Wade Martin pgpAhI0Q7Jed4.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add speaker device and icon by default
On Fri, Apr 25, 2008 at 1:56 PM, Eben Eliason <[EMAIL PROTECTED]> wrote: > On Fri, Apr 25, 2008 at 1:46 PM, Martin Dengler > > self._mute_item.get_child().set_text(_(mute_item_text)) > > Oh, I missed that. I would wrap the localization around the string > literal, so the connection is clear. (Yes, you have to use it twice > instead of oncebut it was imported as _ for a reason. ;) ) Won't gettext fail to pick these up when generating the .pot file, the way it's written now? I was under the impression it just looks blindly through the source for _() when building the translation files... Wade ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
