[sugar] Alternative to Terminal ?
>> [I have not yet found an acceptable multi-screen replacement for Terminal.] > > Have you tried http://wiki.laptop.org/go/Quake_Terminal? Tried it a while ago. Found it completely unusable, because I could not figure out how to scroll up on the display. [Many programs produce more output lines than the small XO screen will show.] mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] replace/normalize some keyboard shortcuts
On Tue, Apr 29, 2008 at 5:17 PM, Mikus Grinbergs <[EMAIL PROTECTED]> wrote: > > I don't expect kids to have more than half a dozen or so activities > > running at once. Cycling around wouldn't be the end of the world. > > [I have not yet found an acceptable multi-screen replacement for > Terminal.] Given the small OLPC screen, what I do is start two > instances of Terminal - then use one to "read" information (i.e., > for 'reference') and the other to "write" what I'm working on (i.e., > for 'output'). This usually involves a lot of navigating back and > forth between these two Terminal instances. "Cycling around" seems > very cumbersome (and it actually is time-consuming). Maybe one of > these years I'll write some scripts to 'select' each instance, then > attach them to keyboard keys. That should give me good "operator > performance" - a single keypress and I get to a specific instance. Another shortcut I very much hope to add (can someone comment on how easy this would be?) is alt-backtick ((`), tilde (~), minus shift) for cycling through all instances of the currently selected activity. This would allow you to, for instance, toggle back and forth between your two terminal instances regardless of how many other activities you had running. Another discussion this revisits is which method we desire to implement for alt-tab cycling. The current implementation simply cycles through activities in the order in which they were launched, and that order never changes. The more common approach is to keep a stack from which you can pull out arbitrary elements and then push them on top when they are focused. This means that alt-tab always cycles through the list in the order of last use instead, allowing ping-pong navigation between the two at the top of the stack. This has some great usability advantages, but is tricker to fuse with the arrangement of icons in the Frame (we intended to have alt-tab reveal the Frame so that it was possible to see the running activities while switching through them), since they rearrange themselves. A short animation of this rearrangement, such that activities are ordered by last use, with the active/most recent at the far left, is something we've considered, but not decided upon. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] replace/normalize some keyboard shortcuts
On Tue, Apr 29, 2008 at 5:17 PM, Mikus Grinbergs <[EMAIL PROTECTED]> wrote: > [I have not yet found an acceptable multi-screen replacement for > Terminal.] > Have you tried http://wiki.laptop.org/go/Quake_Terminal? Wade ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] replace/normalize some keyboard shortcuts
> I don't expect kids to have more than half a dozen or so activities > running at once. Cycling around wouldn't be the end of the world. [I have not yet found an acceptable multi-screen replacement for Terminal.] Given the small OLPC screen, what I do is start two instances of Terminal - then use one to "read" information (i.e., for 'reference') and the other to "write" what I'm working on (i.e., for 'output'). This usually involves a lot of navigating back and forth between these two Terminal instances. "Cycling around" seems very cumbersome (and it actually is time-consuming). Maybe one of these years I'll write some scripts to 'select' each instance, then attach them to keyboard keys. That should give me good "operator performance" - a single keypress and I get to a specific instance. mikus (G1G1) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
On Tue, Apr 29, 2008 at 1:58 PM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > We should ban banners, really :) > > The two points that makes our feedback different from a banner are: > > * It reinforces the zoom metaphor. > * It deals with the problem of children clicking on 2-3 activities at > the same time, which proved to be a real issue in the field (will > faster activities address this? not sure). > I think Eben's got a great plan. The iPhone does something similar, when you hit say the "Clock" icon on the home screen you are instantly zoomed into a static representation of the UI, which populates in a few seconds once the program launches. Overall, it gives the impression of high performance and instant feedback, when the reality may not be that. I also like how it deals with the problem of clicking more activities while some are already launching, I have succumbed to that before :) Ultimately this combined with 2-3 second launching should provide a perfectly good experience. Perhaps for the power users, shift-click could mean "launch this activity in the background"? -Wade ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
Michael Stone wrote: > Personally, I have found extensible autostart mechanisms which process > third-party data to be more useful to trojan authors than to users so > I'm mildly inclined to consider such mechanisms to be a misfeatures Then don't make it easily extensible. I already manually change the python scripts to tell rainbow that certain (admittedly mis-written) activities should be allowed to write their configuration files to an "improper" location. If making another change to a python script will save me having to perform a series of cursor moves and manual clicks after each boot, that's worth it to me to set up "autostart". My bigger point is - how does not "autostarting" an activity keep away trojan authors? If the trojan author is worth his salt, he will have superseded the legitimate activity. That trojan will still be activated when the user clicks on the associated icon. To me, whether one mechanism or another is used to launch such a thing makes little difference. Remember - one intent behind the OLPC is "to make it easy for a kid to program". I know of no way to screen out trojan authors. > On an XO running a recent build (including 703), almost all activities > are prevented from writing to interesting places like .xsession. I see no reason why "autostarted" activities should not be given the same protections by rainbow as "clickstarted" activities. > Avoiding autostart means that reboot is much more powerful - rebooting > will actually have some chance of restoring your system to a workable state I'm not intending to "restart" everything the system was running when it was shut down. But I do want a 'clean' version of Terminal to be available to me right after booting - so I can for instance look at system internals (I prefer Terminal to the text console). Having it come up automatically makes my life easier. mikus ___ 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 | 25 -
1 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/src/view/keyhandler.py b/src/view/keyhandler.py
index 306bb21..219cc5e 100644
--- a/src/view/keyhandler.py
+++ b/src/view/keyhandler.py
@@ -40,26 +40,25 @@ _actions_table = {
'F4' : 'zoom_activity',
'F9' : 'brightness_down',
'F10': 'brightness_up',
-'F9' : 'brightness_min',
-'F10' : 'brightness_max',
+'F9': 'brightness_min',
+'F10' : 'brightness_max',
'F11': 'volume_down',
'F12': 'volume_up',
-'F11' : 'volume_min',
-'F12' : 'volume_max',
+'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',
+'Tab': 'previous_window',
+'Escape': 'close_window',
'0xDC' : 'open_search',
-'s' : 'say_text'
+# the following are intended for emulator users
+'f' : 'frame',
+'q' : 'quit_emulator',
+'o' : 'open_search',
+'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] perceived sugar performance
On Tue, Apr 29, 2008 at 03:31:05PM -0400, Paul Fox wrote: > michael wrote: > > On Tue, Apr 29, 2008 at 02:54:15PM -0400, Paul Fox wrote: > > > michael wrote: > > > > Depends. Any software you run can write to your .xsession, yes? > > > > Afterward, will you really notice an extra instance of 'bash', or > > > > 'kdmgd', or some other nonsense running in the background, capturing > all > > > > your keystrokes, aliasing 'sudo', running 'xauth ++', setting up a > > > > spambot, or querying an IRC server for recent local root exploits? > > > > > > eek! time to retire. ;-) > > > > > > your point is well taken, but since any program i run manually > > > can also write to lots and lots of things that i run, or use as > > > config, > > > > On an XO running a recent build (including 703), almost all activities > > are prevented from writing to interesting places like .xsession. We just > > invent new uids and gids (user ids and group ids) for them on demand. > > Also, there's plenty left to do to help control the current exceptions. > > this paragraph is an argument that autostart is "okay" on the XO -- > not as dangerous as it is on my traditional workstation. It suggests that we've made it a bit harder to scribble over the filesystem. There's plenty of nasty things that can still be done. One must also reflect upon what holes still lurk in the system. :) Also, I think my comment that extensible user-level autostart systems running software that touches data which arrived over a network cost more than you think (and more than they're worth in convenience) still stands. Thanks for the invigorating discussion, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] fix #4646 - replace/normalize some keyboard shortcuts
On Tue, Apr 29, 2008 at 3:21 PM, Benjamin M. Schwartz <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > Martin Dengler wrote: > | 'F12': 'volume_up', > | 'F11' : 'volume_min', > | 'F12' : 'volume_max', > Given our ctrl/alt/shift distinction, it seems to me that these should be > F11 and > F12 > This is philosophically consistent with the idea that makes small > letters into BIG LETTERS, and similarly makes small volume changes into > maximum volume changes. Alternatively they could be F11 and > F12. But in any event, if we're going to avoid shortcuts in > the shell, then these should change too. Yes, I think alt is the more appropriate key in this case. The same is true for brightness. > | +'0xDC' : 'screenshot', > I think 0x93 would actually be better (this is what I meant to > suggest). In other words, I think "frame" is better than > "search" for taking a screenshot. This is because the visual of the > frame suggests that it includes the contents of the screen, and is a sort > of "picture frame", so there is a nice abstract connection. I'm personally not ready to attribute the screenshot with the semantics of these other specialized keys. I think there may be some better used for them in the future, and am more content to leave it as the mostly meaningless alt-1 until we have a clearer direction. While the icon on the key is reminiscent of a photo frame, I don't think the actual semantics of the two functions relate. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
michael wrote: > On Tue, Apr 29, 2008 at 02:54:15PM -0400, Paul Fox wrote: > > michael wrote: > > > Depends. Any software you run can write to your .xsession, yes? > > > Afterward, will you really notice an extra instance of 'bash', or > > > 'kdmgd', or some other nonsense running in the background, capturing all > > > your keystrokes, aliasing 'sudo', running 'xauth ++', setting up a > > > spambot, or querying an IRC server for recent local root exploits? > > > > eek! time to retire. ;-) > > > > your point is well taken, but since any program i run manually > > can also write to lots and lots of things that i run, or use as > > config, > > On an XO running a recent build (including 703), almost all activities > are prevented from writing to interesting places like .xsession. We just > invent new uids and gids (user ids and group ids) for them on demand. > Also, there's plenty left to do to help control the current exceptions. this paragraph is an argument that autostart is "okay" on the XO -- not as dangerous as it is on my traditional workstation. > > > i'm not sure why autostart makes a huge difference. > i think i should have added "... from a security perspective." > Avoiding autostart means that reboot is much more powerful - rebooting > will actually have some chance of restoring your system to a workable > state. It also gives you a small mischief diagnosis tool - you can do > controlled experiments to determine whether your system does annoying > things when you run specific activities. (We're thinking of trying to > add some power usage monitoring and some network isolation that will > further support this use.) Combined with a button or option on each > activity that lets one wipe away cached state, this system will > plausibly have achieved a new plateau of mischief resilience. i never considered that there wouldn't be a "safe mode" override for autostart. (just as you wouldn't implement hibernate without the ability to still do a true cold boot.) paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 46.2 degrees) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] fix #4646 - replace/normalize some keyboard shortcuts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Dengler wrote: | 'F12': 'volume_up', | 'F11' : 'volume_min', | 'F12' : 'volume_max', Given our ctrl/alt/shift distinction, it seems to me that these should be F11 and F12 This is philosophically consistent with the idea that makes small letters into BIG LETTERS, and similarly makes small volume changes into maximum volume changes. Alternatively they could be F11 and F12. But in any event, if we're going to avoid shortcuts in the shell, then these should change too. | +'0xDC' : 'screenshot', I think 0x93 would actually be better (this is what I meant to suggest). In other words, I think "frame" is better than "search" for taking a screenshot. This is because the visual of the frame suggests that it includes the contents of the screen, and is a sort of "picture frame", so there is a nice abstract connection. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIF3VNUJT6e6HFtqQRAkY+AJ9IO0kutkbsFVsu+3MQ+x9kkL6T3wCaA7Xd r8UuhS8KbGlRpl/Z6X9539E= =ytjY -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar Digest, Vol 22, Issue 98
On Mon, Apr 28, 2008 at 4:36 PM, J.M. Maurer <[EMAIL PROTECTED]> wrote: > > > On Mon, 2008-04-28 at 09:26 -0700, ValS wrote: > > Thanks for this wonderful program! Speaking as an XO user, I am > > requesting a feature that I imagine would benefit any users that have > > internet access. I would like to be able to use the Write function, > > and then send what I have written in an email as an attachment. That > > way, I can send it to others, send it to a computer with a printer, > > and use the written material in various ways, even as a book. So is > > there a chance of compatibility between the Write (and other) > > functions and the Browse (where we can access email)? > > If there is any service on the XO that can send email, then this would > be trivial to add to Write. Isn't there a Google SoC application this > year to create an an email thing based on tinymail for the XO ? Interesting. When I read this the first time, I only considered the approach of first opening an email interface (for instance, Gmail in Browse) and then selecting a file from the Journal to attach to it. I hadn't considered wanting to send the document I'm *currently working on* to someone else as an attachment. One reason for this might be due to the fact that we *do* plan to add a "send to..." option to the palette/toolbar for each activity, to allow direct file transfers between people running Sugar. Perhaps there is a place in here somewhere for "mail to..." as well? Or, perhaps under send to it's possible to select an individual, or a group, or an *activity* (!) which could then take some action based upon what it was given. By selecting an email activity, it could generate a new draft message and automatically attach the file. - Eben ___ 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 | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/view/keyhandler.py b/src/view/keyhandler.py
index 306bb21..eac4fa6 100644
--- a/src/view/keyhandler.py
+++ b/src/view/keyhandler.py
@@ -46,20 +46,20 @@ _actions_table = {
'F12': 'volume_up',
'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',
+'Tab': 'previous_window',
+'Escape': 'close_window',
'0xDC' : 'open_search',
-'s' : 'say_text'
+'0xDC' : 'screenshot',
+# the following are intended for emulator users
+'1' : 'screenshot',
+'f' : 'frame',
+'q' : 'quit_emulator',
+'o' : 'open_search',
+'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] DS possibilities
On Wed, Apr 23, 2008 at 10:19 PM, Benjamin M. Schwartz <[EMAIL PROTECTED]> wrote: > Based on these options, I personally recommend that the priorities be: > > 1. Write a new datastore implementation to the same API. > 1. Set up a datastore test system. > 2. Improve logging. > - --- Future --- > 3. Write a new datastore implementation with a new API. > 3. Notify the user when things go wrong. > > My recommendation is not very strong. I can see many other reasonable > arguments. However, I prefer this one: > > After glancing at Michael's Simple Data Store code, I am convinced that it > would be easy to turn it into a complete implementation of the current > datastore API, with a backend that is simply individual files in the > filesystem. Where would metadata be stored? > Search could be implemented by grep -R, or something of > similar complexity. Hmm, I see filtering and fulltext search as really important features. Do we really want to grep instead of using some kind of index? > I would be perfectly happy to replace the current > datastore layer with this one (though the upgrade mechanism will take some > careful thought). If some code from the existing implementation is still > applicable, then it may of course be reused. Indeed, the rewrite vs. fix > distinction is something of a false dichotomy; the major issue is whether > or not to use Xapian and other advanced algorithmic designs. I think that most of our problems come from using Xapian for storing the metadata, but not from using it as what it is intended: a fulltext search engine. I actually think that it has worked quite well for that purpose. > The principle objection to this path, it seems to me, is the possibility > of introducing new (worse) bugs. A datastore test system would greatly > increase confidence in any new implementation. If the test system can > also reproduce crashes in the current implementation, then we may > determine with some confidence whether the new implementation is more > reliable (under those circumstances). Logging goes hand-in-hand with > testing; it is needed in order to determine the results. Having better > logging in production laptops will be a positive side benefit. Agreed, but I would like to note that the DS is (to my knowledge) the component in Sugar with most extensive unit tests. > I recognize the importance of providing version control functionality > within the datastore, but the deadline for this work appears to be July, > pending an August release. It seems unlikely to me that any > future-proofed version control system could be completed, and integrated > with the rest of the system, in two months. If anyone wishes to argue the > opposite point, I will be happy to listen, since I desire this feature > greatly. If the version control project is sufficiently important, it may > be acceptable to place an expert (presumably Scott) on this full-time > targeting a December release. I think that it depends on which features we wish to add. This scheme may be enough to provide the user experience that Eben has devised: - Store a version number as a metadata property. Create a branch every time that a non-tip revision is resumed. Suggested format: 3.1.1. - Use xdelta to store backwards deltas between versions of the same file. Probably calculate a hash of the content so we can optimize out the no-changes case. - That's all ;) See here for the last work from Ben Saller related to versions: http://dev.laptop.org/git?p=projects/datastore;a=shortlog;h=version_prototype > Notifying the user when critical system components stop working is a good > goal as long as it doesn't distract from the more important work of making > the critical system components work reliably. It seems to me that the UI > team's work on the wide variety of frequent, user-interaction > notifications is far more important, and also sets the stage for this work > later. Yes, the "journal full" notification is one example. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
On Tue, Apr 29, 2008 at 02:54:15PM -0400, Paul Fox wrote: > michael wrote: > > Depends. Any software you run can write to your .xsession, yes? > > Afterward, will you really notice an extra instance of 'bash', or > > 'kdmgd', or some other nonsense running in the background, capturing all > > your keystrokes, aliasing 'sudo', running 'xauth ++', setting up a > > spambot, or querying an IRC server for recent local root exploits? > > eek! time to retire. ;-) > > your point is well taken, but since any program i run manually > can also write to lots and lots of things that i run, or use as > config, On an XO running a recent build (including 703), almost all activities are prevented from writing to interesting places like .xsession. We just invent new uids and gids (user ids and group ids) for them on demand. Also, there's plenty left to do to help control the current exceptions. > i'm not sure why autostart makes a huge difference. Avoiding autostart means that reboot is much more powerful - rebooting will actually have some chance of restoring your system to a workable state. It also gives you a small mischief diagnosis tool - you can do controlled experiments to determine whether your system does annoying things when you run specific activities. (We're thinking of trying to add some power usage monitoring and some network isolation that will further support this use.) Combined with a button or option on each activity that lets one wipe away cached state, this system will plausibly have achieved a new plateau of mischief resilience. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote: | On Tue, Apr 29, 2008 at 2:34 PM, Michael Stone <[EMAIL PROTECTED]> wrote: |> On Tue, Apr 29, 2008 at 02:15:54PM -0400, Paul Fox wrote: |> > michael wrote: |> > > Also, where does hibernation fit in your taxonomy? |> > |> > i'd think that's pretty different -- coming out of hibernation |> > should leave the system exactly as it was when it went in. |> > (unless i'm misunderstanding.) |> |> You understood correctly. It has been previously proposed that we should |> (more or less) always hibernate. I was curious if you had thought about |> the resulting system. | | Interesting. To clarify for myself, you're actually asking "what if a | normal reboot was treated as though it were hibernation", such that | the next time the laptop boots I find myself where I left off?" On | one hand, this sounds like a fantastic idea. On the other hand, it | could be that I rebooted specifically to get myself out of some bad | state, in which case I might not want it to relaunch 5 activities | which are going to bring the system to a crawl upon booting. (But | maybe I misunderstood you...) | | Something that is certainly much more valid is to hibernate in the | battery-dies case. In other words, if the battery reaches a | critically low state and the computer needs to turn off, it should | allow enough time to hibernate such that the full state can be | recovered when a poer cable, or a new battery. That I am a strong | advocate for. I agree. To be clear, Michael is potentially referring to two different things. The first, "true hibernation", uses kernel-level mechanisms to write a copy of the RAM out to non-volatile storage before shutting down, and reads it back after boot. This is potentially expensive in terms of disk space. Also, given JFFS2's current read and write speeds, hibernating might be slower than boot, though without compression it could definitely be much faster than our current boot sequence. This "true hibernation" brings the system back to precisely the same state at which it was left off, with videos still running, and infinite loops still looping. We have also discussed another concept, which I have called "fake hibernation". In "fake hibernation", Sugar simply commands all Activities to save their state, notes which activity instances were running, and shuts down. On the next boot, it resumes those activity instances from the datastore. This returns to the previous state only to the degree that Activities save their state. For example, Browse would return to the same address, but Terminal would load as a completely new instance. Fake hibernation would not be any faster than conventional boot and shutdown, but it would require essentially zero disk space. I strongly prefer fake hibernation. I think it would be excellent to make it the default in the case of low-battery shutoff, and perhaps in other cases as well. However, we cannot speak very intelligently about it until it has been implemented. The suggested implementation that I'm aware of is to use Gnome's new session management system, which is just now approaching usability. However, it has not been a priority, and requires some significant knowledge of both session management and Sugar. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIF3EkUJT6e6HFtqQRAmj1AJ9hchEkc4jG0ZfzgFCX6eN/X9j18gCfa980 PIBfEDQdYnpjd7bs/tiHHIY= =+9f2 -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
michael wrote: > On Tue, Apr 29, 2008 at 02:15:54PM -0400, Paul Fox wrote: > > michael wrote: > > > Personally, I have found extensible autostart mechanisms which process > > > third-party data to be more useful to trojan authors than to users so > > > I'm mildly inclined to consider such mechanisms to be a misfeatures > > > > really? i'm not sure where the "third-party" data comes into it. i > > suppose with browse, maybe, but my .xsession has started two xterms on > > my desktop for many years, and i've never considered it a security > > issue. just a time-saver. > > Depends. Any software you run can write to your .xsession, yes? > Afterward, will you really notice an extra instance of 'bash', or > 'kdmgd', or some other nonsense running in the background, capturing all > your keystrokes, aliasing 'sudo', running 'xauth ++', setting up a > spambot, or querying an IRC server for recent local root exploits? eek! time to retire. ;-) your point is well taken, but since any program i run manually can also write to lots and lots of things that i run, or use as config, i'm not sure why autostart makes a huge difference. and although i have little windows experience, i'd have to imagine the case is much the same vis a vis the Start directory. but perhaps there's a distinction i'm missing. > > > Also, where does hibernation fit in your taxonomy? > > > > i'd think that's pretty different -- coming out of hibernation > > should leave the system exactly as it was when it went in. > > (unless i'm misunderstanding.) > > You understood correctly. It has been previously proposed that we should > (more or less) always hibernate. I was curious if you had thought about > the resulting system. if the system can yawn and wake up from hibernation appreciably faster than from a cold boot, clearly that will be a Good Thing. (for some reason this isn't noticeably the case on my current ubuntu (gutsy) laptop.) (this is wandering from sugar performance perceptions.) paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 45.0 degrees) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
On Tue, Apr 29, 2008 at 2:34 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > On Tue, Apr 29, 2008 at 02:15:54PM -0400, Paul Fox wrote: > > michael wrote: > > > Personally, I have found extensible autostart mechanisms which process > > > third-party data to be more useful to trojan authors than to users so > > > I'm mildly inclined to consider such mechanisms to be a misfeatures > > > > really? i'm not sure where the "third-party" data comes into it. i > > suppose with browse, maybe, but my .xsession has started two xterms on > > my desktop for many years, and i've never considered it a security > > issue. just a time-saver. > > Depends. Any software you run can write to your .xsession, yes? > Afterward, will you really notice an extra instance of 'bash', or > 'kdmgd', or some other nonsense running in the background, capturing all > your keystrokes, aliasing 'sudo', running 'xauth ++', setting up a > spambot, or querying an IRC server for recent local root exploits? > > Actually, an even more compelling demonstration of the problem comes > from the Windows world. Consider the Windows 'Start' directory, the > Windows registry hives which list both autostarted "user programs" and > "services", automatically loaded drivers, corruption of Word's > normal.dot template, and Windows' tendency to automatically run software > it that it locates on data CDs. I have seen every single one of these > mechanisms used to cause substantial mischief. All of them amount to an > automatic "run this software" API. Often, there are ways to have the > software run silently, run in a fashion that users are unable to kill, > run steganographically, etc. As I said - in my honest opinion, it's a > misfeature rather than a feature. > > "Third party" comes into it because parsing untrusted data is such a > dangerous operation, particularly when the parsers are written in a > non-memory-safe language (as most of them are, "for performance"). For > this reason, both the Journal and Telepathy really scare me because they > run automatically and parse data from lots of third party sources. > > > > > Also, where does hibernation fit in your taxonomy? > > > > i'd think that's pretty different -- coming out of hibernation > > should leave the system exactly as it was when it went in. > > (unless i'm misunderstanding.) > > You understood correctly. It has been previously proposed that we should > (more or less) always hibernate. I was curious if you had thought about > the resulting system. Interesting. To clarify for myself, you're actually asking "what if a normal reboot was treated as though it were hibernation", such that the next time the laptop boots I find myself where I left off?" On one hand, this sounds like a fantastic idea. On the other hand, it could be that I rebooted specifically to get myself out of some bad state, in which case I might not want it to relaunch 5 activities which are going to bring the system to a crawl upon booting. (But maybe I misunderstood you...) Something that is certainly much more valid is to hibernate in the battery-dies case. In other words, if the battery reaches a critically low state and the computer needs to turn off, it should allow enough time to hibernate such that the full state can be recovered when a poer cable, or a new battery. That I am a strong advocate for. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] xomail
On Tue, Apr 29, 2008 at 11:27:56AM -0400, Kevin Cole wrote: > On Mon, Apr 28, 2008 at 10:05 PM, Joshua N Pritikin <[EMAIL PROTECTED]> wrote: > > I think a better angle on the problem is to be more aggressive about > > blocking email. Can we GPG sign email by default? > > I hope you weren't serious about GPG either. ;-) > > I suppose people can tolerate a wee bit o' garbage at the end of their > messages, if for whatever reason they don't have access to GPG (e.g. I > don't get this list in my GPG-capable MUA, but use the web interface > -- and don't particularly like FireGPG). But do you want people to > type a password on every send? No. The private key does not need to be password protected. > If not, aren't you kind of defeating the whole point of GPG, or am I > misunderstanding you? It's not a perfect strategy, I agree. However, I think it's better than nothing. The school server could be configured to bounce unsigned email or allow only certain whitelist signatures to pass through the mail server. If a kid really wants unrestricted email then Gmail exists. Email is great, but we need to protect kids until they are old enough to handle the responsibility. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
On Tue, Apr 29, 2008 at 02:15:54PM -0400, Paul Fox wrote: > michael wrote: > > Personally, I have found extensible autostart mechanisms which process > > third-party data to be more useful to trojan authors than to users so > > I'm mildly inclined to consider such mechanisms to be a misfeatures > > really? i'm not sure where the "third-party" data comes into it. i > suppose with browse, maybe, but my .xsession has started two xterms on > my desktop for many years, and i've never considered it a security > issue. just a time-saver. Depends. Any software you run can write to your .xsession, yes? Afterward, will you really notice an extra instance of 'bash', or 'kdmgd', or some other nonsense running in the background, capturing all your keystrokes, aliasing 'sudo', running 'xauth ++', setting up a spambot, or querying an IRC server for recent local root exploits? Actually, an even more compelling demonstration of the problem comes from the Windows world. Consider the Windows 'Start' directory, the Windows registry hives which list both autostarted "user programs" and "services", automatically loaded drivers, corruption of Word's normal.dot template, and Windows' tendency to automatically run software it that it locates on data CDs. I have seen every single one of these mechanisms used to cause substantial mischief. All of them amount to an automatic "run this software" API. Often, there are ways to have the software run silently, run in a fashion that users are unable to kill, run steganographically, etc. As I said - in my honest opinion, it's a misfeature rather than a feature. "Third party" comes into it because parsing untrusted data is such a dangerous operation, particularly when the parsers are written in a non-memory-safe language (as most of them are, "for performance"). For this reason, both the Journal and Telepathy really scare me because they run automatically and parse data from lots of third party sources. > > Also, where does hibernation fit in your taxonomy? > > i'd think that's pretty different -- coming out of hibernation > should leave the system exactly as it was when it went in. > (unless i'm misunderstanding.) You understood correctly. It has been previously proposed that we should (more or less) always hibernate. I was curious if you had thought about the resulting system. Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] DS possibilities
On Thu, Apr 24, 2008 at 1:36 AM, Martin Langhoff <[EMAIL PROTECTED]> wrote: > On Thu, Apr 24, 2008 at 7:42 AM, Benjamin M. Schwartz > <[EMAIL PROTECTED]> wrote: > > Reports from the field, especially from Carla and Bryan, have indicated > > that the datastore can get into a corrupted state from which it cannot > > recover. The corruption persists over a reboot. After corruption, > > Can we get copies of the corrupt DS files? You have one here: http://dev.laptop.org/ticket/6864 > As per the irc discussion today, I think we can > > - teach the DS backend how to recover gracefully if it finds a corrupt entry > - tweak the most vulnerable points of the DS code to be more atomic Agreed. My only doubt is if we should refactor or rewrite. One thing that I'd like to make clear is that I have never seen a corrupted Xapian index, nor have I heard of anything that points to this. The problems we have had with uninitializable datastores were due to trying to open an index with a too old release and with the 'config' file corrupted (http://dev.laptop.org/ticket/5494 and http://dev.laptop.org/ticket/6864). That file is not part of xapian but of the high-level python bindings (secore), and we are using a quite old copy of that. > A good trick is to start yanking the power (or kill-9'ing the DS > process) while something is being saved. > > Most of the times I've seen this kind of corruption, changing some > open calls to make a copy beforehand was enough. If one document is > lost due to powerloss, tough, the important thing is that on reboot > everything still works, even if we lost that document. > > > > subsequent datastore calls usually raise exceptions, which are not handled > > by the Activities (including the Journal) and so no Activities will load, > > and Sugar is unusable. > > Activities should handle errors returned by the DS :-/ those are > activity bugs. But we assume a generally working DS for a working > Sugar environment. Agreed. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
On Tue, Apr 29, 2008 at 2:17 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > On Tue, Apr 29, 2008 at 07:58:06PM +0200, Marco Pesenti Gritti wrote: > > On Tue, Apr 29, 2008 at 7:53 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > > > > In a perfect world, you would be right. But that doesn't seem to be > > > the world we are living in, because so many apps seem to need a banner > > > while they launch (openoffice, gimp, banshee, etc.). > > > > > > I'm not 100% sure that we need such a strong feedback during > > > launching, but just saying that we'll make everything fast enough and > > > slow activities won't bite us is a bit courageous, at least. > > While "perfect" may be the enemy of "good", I do not believe that the > present state of mediocrity is either inevitable or "good enough". > However, I'm not presently submitting patches, so what do I know? > > > > * It reinforces the zoom metaphor. > > Perhaps the implementation will convince me. Luckily for you, I'm not > the UI designer. :) =) > > * It deals with the problem of children clicking on 2-3 activities at > > the same time, which proved to be a real issue in the field (will > > faster activities address this? not sure). > > If you actually want to rate limit activity startup - why not just rate > limit activity startup, perhaps with a "cooldown" effect? So, I don't necessarily want to impose a hard rate limit. It may very well be the case that I know that I want Terminal and Chat open, pronto, and that they both launch fairly quickly for me even when launched at the same time. It might also be the case that I know I want 3 or four activities open for a project workflow (say, Record, VideoEdit, and AudioEdit (assuming they existed)), and I know they take a minute or so. I might want to launch them all and go get a cup of coffee. > Instead, if you want to make it clear that people should be using one > activity at a time, why not queue up launch requests and allow > cancellation of all items in the queue? This seems like a much more interesting option to me, if the predominant feedback from others opposes the launch mechanism I'm proposing. Perhaps this is even a wise thing to do regardless of which feedback mechanism we use. Focusing on the first activity launched before wasting time to launch a bunch in parallel might indeed be better. (Again, only truly better if we can prevent the remainder of the launching activities from stealing focus when they finish launching!) - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
On Tue, Apr 29, 2008 at 8:17 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > > * It deals with the problem of children clicking on 2-3 activities at > > the same time, which proved to be a real issue in the field (will > > faster activities address this? not sure). > > If you actually want to rate limit activity startup - why not just rate > limit activity startup, perhaps with a "cooldown" effect? Not sure what you mean with a cooldown effect... > Instead, if you want to make it clear that people should be using one > activity at a time, why not queue up launch requests and allow > cancellation of all items in the queue? No, that's not the point. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
tomeu wrote:
> On Tue, Apr 29, 2008 at 7:42 PM, Paul Fox <[EMAIL PROTECTED]> wrote:
> > in the "time i'd have otherwise wasted is free" department, is
> > there currently (or planned) a mechanism to always launch
> > designated activities (either fixed choices, or choices based on
> > recent journal entries) at startup? i.e., if i always want
...
> I don't think this feature is planned for any time soon, but you can
> easily hack the shell code for adding more activities to start:
>
> /usr/share/sugar/shell/view/Shell.py :
>
> if registry.get_activity('org.laptop.JournalActivity'):
> self.start_activity('org.laptop.JournalActivity')
thanks!
paul
=-
paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 45.0 degrees)
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
On Tue, Apr 29, 2008 at 07:58:06PM +0200, Marco Pesenti Gritti wrote: > On Tue, Apr 29, 2008 at 7:53 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > > In a perfect world, you would be right. But that doesn't seem to be > > the world we are living in, because so many apps seem to need a banner > > while they launch (openoffice, gimp, banshee, etc.). > > > > I'm not 100% sure that we need such a strong feedback during > > launching, but just saying that we'll make everything fast enough and > > slow activities won't bite us is a bit courageous, at least. While "perfect" may be the enemy of "good", I do not believe that the present state of mediocrity is either inevitable or "good enough". However, I'm not presently submitting patches, so what do I know? > * It reinforces the zoom metaphor. Perhaps the implementation will convince me. Luckily for you, I'm not the UI designer. :) > * It deals with the problem of children clicking on 2-3 activities at > the same time, which proved to be a real issue in the field (will > faster activities address this? not sure). If you actually want to rate limit activity startup - why not just rate limit activity startup, perhaps with a "cooldown" effect? Instead, if you want to make it clear that people should be using one activity at a time, why not queue up launch requests and allow cancellation of all items in the queue? > I'm still worried that the feedback might be too strong and > unfortunately it's something hard to test until we have activity > starting in 1.5 for real. If we had an acceptable form of feedback in > the current builds I'd propose to first make activities faster and > then play with feedback. Unfortunately, after the redesign, I don't > think that's the case. Write yourself a trivial activity that starts xterm and see how long it takes to run. (I used the gtk hello world entries, way back when.) Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
michael wrote: > On Tue, Apr 29, 2008 at 01:42:04PM -0400, Paul Fox wrote: > > in the "time i'd have otherwise wasted is free" department, is > > there currently (or planned) a mechanism to always launch > > designated activities (either fixed choices, or choices based on > > recent journal entries) at startup? > > Personally, I have found extensible autostart mechanisms which process > third-party data to be more useful to trojan authors than to users so > I'm mildly inclined to consider such mechanisms to be a misfeatures really? i'm not sure where the "third-party" data comes into it. i suppose with browse, maybe, but my .xsession has started two xterms on my desktop for many years, and i've never considered it a security issue. just a time-saver. > That being said, I'm quite interested in the tradeoff that you raise > between finishing boot quickly so that the user can start doing what > they want to do and extending boot with "expensive" precomputations so > that (on average), the user gets to perform individual actions more > quickly. the longer the boot time, the more it makes sense, because there's more chance that i'll be off getting coffee while it all happens, rather than waiting. (conversely, if boot time were very short, there would be little need for auto-start except as a convenience function, much like a function key is purely for convenience.) > > Also, where does hibernation fit in your taxonomy? i'd think that's pretty different -- coming out of hibernation should leave the system exactly as it was when it went in. (unless i'm misunderstanding.) paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 45.5 degrees) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
On Tue, Apr 29, 2008 at 7:42 PM, Paul Fox <[EMAIL PROTECTED]> wrote:
> tomeu wrote:
> > We cannot presume that _all_ activities will be able to put a window
> > in 0.1-0.5s, and probably don't want all the activity authors to
> > implement something like that.
> >
> > I see as a good thing to improve both feedback and launch performance.
>
>
> in the "time i'd have otherwise wasted is free" department, is
> there currently (or planned) a mechanism to always launch
> designated activities (either fixed choices, or choices based on
> recent journal entries) at startup? i.e., if i always want
> Terminal and/or Read running, then it would be good if their
> startup time simply added to the boot time, rather than being
> felt as an additional delay before i'm productive. i'm not a
> fan of "restore session" mechanisms -- i usually want to start
> from a known, fixed, state -- but it might similarly accomplish
> the goal of folding actiivity startup into boot time.
>
> (forgive me if this feature has been under my nose for some time
> without me noticing it.)
I don't think this feature is planned for any time soon, but you can
easily hack the shell code for adding more activities to start:
/usr/share/sugar/shell/view/Shell.py :
if registry.get_activity('org.laptop.JournalActivity'):
self.start_activity('org.laptop.JournalActivity')
Good luck,
Tomeu
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
On Tue, Apr 29, 2008 at 1:58 PM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > > On Tue, Apr 29, 2008 at 7:53 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > > On Tue, Apr 29, 2008 at 7:44 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > > > On Tue, Apr 29, 2008 at 07:26:12PM +0200, Tomeu Vizoso wrote: > > > > We cannot presume that _all_ activities will be able to put a window > > > > in 0.1-0.5s, > > > > > > I think we are better served by presuming that activities which fail to > > > start quickly are broken need to be fixed. For goodness' sake, we have > a > > > processor clocked at over 400 MHz that can play full-screen video. Does > > > someone here actually wish to argue that it's acceptable for process > > > creation, X connection setup, window creation, and painting to take > long > > > enough to require secondary feedback mechanisms? > > > > In a perfect world, you would be right. But that doesn't seem to be > > the world we are living in, because so many apps seem to need a banner > > while they launch (openoffice, gimp, banshee, etc.). > > > > I'm not 100% sure that we need such a strong feedback during > > launching, but just saying that we'll make everything fast enough and > > slow activities won't bite us is a bit courageous, at least. > > We should ban banners, really :) > > The two points that makes our feedback different from a banner are: > > * It reinforces the zoom metaphor. > * It deals with the problem of children clicking on 2-3 activities at > the same time, which proved to be a real issue in the field (will > faster activities address this? not sure). > > I'm still worried that the feedback might be too strong and > unfortunately it's something hard to test until we have activity > starting in 1.5 for real. If we had an acceptable form of feedback in > the current builds I'd propose to first make activities faster and > then play with feedback. Unfortunately, after the redesign, I don't > think that's the case. For what it's worth, a number of activities in the latest joyride appear to launch in a second or two at most when run in emulation. I've been testing them during the creation of the launcher feedback patch, and I still think the behavior is nice, myself. As mentioned, it would be even nicer if the activities painted in against white instead of gray, but overall the speed of the launch doesn't seem to detract from the feedback thus far. I encourage others to try out what I have working so far. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
On Tue, Apr 29, 2008 at 7:53 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > On Tue, Apr 29, 2008 at 7:44 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > > On Tue, Apr 29, 2008 at 07:26:12PM +0200, Tomeu Vizoso wrote: > > > We cannot presume that _all_ activities will be able to put a window > > > in 0.1-0.5s, > > > > I think we are better served by presuming that activities which fail to > > start quickly are broken need to be fixed. For goodness' sake, we have a > > processor clocked at over 400 MHz that can play full-screen video. Does > > someone here actually wish to argue that it's acceptable for process > > creation, X connection setup, window creation, and painting to take long > > enough to require secondary feedback mechanisms? > > In a perfect world, you would be right. But that doesn't seem to be > the world we are living in, because so many apps seem to need a banner > while they launch (openoffice, gimp, banshee, etc.). > > I'm not 100% sure that we need such a strong feedback during > launching, but just saying that we'll make everything fast enough and > slow activities won't bite us is a bit courageous, at least. We should ban banners, really :) The two points that makes our feedback different from a banner are: * It reinforces the zoom metaphor. * It deals with the problem of children clicking on 2-3 activities at the same time, which proved to be a real issue in the field (will faster activities address this? not sure). I'm still worried that the feedback might be too strong and unfortunately it's something hard to test until we have activity starting in 1.5 for real. If we had an acceptable form of feedback in the current builds I'd propose to first make activities faster and then play with feedback. Unfortunately, after the redesign, I don't think that's the case. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] replace/normalize some keyboard shortcuts
On Tue, Apr 29, 2008 at 1:54 PM, Martin Dengler <[EMAIL PROTECTED]> wrote: > On Tue, Apr 29, 2008 at 12:02:47PM -0400, Mikus Grinbergs wrote: > > Eben wrote: > > > I'm certainly all for removing alt-n and alt-p. We don't need > > > redundant shortcuts here, and alt-tab and alt-shift-tab will work fine > > > > I disagree with alt-n and alt-p not considered useful. Either can > > be done using TWO fingers. Needing three fingers for backwards-tab > > navigation is quite awkward for me. > > FWIW I agree with Eben/others that alt-n/p are too invasive (likely to > be used/desired by activity writers) and redundant to justify > overcoming the awkwardness that all the other major WMs have decided > isn't too much to force on users (the three fingered back-window > keyboard shortcut). > > > > [I don't actually care how you set the defaults -- I customize > > keyhandler.py on my XO for my own preferences anyway (and if that > > makes it more difficult for someone else to use my XO, I'd rather > > make things easier for me than avoid customization).] > > Can you suggest any ideas as to how we might be able to allow you to > do this more easily, without having to change keyhandler.py? The > naive, straw man would be a ~/.sugar/keybindingsrc (and corresponding > /etc/sugar-keybindingsrc) with ini file syntax... I'm interested in > making this customization easier. Well, we (will) always have the control panel for cases where we think there is specific need for this. We could either a) include a way to remap keys for specific areas such as The Frame, or Speech, by allowing one to set individual shortcuts in their respective modules. Or, we could add a new module specifically for Shortcuts, which lays out all of the system-level shortcuts and allows configuration in one place. As an added bonus, we could later make this interface pluggable so that activities could register a list of shortcuts and actions (note, there may be more actions than shortcuts!) so that kids can optimize their experience if they really want to. > > > In general, I would say that it's silly to use basic shortcuts for > > > actions that have a dedicated button on the XO (rotate, frame) > > > > Whenever I'm at home, I plug an USB keyboard into my XO. It is not > > silly for me to assign an unused F-key to 'frame' - again, that is > > something that makes using the XO easier for me. > > This is another good use case justifying customization. > > > mikus > > Martin > > > ___ > 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] perceived sugar performance
On Tue, Apr 29, 2008 at 01:42:04PM -0400, Paul Fox wrote: > in the "time i'd have otherwise wasted is free" department, is > there currently (or planned) a mechanism to always launch > designated activities (either fixed choices, or choices based on > recent journal entries) at startup? Personally, I have found extensible autostart mechanisms which process third-party data to be more useful to trojan authors than to users so I'm mildly inclined to consider such mechanisms to be a misfeatures rather than features. Based on this assessment, my direct answer to your question is simply "no, such a feature is not currently planned." That being said, I'm quite interested in the tradeoff that you raise between finishing boot quickly so that the user can start doing what they want to do and extending boot with "expensive" precomputations so that (on average), the user gets to perform individual actions more quickly. Also, where does hibernation fit in your taxonomy? Regards, Michael P.S. - Thanks for writing! ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] replace/normalize some keyboard shortcuts
On Tue, Apr 29, 2008 at 12:02:47PM -0400, Mikus Grinbergs wrote: > Eben wrote: > > I'm certainly all for removing alt-n and alt-p. We don't need > > redundant shortcuts here, and alt-tab and alt-shift-tab will work fine > > I disagree with alt-n and alt-p not considered useful. Either can > be done using TWO fingers. Needing three fingers for backwards-tab > navigation is quite awkward for me. FWIW I agree with Eben/others that alt-n/p are too invasive (likely to be used/desired by activity writers) and redundant to justify overcoming the awkwardness that all the other major WMs have decided isn't too much to force on users (the three fingered back-window keyboard shortcut). > [I don't actually care how you set the defaults -- I customize > keyhandler.py on my XO for my own preferences anyway (and if that > makes it more difficult for someone else to use my XO, I'd rather > make things easier for me than avoid customization).] Can you suggest any ideas as to how we might be able to allow you to do this more easily, without having to change keyhandler.py? The naive, straw man would be a ~/.sugar/keybindingsrc (and corresponding /etc/sugar-keybindingsrc) with ini file syntax... I'm interested in making this customization easier. > > In general, I would say that it's silly to use basic shortcuts for > > actions that have a dedicated button on the XO (rotate, frame) > > Whenever I'm at home, I plug an USB keyboard into my XO. It is not > silly for me to assign an unused F-key to 'frame' - again, that is > something that makes using the XO easier for me. This is another good use case justifying customization. > mikus Martin pgphvmHXwbkwR.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] fix #4646 - replace/normalize some keyboard shortcuts
On Tue, Apr 29, 2008 at 12:10:01PM -0400, Eben Eliason wrote: > In general, I would say that it's silly to use basic shortcuts for > actions that have a dedicated button on the XO (rotate, frame), which > means in general I approve of making alt-f and alt-r more "complex" > for emulator users. On the other hand, if we do have a goal of making > Sugar portable to other hardware, we can't make these assumptions as > easily. Is it possible to define the shortcuts in a dynamic way, > based upon some settings which determine what type of platform we are > running on/in? I had the same thought - I think we could do something to make it much easier for people to define new key -> action mappings. But one would need to have a good sense of the usual way(s) users / distros / customizers prefer to do this type of customization, which I don't have but plan to muck around with some thoughts and submit a future patch. This also led me to consider the idea of making it easier to define the actions themselves, so that we're not just allowing re-assignment, but new assignment. The implementation and considerations thereof are even more beyond the scope of what I had intended to achieve, though. > My only other comment applies to the comment itself, which I feel is > slightly presumptuous. I definitely intended no presumption. I have removed the comment in the upcoming version of the patch. > - Eben Martin pgp3rncl4NIAU.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
On Tue, Apr 29, 2008 at 7:44 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > On Tue, Apr 29, 2008 at 07:26:12PM +0200, Tomeu Vizoso wrote: > > We cannot presume that _all_ activities will be able to put a window > > in 0.1-0.5s, > > I think we are better served by presuming that activities which fail to > start quickly are broken need to be fixed. For goodness' sake, we have a > processor clocked at over 400 MHz that can play full-screen video. Does > someone here actually wish to argue that it's acceptable for process > creation, X connection setup, window creation, and painting to take long > enough to require secondary feedback mechanisms? In a perfect world, you would be right. But that doesn't seem to be the world we are living in, because so many apps seem to need a banner while they launch (openoffice, gimp, banshee, etc.). I'm not 100% sure that we need such a strong feedback during launching, but just saying that we'll make everything fast enough and slow activities won't bite us is a bit courageous, at least. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
Broken or not, they are going to be written. They are going to be written by teachers. They are going to be written by kids. Not everyone will write perfectly optimized code. And, regardless, I want this form of feedback. I don't care if it lasts 7/10 of a second. I think it will still serve as a valuable reinforcement of the UI paradigms, and a nice transition as the activity takes over the screen. - Eben On Tue, Apr 29, 2008 at 1:44 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > On Tue, Apr 29, 2008 at 07:26:12PM +0200, Tomeu Vizoso wrote: > > We cannot presume that _all_ activities will be able to put a window > > in 0.1-0.5s, > > I think we are better served by presuming that activities which fail to > start quickly are broken need to be fixed. For goodness' sake, we have a > processor clocked at over 400 MHz that can play full-screen video. Does > someone here actually wish to argue that it's acceptable for process > creation, X connection setup, window creation, and painting to take long > enough to require secondary feedback mechanisms? > > Regards, > > Michael > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
On Tue, Apr 29, 2008 at 07:26:12PM +0200, Tomeu Vizoso wrote: > We cannot presume that _all_ activities will be able to put a window > in 0.1-0.5s, I think we are better served by presuming that activities which fail to start quickly are broken need to be fixed. For goodness' sake, we have a processor clocked at over 400 MHz that can play full-screen video. Does someone here actually wish to argue that it's acceptable for process creation, X connection setup, window creation, and painting to take long enough to require secondary feedback mechanisms? Regards, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
tomeu wrote: > We cannot presume that _all_ activities will be able to put a window > in 0.1-0.5s, and probably don't want all the activity authors to > implement something like that. > > I see as a good thing to improve both feedback and launch performance. in the "time i'd have otherwise wasted is free" department, is there currently (or planned) a mechanism to always launch designated activities (either fixed choices, or choices based on recent journal entries) at startup? i.e., if i always want Terminal and/or Read running, then it would be good if their startup time simply added to the boot time, rather than being felt as an additional delay before i'm productive. i'm not a fan of "restore session" mechanisms -- i usually want to start from a known, fixed, state -- but it might similarly accomplish the goal of folding actiivity startup into boot time. (forgive me if this feature has been under my nose for some time without me noticing it.) paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 45.7 degrees) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] replace/normalize some keyboard shortcuts
On Tue, Apr 29, 2008 at 12:02 PM, Mikus Grinbergs <[EMAIL PROTECTED]> wrote: > Eben wrote: > > I'm certainly all for removing alt-n and alt-p. We don't need > > redundant shortcuts here, and alt-tab and alt-shift-tab will work fine > > I disagree with alt-n and alt-p not considered useful. Either can > be done using TWO fingers. Needing three fingers for backwards-tab > navigation is quite awkward for me. This is true. Though, I don't expect kids to have more than half a dozen or so activities running at once. Cycling around wouldn't be the end of the world. I think it's cleaner to retain the standard (alt-tab) approach. > BTW, the existing XO implementation is a non-standard ctl-alt-tab, > instead of alt-shift-tab. I commented on that in this thread...the patch this came in response to includes that change. > [I don't actually care how you set the defaults -- I customize > keyhandler.py on my XO for my own preferences anyway (and if that > makes it more difficult for someone else to use my XO, I'd rather > make things easier for me than avoid customization).] > > > > In general, I would say that it's silly to use basic shortcuts for > > actions that have a dedicated button on the XO (rotate, frame) > > Whenever I'm at home, I plug an USB keyboard into my XO. It is not > silly for me to assign an unused F-key to 'frame' - again, that is > something that makes using the XO easier for me. What I meant to say was that using a perfectly valid "primary" shortcut (such as ctrl-F or ctrl-R) seems like the wrong approach, since activities may very well want to use those. Reassigning to function keys seems like a perfectly valid solution for any hardware by the XO, which already has special meanings assigned to most of these keys. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
On Tue, Apr 29, 2008 at 7:31 PM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > > On Tue, Apr 29, 2008 at 7:26 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > > On Tue, Apr 29, 2008 at 7:01 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > > > > > > We have a completely different approach to activity launching in the > > > > works (I've been hacking it up myself...I need some help from the > pros > > > > to finish it!) > > > > > > Why are we building a splash screen instead of speeding up activity > > > launch? We know that programs can put up full-screen windows in > > > 0.1-0.5s. > > > > We cannot presume that _all_ activities will be able to put a window > > in 0.1-0.5s, and probably don't want all the activity authors to > > implement something like that. > > > > I see as a good thing to improve both feedback and launch performance. > > But if most of activities startup in ~ 1.5, switching context two > times during this period might be excessive. Might be, but I guess Eben doesn't want to switch context 2 times? I imagine his placeholder window as a transition from the shell to the activity window, right? Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
On Tue, Apr 29, 2008 at 7:26 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > On Tue, Apr 29, 2008 at 7:01 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > > > > We have a completely different approach to activity launching in the > > > works (I've been hacking it up myself...I need some help from the pros > > > to finish it!) > > > > Why are we building a splash screen instead of speeding up activity > > launch? We know that programs can put up full-screen windows in > > 0.1-0.5s. > > We cannot presume that _all_ activities will be able to put a window > in 0.1-0.5s, and probably don't want all the activity authors to > implement something like that. > > I see as a good thing to improve both feedback and launch performance. But if most of activities startup in ~ 1.5, switching context two times during this period might be excessive. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
On Tue, Apr 29, 2008 at 7:01 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > > We have a completely different approach to activity launching in the > > works (I've been hacking it up myself...I need some help from the pros > > to finish it!) > > Why are we building a splash screen instead of speeding up activity > launch? We know that programs can put up full-screen windows in > 0.1-0.5s. We cannot presume that _all_ activities will be able to put a window in 0.1-0.5s, and probably don't want all the activity authors to implement something like that. I see as a good thing to improve both feedback and launch performance. Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
On Tue, Apr 29, 2008 at 1:01 PM, Michael Stone <[EMAIL PROTECTED]> wrote:
> > We have a completely different approach to activity launching in the
> > works (I've been hacking it up myself...I need some help from the pros
> > to finish it!)
>
> Why are we building a splash screen instead of speeding up activity
> launch? We know that programs can put up full-screen windows in
> 0.1-0.5s.
We have considerably sped up activity launch, and we can do so
further. That certainly benefits us as well. Still, the launch
feedback needs to be immediate. I'd much rather have an immediate
result (the pulsing icon) visible for 3 or 4 seconds than a 2 or 3
second delay before I recognize that my action took effect.
Furthermore, this approach reinforces the zoom metaphor, which we've
been trying to find ways to improve as well. finally, it sets up
circumstances which could support the interactions mentioned below,
allowing one to work elsewhere in the edge cases where launching does
take considerable time. It think overall the new design will be much
more gratifying for kids when then click on an icon, and will go a
long way to preventing kids from simultaneously launching too many
activities, which is one of the biggest points of feedback from the
field.
> > Do to window manager limitations, it's non-trivial (as I understand
> > it) to prevent the system from automatically returning to the newly
> > launched activity when its ready.
>
> {{cite}}
I honestly have no idea on the technical details. Marco, can you
clarify the difficulties here?
>
> > Of course, the much desired interaction would be to allow the user to
> > go elsewhere, *not* automatically return them, thus pulling them out
> > of their working context, and instead show a standard notification to
> > indicate that the launch was successful.
>
> So why aren't we doing that?
Because of the difficulties implied above...if we can work those out,
we should be doing this.
- Eben
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] replace/normalize some keyboard shortcuts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mikus Grinbergs wrote: | Eben wrote: |> I'm certainly all for removing alt-n and alt-p. We don't need |> redundant shortcuts here, and alt-tab and alt-shift-tab will work fine | | I disagree with alt-n and alt-p not considered useful. Either can | be done using TWO fingers. Needing three fingers for backwards-tab | navigation is quite awkward for me. This is why I like Eben's suggestion of having F4 and Shift-F4 cycle activities. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIF1XwUJT6e6HFtqQRAi43AJ0UKVOOS4JLKOdI/c2Ak/eo+jDDWwCfYZ8k 9QwIY1TnEJdmW0qNphOufnI= =9rpA -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] On improving Sugar performance
> Catering for subjective human response is tricky, but once you've > passed some minimum threshold for utility** you can often win more > hearts and minds going for the subjective. A concrete example I'd > point to is smooth animation; activity switching with no nasty redraw > flicker; pulsing icons with no visible strobe; and frame/notification > transitions that glide smoothly onto the display giving the illusion > of effortlessness. Yes! This is exactly right. Perceived responsiveness is, in some cases, more important than actual speed. I think you've nailed the most crucial elements here, as well. The redraws are really ugly, the Frame is slow, pulsing is a bit better these days but not perfect, and the notifications should slide (and smoothly). Of course, we're limited in what we can do without compositing. I long for the day that gets turned on, if only to improve these points and nothing else. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] replace/normalize some keyboard shortcuts
Eben wrote: > I'm certainly all for removing alt-n and alt-p. We don't need > redundant shortcuts here, and alt-tab and alt-shift-tab will work fine I disagree with alt-n and alt-p not considered useful. Either can be done using TWO fingers. Needing three fingers for backwards-tab navigation is quite awkward for me. BTW, the existing XO implementation is a non-standard ctl-alt-tab, instead of alt-shift-tab. [I don't actually care how you set the defaults -- I customize keyhandler.py on my XO for my own preferences anyway (and if that makes it more difficult for someone else to use my XO, I'd rather make things easier for me than avoid customization).] > In general, I would say that it's silly to use basic shortcuts for > actions that have a dedicated button on the XO (rotate, frame) Whenever I'm at home, I plug an USB keyboard into my XO. It is not silly for me to assign an unused F-key to 'frame' - again, that is something that makes using the XO easier for me. mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
> We have a completely different approach to activity launching in the
> works (I've been hacking it up myself...I need some help from the pros
> to finish it!)
Why are we building a splash screen instead of speeding up activity
launch? We know that programs can put up full-screen windows in
0.1-0.5s.
> Do to window manager limitations, it's non-trivial (as I understand
> it) to prevent the system from automatically returning to the newly
> launched activity when its ready.
{{cite}}
> Of course, the much desired interaction would be to allow the user to
> go elsewhere, *not* automatically return them, thus pulling them out
> of their working context, and instead show a standard notification to
> indicate that the launch was successful.
So why aren't we doing that?
Thanks,
Michael
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] fix #4646 - replace/normalize some keyboard shortcuts
On Tue, Apr 29, 2008 at 12:50 PM, Benjamin M. Schwartz <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > Eben Eliason wrote: > | ALT - "alternate" shortucts...modifications of the corresponding > | primary shortcuts, eg. "copy and erase" (cut) > > | Of course, now that you point it out, I think that ctrl-esc might be > | the only global non-ALT shortcut. So if others argue strongly against > | using ctrl-esc, I'll leave it to a democratic decision. > > I think alt-esc might be better, for consistency. It's also entirely > consistent with your description above. Personally, I usually think of > "cut" as a strengthened, more dangerous form of copy. Similarly, alt-esc > (close this window) is a strengthened, more dangerous form of Esc, which > typically means something like "request politely to leave current action". Yup...makes sense. This is why I certainly don't feel the need to argue against it. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
Preface: I agree with all points below! On Mon, Apr 28, 2008 at 5:01 PM, Mikus Grinbergs <[EMAIL PROTECTED]> wrote: > I'm neither a child nor a teacher, so this opinion is personal : > > What you want to avoid is having the user decide "my intent has been > ignored", when in fact it is something "under the covers" that is > delaying the completion of his intent. > > The best way I can think of to avoid the user making a wrong > decision is to give him "feedback" whenever the XO enters a > condition perceived as "as yet, nothing seems to be happening". We have been lacking in feedback in many many places in the UI, mostly because it takes time -- more than we had up front -- to properly handle all of the cases and add the proper feedback. I hope we put a very large dent in this problem before the next release. > > > You are probably asking about situations where responsiveness is > expected in seconds (let educators determine how long a wait needs > to be to cross the threshold into "too long"). What I believe is > needed is showing "Yes, something *is* happening". Many operating > systems use the cursor appearance to tell the user "working on it". > [Eye candy might distract the user during unavoidable waits.] We do indeed have a busy cursor. I think we should make use of it more when it makes sense to do so. Right now, Browse is the only place I think I see it in use. > If confirmation takes "too long", the user might end up confused. > For example, I restarted an Activity from the Journal (no longer > remember which one); nothing seemed to be happening, so I used > alt-tab to switch to an existing Activity; a while later, while I > was viewing its screen, the XO suddenly transferred the display to > showing the screen of the new Activity, which had finally started. > [A change to supply an unmistakable confirmation of "Activity > starting" has been described -- I wish it were available now.] We have a completely different approach to activity launching in the works (I've been hacking it up myself...I need some help from the pros to finish it!) The new design will perform a quick (really quick) zoom-in effect into a white screen with a large pulsing activity icon in the center. It will be possible to switch away from this pseudo-activity view to do other things during launch. Do to window manager limitations, it's non-trivial (as I understand it) to prevent the system from automatically returning to the newly launched activity when its ready. Of course, the much desired interaction would be to allow the user to go elsewhere, *not* automatically return them, thus pulling them out of their working context, and instead show a standard notification to indicate that the launch was successful. > Harder to endure are the situations where it can take minutes to do > something. I am (and I expect others will be, as well) too > impatient to sit still and wait for these to complete - I'll switch > my attention to something else, and will need to be informed of what > became of the thing I was waiting for. [For example, I believe that > if connectivity to a server is lost -- recovery might be soon, but > also it might take more than five minutes.] I believe there should > be an ongoing indication (e.g., slow blinking of a front panel > light) that unambiguously shows the user "I'm slowly working on > this", with a specific how-it-concluded indication when this > "working" activity ends (e.g., light goes off for "connection given > up for good", or light goes steady for "connection properly > established"). Actually, I think this is how the new design is working in joyride now (it is, at least, how it's supposed to be). Martin D. has been working on refining the devices in the frame, and AP/Mesh devices are next on the list. Anytime an AP connection is in progress, it should be pulsing in the Neighborhood and in the Frame. Any time a connection state changes, a standard notification should appear to indicate this, including when connection is lost, or when a connection fails to be established. > [Shutdown is an example of where I feel the XO is a "drag" - it > takes me 40+ seconds. I don't know if "closing the lid" while the > screen is still lit will cause problems, or if before packing up the > XO I have to just sit and wait until the screen goes dark.] This is unfortunate. On the other hand, I don't expect it will happen *that* often, and even when it does, it's not really holding up all that much, right? I'd much sooner spend time making the boot process take 1/2 or 1/4 the time it does now instead. And even before that, I'd like to improve basic feedback and responsiveness in the rest of the UI! - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] fix #4646 - replace/normalize some keyboard shortcuts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote: | ALT - "alternate" shortucts...modifications of the corresponding | primary shortcuts, eg. "copy and erase" (cut) | Of course, now that you point it out, I think that ctrl-esc might be | the only global non-ALT shortcut. So if others argue strongly against | using ctrl-esc, I'll leave it to a democratic decision. I think alt-esc might be better, for consistency. It's also entirely consistent with your description above. Personally, I usually think of "cut" as a strengthened, more dangerous form of copy. Similarly, alt-esc (close this window) is a strengthened, more dangerous form of Esc, which typically means something like "request politely to leave current action". - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIF1HcUJT6e6HFtqQRAl2vAJ94bmTmEjMgutf0Mf5DXGaygPm31QCaA8ZW dv8v9C3MMbF6P8ymkjc8whA= =37Hn -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] fix #4646 - replace/normalize some keyboard shortcuts
On Tue, Apr 29, 2008 at 12:31 PM, Bert Freudenberg <[EMAIL PROTECTED]> wrote: > On 29.04.2008, at 18:10, Eben Eliason wrote: > > > Ctrl-Q is likewise redundant with the ctrl-esc shortcut, which is a > > mostly non-standard shortcut, but somehow makes sense in this context > > anyway. (Hey, it beats alt-F4, right?...there's no logic there that I > > can see) In other news, after looking it up, it turns out that > > ctrl-esc used to be used to reveal the task manager in Windows, > > allowing one to terminate running programs (semantically aligned with > > our use here). Oddly, it has since been remapped to invoke the > > Windows start menu, with opposite semantics. This despite the fact > > that many PC keyboards even have a Windows key which does this anyway. > > In any case, I support our interpretation of ctrl-esc and think it > > serves the purposes without need for redundancy. > > > I thought that all ctrl-modifiers should be handled by the activity? > Wouldn't alt-esc be more appropriate, since the handler is in the shell? Hmmm. The semantics I was aiming for are: CTRL - "primary" shortcuts...standard/basic actions eg. "copy" ALT - "alternate" shortucts...modifications of the corresponding primary shortcuts, eg. "copy and erase" (cut) SHIFT - "invert"...do the opposite of the primary or alternate shortcut it is chorded with, eg. "cycle through open activities in reverse" My goals for the semantics never specified that different keys should have different contexts or scopes. Of course, now that you point it out, I think that ctrl-esc might be the only global non-ALT shortcut. So if others argue strongly against using ctrl-esc, I'll leave it to a democratic decision. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] fix #4646 - replace/normalize some keyboard shortcuts
On 29.04.2008, at 18:10, Eben Eliason wrote: > Ctrl-Q is likewise redundant with the ctrl-esc shortcut, which is a > mostly non-standard shortcut, but somehow makes sense in this context > anyway. (Hey, it beats alt-F4, right?...there's no logic there that I > can see) In other news, after looking it up, it turns out that > ctrl-esc used to be used to reveal the task manager in Windows, > allowing one to terminate running programs (semantically aligned with > our use here). Oddly, it has since been remapped to invoke the > Windows start menu, with opposite semantics. This despite the fact > that many PC keyboards even have a Windows key which does this anyway. > In any case, I support our interpretation of ctrl-esc and think it > serves the purposes without need for redundancy. I thought that all ctrl-modifiers should be handled by the activity? Wouldn't alt-esc be more appropriate, since the handler is in the shell? - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] fix #4646 - replace/normalize some keyboard shortcuts
On Tue, Apr 29, 2008 at 6:10 PM, Eben Eliason <[EMAIL PROTECTED]> wrote: > On Tue, Apr 29, 2008 at 8:02 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > > Eben, Ben, are you ok with this? > > I'm certainly all for removing alt-n and alt-p. We don't need > redundant shortcuts here, and alt-tab and alt-shift-tab will work > fine. Also, I'm the one who mentioned that we should use > alt-shift-tab instead of ctrl-alt-tab for going backwards, to be > consistent with the modifier semantics we are aiming for, so I approve > of that change. Fine. > Ctrl-Q is likewise redundant with the ctrl-esc shortcut, which is a > mostly non-standard shortcut, but somehow makes sense in this context > anyway. (Hey, it beats alt-F4, right?...there's no logic there that I > can see) In other news, after looking it up, it turns out that > ctrl-esc used to be used to reveal the task manager in Windows, > allowing one to terminate running programs (semantically aligned with > our use here). Oddly, it has since been remapped to invoke the > Windows start menu, with opposite semantics. This despite the fact > that many PC keyboards even have a Windows key which does this anyway. > In any case, I support our interpretation of ctrl-esc and think it > serves the purposes without need for redundancy. Cool. > In general, I would say that it's silly to use basic shortcuts for > actions that have a dedicated button on the XO (rotate, frame), which > means in general I approve of making alt-f and alt-r more "complex" > for emulator users. On the other hand, if we do have a goal of making > Sugar portable to other hardware, we can't make these assumptions as > easily. Is it possible to define the shortcuts in a dynamic way, > based upon some settings which determine what type of platform we are > running on/in? I'm a bit worried by having different shortcuts depending on the machine. If we could find acceptable shortcuts for those (hopefully few) shortcuts that need to be global that were effective everywhere, that would be awesome. > My only other comment applies to the comment itself, which I feel is > slightly presumptuous. I would cut off the stuff after the comma, and > leave it at that. Who knows, maybe kids in the field will install > Fedora and emulate Sugar themselves! ;) Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] fix #4646 - replace/normalize some keyboard shortcuts
On Tue, Apr 29, 2008 at 8:02 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > Eben, Ben, are you ok with this? I'm certainly all for removing alt-n and alt-p. We don't need redundant shortcuts here, and alt-tab and alt-shift-tab will work fine. Also, I'm the one who mentioned that we should use alt-shift-tab instead of ctrl-alt-tab for going backwards, to be consistent with the modifier semantics we are aiming for, so I approve of that change. Ctrl-Q is likewise redundant with the ctrl-esc shortcut, which is a mostly non-standard shortcut, but somehow makes sense in this context anyway. (Hey, it beats alt-F4, right?...there's no logic there that I can see) In other news, after looking it up, it turns out that ctrl-esc used to be used to reveal the task manager in Windows, allowing one to terminate running programs (semantically aligned with our use here). Oddly, it has since been remapped to invoke the Windows start menu, with opposite semantics. This despite the fact that many PC keyboards even have a Windows key which does this anyway. In any case, I support our interpretation of ctrl-esc and think it serves the purposes without need for redundancy. In general, I would say that it's silly to use basic shortcuts for actions that have a dedicated button on the XO (rotate, frame), which means in general I approve of making alt-f and alt-r more "complex" for emulator users. On the other hand, if we do have a goal of making Sugar portable to other hardware, we can't make these assumptions as easily. Is it possible to define the shortcuts in a dynamic way, based upon some settings which determine what type of platform we are running on/in? My only other comment applies to the comment itself, which I feel is slightly presumptuous. I would cut off the stuff after the comma, and leave it at that. Who knows, maybe kids in the field will install Fedora and emulate Sugar themselves! - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] tweak battery charging (progress) bar
On Tue, Apr 29, 2008 at 5:50 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > > On Tue, Apr 29, 2008 at 5:46 PM, Eben Eliason <[EMAIL PROTECTED]> wrote: > > On Tue, Apr 29, 2008 at 8:56 AM, Martin Dengler > > > > <[EMAIL PROTECTED]> wrote: > > > On Tue, Apr 29, 2008 at 02:03:21PM +0200, Marco Pesenti Gritti wrote: > > > > On Tue, Apr 29, 2008 at 1:59 PM, Tomeu Vizoso <[EMAIL PROTECTED]> > wrote: > > > > > On Sat, Apr 26, 2008 at 2:17 AM, Martin Dengler > > > > > <[EMAIL PROTECTED]> wrote: > > > > > > +self.set_size_request(style.zoom(style.GRID_CELL_SIZE > * 4), -1) > > > > > > > > > > Sounds good to me, but I think Marco dislikes set_size_request. > > > > > > > > > > Marco, what do you think? > > > > > > > > I don't think we should set palette size to a fixed width. The whole > > > > gtk layout logic is dynamic, so that, for example, you can increase > > > > the font size without screwing up... > > > > > > There is indeed little point in having a nice auto-sizing GUI if code > > > is going to fix assumptions about sizes. > > > > > > In case you/anyone can think of something that might be acceptable, I > > > want to make the motivation clear: 1) many of the palettes in the > > > mockups at http://wiki.laptop.org/go/Designs/Frame seem to have a > > > fixed size; and 2) on IRC eben mentioned he liked the palettes a bit > > > wider (IIRC), and I, after trying it out on my XO, found the same. > > > > To make my goal clear: I have no intention of requiring all of the > > device palettes to be a fixed width. For that matter, I don't care to > > specify an absolute size for any of them individually. I do, however, > > want to ensure that the sliders and meters and such within them have > > enough horizontal space to accurately portray the info they contain. > > I think that the battery meter should be about twice as wide as it is > > currently. As such, there must be a way to tell it to be *at least* > > some width, since below that width it's less readable. This is not a > > fixed assumption. The palette can naturally expand as necessary to > > allow room for longer text, etc. > > Perhaps setting the request size of the progressbar may be better? That should be fine. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] tweak battery charging (progress) bar
On Tue, Apr 29, 2008 at 11:50 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > > On Tue, Apr 29, 2008 at 5:46 PM, Eben Eliason <[EMAIL PROTECTED]> wrote: > > On Tue, Apr 29, 2008 at 8:56 AM, Martin Dengler > > > > <[EMAIL PROTECTED]> wrote: > > > On Tue, Apr 29, 2008 at 02:03:21PM +0200, Marco Pesenti Gritti wrote: > > > > On Tue, Apr 29, 2008 at 1:59 PM, Tomeu Vizoso <[EMAIL PROTECTED]> > wrote: > > > > > On Sat, Apr 26, 2008 at 2:17 AM, Martin Dengler > > > > > <[EMAIL PROTECTED]> wrote: > > > > > > +self.set_size_request(style.zoom(style.GRID_CELL_SIZE > * 4), -1) > > > > > > > > > > Sounds good to me, but I think Marco dislikes set_size_request. > > > > > > > > > > Marco, what do you think? > > > > > > > > I don't think we should set palette size to a fixed width. The whole > > > > gtk layout logic is dynamic, so that, for example, you can increase > > > > the font size without screwing up... > > > > > > There is indeed little point in having a nice auto-sizing GUI if code > > > is going to fix assumptions about sizes. > > > > > > In case you/anyone can think of something that might be acceptable, I > > > want to make the motivation clear: 1) many of the palettes in the > > > mockups at http://wiki.laptop.org/go/Designs/Frame seem to have a > > > fixed size; and 2) on IRC eben mentioned he liked the palettes a bit > > > wider (IIRC), and I, after trying it out on my XO, found the same. > > > > To make my goal clear: I have no intention of requiring all of the > > device palettes to be a fixed width. For that matter, I don't care to > > specify an absolute size for any of them individually. I do, however, > > want to ensure that the sliders and meters and such within them have > > enough horizontal space to accurately portray the info they contain. > > I think that the battery meter should be about twice as wide as it is > > currently. As such, there must be a way to tell it to be *at least* > > some width, since below that width it's less readable. This is not a > > fixed assumption. The palette can naturally expand as necessary to > > allow room for longer text, etc. > > Perhaps setting the request size of the progressbar may be better? Ah, that's what I had thought was being done! In my head that's how it worked, but I failed to convey that to Martin and neglected to look at the patch. My fault. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] tweak battery charging (progress) bar
On Tue, Apr 29, 2008 at 5:46 PM, Eben Eliason <[EMAIL PROTECTED]> wrote: > On Tue, Apr 29, 2008 at 8:56 AM, Martin Dengler > > <[EMAIL PROTECTED]> wrote: > > On Tue, Apr 29, 2008 at 02:03:21PM +0200, Marco Pesenti Gritti wrote: > > > On Tue, Apr 29, 2008 at 1:59 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > > > > On Sat, Apr 26, 2008 at 2:17 AM, Martin Dengler > > > > <[EMAIL PROTECTED]> wrote: > > > > > +self.set_size_request(style.zoom(style.GRID_CELL_SIZE * > 4), -1) > > > > > > > > Sounds good to me, but I think Marco dislikes set_size_request. > > > > > > > > Marco, what do you think? > > > > > > I don't think we should set palette size to a fixed width. The whole > > > gtk layout logic is dynamic, so that, for example, you can increase > > > the font size without screwing up... > > > > There is indeed little point in having a nice auto-sizing GUI if code > > is going to fix assumptions about sizes. > > > > In case you/anyone can think of something that might be acceptable, I > > want to make the motivation clear: 1) many of the palettes in the > > mockups at http://wiki.laptop.org/go/Designs/Frame seem to have a > > fixed size; and 2) on IRC eben mentioned he liked the palettes a bit > > wider (IIRC), and I, after trying it out on my XO, found the same. > > To make my goal clear: I have no intention of requiring all of the > device palettes to be a fixed width. For that matter, I don't care to > specify an absolute size for any of them individually. I do, however, > want to ensure that the sliders and meters and such within them have > enough horizontal space to accurately portray the info they contain. > I think that the battery meter should be about twice as wide as it is > currently. As such, there must be a way to tell it to be *at least* > some width, since below that width it's less readable. This is not a > fixed assumption. The palette can naturally expand as necessary to > allow room for longer text, etc. Perhaps setting the request size of the progressbar may be better? Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] tweak battery charging (progress) bar
On Tue, Apr 29, 2008 at 8:56 AM, Martin Dengler <[EMAIL PROTECTED]> wrote: > On Tue, Apr 29, 2008 at 02:03:21PM +0200, Marco Pesenti Gritti wrote: > > On Tue, Apr 29, 2008 at 1:59 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > > > On Sat, Apr 26, 2008 at 2:17 AM, Martin Dengler > > > <[EMAIL PROTECTED]> wrote: > > > > +self.set_size_request(style.zoom(style.GRID_CELL_SIZE * 4), > -1) > > > > > > Sounds good to me, but I think Marco dislikes set_size_request. > > > > > > Marco, what do you think? > > > > I don't think we should set palette size to a fixed width. The whole > > gtk layout logic is dynamic, so that, for example, you can increase > > the font size without screwing up... > > There is indeed little point in having a nice auto-sizing GUI if code > is going to fix assumptions about sizes. > > In case you/anyone can think of something that might be acceptable, I > want to make the motivation clear: 1) many of the palettes in the > mockups at http://wiki.laptop.org/go/Designs/Frame seem to have a > fixed size; and 2) on IRC eben mentioned he liked the palettes a bit > wider (IIRC), and I, after trying it out on my XO, found the same. To make my goal clear: I have no intention of requiring all of the device palettes to be a fixed width. For that matter, I don't care to specify an absolute size for any of them individually. I do, however, want to ensure that the sliders and meters and such within them have enough horizontal space to accurately portray the info they contain. I think that the battery meter should be about twice as wide as it is currently. As such, there must be a way to tell it to be *at least* some width, since below that width it's less readable. This is not a fixed assumption. The palette can naturally expand as necessary to allow room for longer text, etc. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] xomail
On Mon, Apr 28, 2008 at 10:05 PM, Joshua N Pritikin <[EMAIL PROTECTED]> wrote: > I think a better angle on the problem is to be more aggressive about > blocking email. Can we GPG sign email by default? I hope you weren't serious about GPG either. ;-) I suppose people can tolerate a wee bit o' garbage at the end of their messages, if for whatever reason they don't have access to GPG (e.g. I don't get this list in my GPG-capable MUA, but use the web interface -- and don't particularly like FireGPG). But do you want people to type a password on every send? If not, aren't you kind of defeating the whole point of GPG, or am I misunderstanding you? -- Kevin Cole | Key ID: 0xE6F332C7 (GPG/PGP) Gallaudet University | WWW: http://gri.gallaudet.edu/~kjcole/ Hall Memorial Bldg S-419 | V/TTY: (202) 651-5135 Washington, D.C. 20002-3695 | FAX: (202) 651-5746 ". ! 1 |" -- Rene Magritte's computer ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] state of WebKit on the XO?
hello - I'm wondering if anyone has any information on current efforts to port WebKit to the XO. I found a couple google links [1], but not much recently. On IRC Shenki pointed me to an activity bundle [2], which didn't run on my sugar-jhbuild setup. Has anyone been working with WebKit or know of any current efforts? yours, Bobby Powers [1] http://www.j5live.com/?p=395 [2] http://dev.laptop.org/~danw/WebKit-1.xo ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] tweak battery charging (progress) bar
On Tue, Apr 29, 2008 at 02:03:21PM +0200, Marco Pesenti Gritti wrote: > On Tue, Apr 29, 2008 at 1:59 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > > On Sat, Apr 26, 2008 at 2:17 AM, Martin Dengler > > <[EMAIL PROTECTED]> wrote: > > > +self.set_size_request(style.zoom(style.GRID_CELL_SIZE * 4), -1) > > > > Sounds good to me, but I think Marco dislikes set_size_request. > > > > Marco, what do you think? > > I don't think we should set palette size to a fixed width. The whole > gtk layout logic is dynamic, so that, for example, you can increase > the font size without screwing up... There is indeed little point in having a nice auto-sizing GUI if code is going to fix assumptions about sizes. In case you/anyone can think of something that might be acceptable, I want to make the motivation clear: 1) many of the palettes in the mockups at http://wiki.laptop.org/go/Designs/Frame seem to have a fixed size; and 2) on IRC eben mentioned he liked the palettes a bit wider (IIRC), and I, after trying it out on my XO, found the same. > Marco pgpZ7TFonQnfx.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 Tue, Apr 29, 2008 at 2:36 PM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > On Tue, Apr 29, 2008 at 2:28 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > > The idea is that we have a complex system, and that value can be seen > > in having this system degrading gracefully when an unexpected error > > happens. > > I see that point. > > > > Even more when is an area where kids are supposed to play > > with (adding device icons to the shell). > > I'm not sure we can do this kind of assumption about what kids will play > with. Don't you think there are areas in the shell that are more likely to be customized? Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add speaker device and icon by default
On Tue, Apr 29, 2008 at 2:28 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > The idea is that we have a complex system, and that value can be seen > in having this system degrading gracefully when an unexpected error > happens. I see that point. > Even more when is an area where kids are supposed to play > with (adding device icons to the shell). I'm not sure we can do this kind of assumption about what kids will play with. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add speaker device and icon by default
The idea is that we have a complex system, and that value can be seen
in having this system degrading gracefully when an unexpected error
happens. Even more when is an area where kids are supposed to play
with (adding device icons to the shell).
Adding just one try..except block before gtk.main won't give us this
graceful degradation.
Tomeu
On Tue, Apr 29, 2008 at 2:24 PM, Marco Pesenti Gritti
<[EMAIL PROTECTED]> wrote:
> I'm not really sure about the value of this kind of try/except blocks.
> If the target is to avoid the shell exiting in any case, we could as
> well try/except the whole code executed before gtk.main().
>
> Marco
>
>
>
> On Tue, Apr 29, 2008 at 2:12 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, Apr 29, 2008 at 1:37 AM, Martin Dengler
> > <[EMAIL PROTECTED]> wrote:
> > > On Mon, Apr 28, 2008 at 06:12:31PM -0400, Michael Stone wrote:
> > > > On Mon, Apr 28, 2008 at 10:26:21PM +0100, Martin Dengler wrote:
> > > > > On Mon, Apr 28, 2008 at 01:08:04PM -0400, Michael Stone wrote:
> > > > > > Can calls to self._mixer or self._master fail even when these
> attributes
> > > > > > are not None?
> > > > >
> > > > > It doesn't appear a concern from the existing hardwaremanager.py
> code,
> > > > > and not in practice: I've tested checking/changing the volume in a
> few
> > > > > activities.
> > > >
> > > > I seem to recall having encountered situations where sugar startup
> would
> > > > fail (in early versions of the QEMU image, before sound began
> working)
> > > > as a result of unchecked use of sound hardware. I fixed the problem
> by
> > > > commenting out volume control in the sugar shell. It was a
> particularly
> > > > annoying problem because it was persistent, which meant that X
> entered
> > > > an infinite reboot loop.
> > >
> > > Yes, that problem exists and my patch is no worse in this respect - I
> > > meant to make both points very explicit later in the email to which
> > > you replied. Given the clear implication that we should do better,
> > > I'll change my patch.
> > >
> > > If you, or marco, or anyone has an opinion about where the best place
> > > to introduce the real paranoia, please let me know. OTTOMH, given we
> > > obviously want to make Sugar not crash and (secondarily) minimize
> > > spamming of 'try:...except's, hardwaremanager.py's where I would
> > > introduce the bulk of the changes (rather than make speaker.py,
> > > randomactivity.py,
> > > presence-palette-that-wants-to-make-a-dinging-noise.py, etc. do this).
> > >
> > > If anyone thinks that's controversial let me know.
> > >
> > >
> > > > > The original author of the hardwaremanager.py trusted the gst
> classes
> > > > > just as much as I am... also keep in mind that I actually saw and
> > > > > worked around two failures (#6933, #6934) of exactly these
> > > > > attributes/implementations,
> > > >
> > > > In your opinion, did the original author of hardwaremanager.py (or
> > > > authors of the clients of hardwaremanager.py?) exercise the degree of
> > > > caution necessary to deliver a solid, reliable Sugar experience to
> our
> > > > present audience? (I say "present" audience because I think that our
> > > > audience has changed from one which consisted primarily of
> developers to
> > > > one which consists primarily of semi-literate children.)
> > >
> > > As a rhetorical question I think I understand the point. As a
> > > non-rhetorical question, I'll decline to answer due to lack of
> > > context/familiarity with the conditions.
> > >
> > >
> > > > > > Also, what happens if an exception is thrown by, say,
> Device.__init__()?
> > > > >
> > > > > Given the current state of error checking, sugar (the shell) will
> fail
> > > > > to start and matchbox will exit (I saw this during testing, and
> just
> > > > > now tried 'raise Exception("we love m_stone")' to confirm.)
> > > >
> > > > Is the exception properly recorded?
> > >
> > > I'm sorry, I will have to research the proper way to record such an
> > > exception. I don't know.
> > >
> > >
> > > > Is it possible (easy?) to send the traceback upstream to us?
> > >
> > > Very interesting idea. Is there a plan for aggregating such data?
> > > cscott's FISL presenation had some (http-sourced?) usage graphs...is
> > > there a "Send Microsoft a Report"- (or "We Share Your Pain" :)) like
> > > server to which our code could send such reports? Do you want
> > > automated/staged trac submissions? The design/architecture/maintenance
> > > solution space is well beyond my time to explore. Lacking any leads
> > > therein I'm going to answer to your question as "I know not this
> > > 'upstream', would be happy to use one, but have no resources to build
> > > one".
> > >
> > >
> > > > > Device.__init__() is four lines
Re: [sugar] [PATCH] Add speaker device and icon by default
I'm not really sure about the value of this kind of try/except blocks.
If the target is to avoid the shell exiting in any case, we could as
well try/except the whole code executed before gtk.main().
Marco
On Tue, Apr 29, 2008 at 2:12 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote:
>
> On Tue, Apr 29, 2008 at 1:37 AM, Martin Dengler
> <[EMAIL PROTECTED]> wrote:
> > On Mon, Apr 28, 2008 at 06:12:31PM -0400, Michael Stone wrote:
> > > On Mon, Apr 28, 2008 at 10:26:21PM +0100, Martin Dengler wrote:
> > > > On Mon, Apr 28, 2008 at 01:08:04PM -0400, Michael Stone wrote:
> > > > > Can calls to self._mixer or self._master fail even when these
> attributes
> > > > > are not None?
> > > >
> > > > It doesn't appear a concern from the existing hardwaremanager.py code,
> > > > and not in practice: I've tested checking/changing the volume in a few
> > > > activities.
> > >
> > > I seem to recall having encountered situations where sugar startup would
> > > fail (in early versions of the QEMU image, before sound began working)
> > > as a result of unchecked use of sound hardware. I fixed the problem by
> > > commenting out volume control in the sugar shell. It was a particularly
> > > annoying problem because it was persistent, which meant that X entered
> > > an infinite reboot loop.
> >
> > Yes, that problem exists and my patch is no worse in this respect - I
> > meant to make both points very explicit later in the email to which
> > you replied. Given the clear implication that we should do better,
> > I'll change my patch.
> >
> > If you, or marco, or anyone has an opinion about where the best place
> > to introduce the real paranoia, please let me know. OTTOMH, given we
> > obviously want to make Sugar not crash and (secondarily) minimize
> > spamming of 'try:...except's, hardwaremanager.py's where I would
> > introduce the bulk of the changes (rather than make speaker.py,
> > randomactivity.py,
> > presence-palette-that-wants-to-make-a-dinging-noise.py, etc. do this).
> >
> > If anyone thinks that's controversial let me know.
> >
> >
> > > > The original author of the hardwaremanager.py trusted the gst classes
> > > > just as much as I am... also keep in mind that I actually saw and
> > > > worked around two failures (#6933, #6934) of exactly these
> > > > attributes/implementations,
> > >
> > > In your opinion, did the original author of hardwaremanager.py (or
> > > authors of the clients of hardwaremanager.py?) exercise the degree of
> > > caution necessary to deliver a solid, reliable Sugar experience to our
> > > present audience? (I say "present" audience because I think that our
> > > audience has changed from one which consisted primarily of developers to
> > > one which consists primarily of semi-literate children.)
> >
> > As a rhetorical question I think I understand the point. As a
> > non-rhetorical question, I'll decline to answer due to lack of
> > context/familiarity with the conditions.
> >
> >
> > > > > Also, what happens if an exception is thrown by, say,
> Device.__init__()?
> > > >
> > > > Given the current state of error checking, sugar (the shell) will fail
> > > > to start and matchbox will exit (I saw this during testing, and just
> > > > now tried 'raise Exception("we love m_stone")' to confirm.)
> > >
> > > Is the exception properly recorded?
> >
> > I'm sorry, I will have to research the proper way to record such an
> > exception. I don't know.
> >
> >
> > > Is it possible (easy?) to send the traceback upstream to us?
> >
> > Very interesting idea. Is there a plan for aggregating such data?
> > cscott's FISL presenation had some (http-sourced?) usage graphs...is
> > there a "Send Microsoft a Report"- (or "We Share Your Pain" :)) like
> > server to which our code could send such reports? Do you want
> > automated/staged trac submissions? The design/architecture/maintenance
> > solution space is well beyond my time to explore. Lacking any leads
> > therein I'm going to answer to your question as "I know not this
> > 'upstream', would be happy to use one, but have no resources to build
> > one".
> >
> >
> > > > Device.__init__() is four lines of code, and depends on
> > > > util.unique_id() and gobject.GObject.__init__().
> > >
> > > Device.__init__() sounds like the sort of thing that I expect will be
> > > overridden by subclasses in interesting ways and it sounds like the sort
> > > of thing that will break when people try to run Sugar on platforms we
> > > haven't tested pre-qualified.
> >
> > I think you're encouraging me to make Device.__init__() a bit safer,
> > or add some comments, or something similar, rather than changing
> > speaker.py's __init__(). It's going to get a bit hairy if we can't
> > trust our superclass(es)'s constructor(s). Or perhaps you'd have me
> > consider patching devices.py, to survive any of
Re: [sugar] [PATCH] Add speaker device and icon by default
On Tue, Apr 29, 2008 at 1:37 AM, Martin Dengler
<[EMAIL PROTECTED]> wrote:
> On Mon, Apr 28, 2008 at 06:12:31PM -0400, Michael Stone wrote:
> > On Mon, Apr 28, 2008 at 10:26:21PM +0100, Martin Dengler wrote:
> > > On Mon, Apr 28, 2008 at 01:08:04PM -0400, Michael Stone wrote:
> > > > Can calls to self._mixer or self._master fail even when these
> attributes
> > > > are not None?
> > >
> > > It doesn't appear a concern from the existing hardwaremanager.py code,
> > > and not in practice: I've tested checking/changing the volume in a few
> > > activities.
> >
> > I seem to recall having encountered situations where sugar startup would
> > fail (in early versions of the QEMU image, before sound began working)
> > as a result of unchecked use of sound hardware. I fixed the problem by
> > commenting out volume control in the sugar shell. It was a particularly
> > annoying problem because it was persistent, which meant that X entered
> > an infinite reboot loop.
>
> Yes, that problem exists and my patch is no worse in this respect - I
> meant to make both points very explicit later in the email to which
> you replied. Given the clear implication that we should do better,
> I'll change my patch.
>
> If you, or marco, or anyone has an opinion about where the best place
> to introduce the real paranoia, please let me know. OTTOMH, given we
> obviously want to make Sugar not crash and (secondarily) minimize
> spamming of 'try:...except's, hardwaremanager.py's where I would
> introduce the bulk of the changes (rather than make speaker.py,
> randomactivity.py,
> presence-palette-that-wants-to-make-a-dinging-noise.py, etc. do this).
>
> If anyone thinks that's controversial let me know.
>
>
> > > The original author of the hardwaremanager.py trusted the gst classes
> > > just as much as I am... also keep in mind that I actually saw and
> > > worked around two failures (#6933, #6934) of exactly these
> > > attributes/implementations,
> >
> > In your opinion, did the original author of hardwaremanager.py (or
> > authors of the clients of hardwaremanager.py?) exercise the degree of
> > caution necessary to deliver a solid, reliable Sugar experience to our
> > present audience? (I say "present" audience because I think that our
> > audience has changed from one which consisted primarily of developers to
> > one which consists primarily of semi-literate children.)
>
> As a rhetorical question I think I understand the point. As a
> non-rhetorical question, I'll decline to answer due to lack of
> context/familiarity with the conditions.
>
>
> > > > Also, what happens if an exception is thrown by, say,
> Device.__init__()?
> > >
> > > Given the current state of error checking, sugar (the shell) will fail
> > > to start and matchbox will exit (I saw this during testing, and just
> > > now tried 'raise Exception("we love m_stone")' to confirm.)
> >
> > Is the exception properly recorded?
>
> I'm sorry, I will have to research the proper way to record such an
> exception. I don't know.
>
>
> > Is it possible (easy?) to send the traceback upstream to us?
>
> Very interesting idea. Is there a plan for aggregating such data?
> cscott's FISL presenation had some (http-sourced?) usage graphs...is
> there a "Send Microsoft a Report"- (or "We Share Your Pain" :)) like
> server to which our code could send such reports? Do you want
> automated/staged trac submissions? The design/architecture/maintenance
> solution space is well beyond my time to explore. Lacking any leads
> therein I'm going to answer to your question as "I know not this
> 'upstream', would be happy to use one, but have no resources to build
> one".
>
>
> > > Device.__init__() is four lines of code, and depends on
> > > util.unique_id() and gobject.GObject.__init__().
> >
> > Device.__init__() sounds like the sort of thing that I expect will be
> > overridden by subclasses in interesting ways and it sounds like the sort
> > of thing that will break when people try to run Sugar on platforms we
> > haven't tested pre-qualified.
>
> I think you're encouraging me to make Device.__init__() a bit safer,
> or add some comments, or something similar, rather than changing
> speaker.py's __init__(). It's going to get a bit hairy if we can't
> trust our superclass(es)'s constructor(s). Or perhaps you'd have me
> consider patching devices.py, to survive any of its devices' not
> initializing.
>
> If you / anyone has a preference for either approach, or how I
> structure the changes into one or more patches (this is part of the
> culture that I haven't picked up yet), please let me know.
>
> Otherwise I will go forward with what you've said on the principle
> that you/others would rather slap my code back/down than micromanage
> me forward.
>
>
> > > and no other similar bit of code... does any more checking than this.
> >
> > Is this good? In particular, is it good that an exception that bu
Re: [sugar] [PATCH] Adjust system activities path
r+ On Mon, Apr 28, 2008 at 9:16 PM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > And the actual patch... > > Marco > > > > On Mon, Apr 28, 2008 at 9:12 PM, Marco Pesenti Gritti > <[EMAIL PROTECTED]> wrote: > > The new paths are: > > > > '@prefix@/share/sugar/activities:' \ > > '@prefix@/lib64/sugar/activities:' \ > > '@prefix@/lib/sugar/activities' > > > > This provides an home for arch specific activities. Also using > > "activities" for something sugar specific was a bad idea, so it's now > > "sugar/activities". > > > > Marco > > > > ___ > 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] tweak battery charging (progress) bar
On Tue, Apr 29, 2008 at 1:59 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > On Sat, Apr 26, 2008 at 2:17 AM, Martin Dengler > <[EMAIL PROTECTED]> wrote: > > +self.set_size_request(style.zoom(style.GRID_CELL_SIZE * 4), -1) > > Sounds good to me, but I think Marco dislikes set_size_request. > > Marco, what do you think? I don't think we should set palette size to a fixed width. The whole gtk layout logic is dynamic, so that, for example, you can increase the font size without screwing up... Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] fix #4646 - replace/normalize some keyboard shortcuts
Eben, Ben, are you ok with this?
On Sat, Apr 26, 2008 at 7:48 PM, Martin Dengler
<[EMAIL PROTECTED]> wrote:
> ---
> 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
>
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] tweak battery charging (progress) bar
On Sat, Apr 26, 2008 at 2:17 AM, Martin Dengler <[EMAIL PROTECTED]> wrote: > +self.set_size_request(style.zoom(style.GRID_CELL_SIZE * 4), -1) Sounds good to me, but I think Marco dislikes set_size_request. Marco, what do you think? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
I don't mean to discount personal experiences and anything we collectively do to improve the experience is a plus. But your two examples are a wonderful case in point. Resume from Journal is too slow and doesn't provide feedback and it does seem to deter use of the Journal as a way to revisit old work. (Also--being addressed in the refactoring of Sugar--is the current mismatch between how easy it is to launch a new instance than to resume an old instance.) On the other hand, I've never seen in the field any issue with how long it takes to shutdown the machine. It is annoying, yes, but it doesn't have much impact on how the kids use the laptops. But I look forward to more feedback and ideas from developers, teachers, and kids. thanks. -walter On Mon, Apr 28, 2008 at 5:01 PM, Mikus Grinbergs <[EMAIL PROTECTED]> wrote: > I'm neither a child nor a teacher, so this opinion is personal : > > What you want to avoid is having the user decide "my intent has been > ignored", when in fact it is something "under the covers" that is > delaying the completion of his intent. > > The best way I can think of to avoid the user making a wrong > decision is to give him "feedback" whenever the XO enters a > condition perceived as "as yet, nothing seems to be happening". > > > > You are probably asking about situations where responsiveness is > expected in seconds (let educators determine how long a wait needs > to be to cross the threshold into "too long"). What I believe is > needed is showing "Yes, something *is* happening". Many operating > systems use the cursor appearance to tell the user "working on it". > [Eye candy might distract the user during unavoidable waits.] > > If confirmation takes "too long", the user might end up confused. > For example, I restarted an Activity from the Journal (no longer > remember which one); nothing seemed to be happening, so I used > alt-tab to switch to an existing Activity; a while later, while I > was viewing its screen, the XO suddenly transferred the display to > showing the screen of the new Activity, which had finally started. > [A change to supply an unmistakable confirmation of "Activity > starting" has been described -- I wish it were available now.] > > > > Harder to endure are the situations where it can take minutes to do > something. I am (and I expect others will be, as well) too > impatient to sit still and wait for these to complete - I'll switch > my attention to something else, and will need to be informed of what > became of the thing I was waiting for. [For example, I believe that > if connectivity to a server is lost -- recovery might be soon, but > also it might take more than five minutes.] I believe there should > be an ongoing indication (e.g., slow blinking of a front panel > light) that unambiguously shows the user "I'm slowly working on > this", with a specific how-it-concluded indication when this > "working" activity ends (e.g., light goes off for "connection given > up for good", or light goes steady for "connection properly > established"). > > > [Shutdown is an example of where I feel the XO is a "drag" - it > takes me 40+ seconds. I don't know if "closing the lid" while the > screen is still lit will cause problems, or if before packing up the > XO I have to just sit and wait until the screen goes dark.] > > > mikus (running G1G1, not emulator) > > > > ___ > 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] On improving Sugar performance
On Mon, Apr 28, 2008 at 7:21 PM, Gary C Martin <[EMAIL PROTECTED]> wrote: > > Sure, but rather than a useful tool, I would call measuring as the > > only possible base on which decide actual work that needs to be done. > > We could be refactoring and recoding for years and don't get any > > noticeable improvement, if we don't measure. > > Not that I want to start a CS grad war here, but with more than one foot in > the UI camp, I just wanted to request that more than just 'clock watching' > is done when selecting/implementing optomisations – though 'clock watching' > is a very good place to start. > > http://www.codinghorror.com/blog/archives/001058.html > > Catering for subjective human response is tricky, but once you've passed > some minimum threshold for utility** you can often win more hearts and minds > going for the subjective. A concrete example I'd point to is smooth > animation; activity switching with no nasty redraw flicker; pulsing icons > with no visible strobe; and frame/notification transitions that glide > smoothly onto the display giving the illusion of effortlessness. I agree with this. We need to choose which code paths need to be optimized based on (subjective) user reports. But once we know there's a point where we are not giving enough feedback or where things just should be done faster, we should measure in order to set goals and choose the best approach. I don't think we have enough resources to rewrite things and find out later that we haven't improved user experience at all. > **how many hours must I have spent as a kid, excitedly waiting for some > software to load up off a magnetic tape, only to have it fail a fair portion > of the time and have to start the tape over again... and some folks here > moan about a ~6sec launch time for an activity. Though it's true to argue > that those old machines did have instant on, even if you were left to ponder > a BASIC prompt and spend the next 5min trying to tune your TV in to get a > clear signal :-) ;) Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] fix #6753 Activities should be able to specify "mime_types = */*"
On Tue, Apr 29, 2008 at 11:19:01AM +0200, Marco Pesenti Gritti wrote: > On Tue, Apr 29, 2008 at 1:36 AM, Martin Dengler > <[EMAIL PROTECTED]> wrote: > > Perhaps this patch got more attention than it needed, given the > > questions you raised. Besides the one to which I responded, I don't > > know the answers. I suspect that now might not be the optimal time to > > answer them. I'm quite happy for this tiny patch to languish / be > > discarded - the advantage of such a small patch is that it costs > > little to generate / discard, but if it gets in it's cheap. > > We have to be careful mainly because it's public ABI... Sure - I'm very very for that. Rather than me saying "ooh, good idea, let's do it dudez", I figured a patch would have a higher chance of being useful if people more familiar with the problem agreed. I really am happy to have it languish / be discarded; I'm not the expert, and it only took a few minutes. I'll update trac and we can get back to discussing more important issues ;). > Marco Martin pgp4SNJGnfTWM.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] fix #6753 Activities should be able to specify "mime_types = */*"
On Tue, Apr 29, 2008 at 1:36 AM, Martin Dengler <[EMAIL PROTECTED]> wrote: > Perhaps this patch got more attention than it needed, given the > questions you raised. Besides the one to which I responded, I don't > know the answers. I suspect that now might not be the optimal time to > answer them. I'm quite happy for this tiny patch to languish / be > discarded - the advantage of such a small patch is that it costs > little to generate / discard, but if it gets in it's cheap. We have to be careful mainly because it's public ABI... Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Status of Sugar in Ubuntu 8.04
>> > RE abiword: The packages that will become official are currently at > https://launchpad.net/~abiryan/+archive and will officially be at > https://launchpad.net/~abiword-stable/+archive where I have 2.6 packages > from Dapper through Gutsy too. I'd prefer not to have two different > versions floating around - if you could take a look at my packages and > see if they are missing anything for your use, that would be great, let > me know. (I've been told on IRC in #ubuntu-devel we should be able to > get it in for 8.04.1) I have commented on the abiword 2.6 tracker bug in Ubuntu earlier today asking about the python bingings. > > (I see you seem to only have lib-abiword packages - unfortunately I > don't have time right now to take a closer look.) You are right, I packaged only what I needed for sugar based on abiword 2.5.2 and later a svn snapshot. So the lib and the python binding. Not even the collab plugin is included but it is enough to use the write activity without collab and the MaMaMedia games. > > I would also like to take a look at your pyabiword packages in the next > month and see if we can get them standardized and such. thanks Jani ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Status of Sugar in Ubuntu 8.04
Jani Monoses wrote: > Hello, > > while some important activities are missing, Sugar can be installed and > used in Ubuntu 8.04 out of the official Universe repositories. It is a > very easy way of trying it out. > > The packages to install are sugar-emulator and sugar-activities. > > The latter is a metapackage depending on > > sugar-calculate-activity > sugar-chat-activity > sugar-connect-activity > sugar-logviewer-activity > sugar-memorize-activity > sugar-pippy-activity > sugar-terminal-activity > sugar-turtleart-activity > sugar-web-activity > > It can be started from the command prompt as sugar-emulator or from the > application menu item of the same description. There's also a GDM login > option for Sugar which will run it natively instead of in Xephyr. The > latter option I have not tested as much as the emulator. > > Abiword 2.6 did not make it in Ubuntu 8.04 but if you add the Sugar repo > for Hardy as described at > > https://launchpad.net/~sugar/+archive/ > > you can also install python-abiword and then sugar-write-activity, > sugar-jigsawpuzzle-activity and sugar-sliderpuzzle-activity from > Universe will work as well. > > Squeak in Ubuntu is not new enough and does not include the Etoys image > so that activity is missing too. > > The read activity does not work either - hopefully the Sugar specific > changes to Evince will be pushed upstream in this 2.23 GNOME cycle. > > Penguintv and TamTam are also notably missing, neither included license > texts in the tarballs at the time of packaging, and that prevents > uploading to Ubuntu - or any distro for that matter AFAIK. > > Paint and Record contain i386 specific shared objects so I wanted to > take the time and see how those are best installed without breaking > either Sugar's "one directory pe activity" or Debian's packaging > policy. > > It looks like plenty of things are missing, but it's ok for getting > started in learning or developing for Sugar and for interacting with > other Sugar installations on the Internet. > > Jani > > RE abiword: The packages that will become official are currently at https://launchpad.net/~abiryan/+archive and will officially be at https://launchpad.net/~abiword-stable/+archive where I have 2.6 packages from Dapper through Gutsy too. I'd prefer not to have two different versions floating around - if you could take a look at my packages and see if they are missing anything for your use, that would be great, let me know. (I've been told on IRC in #ubuntu-devel we should be able to get it in for 8.04.1) (I see you seem to only have lib-abiword packages - unfortunately I don't have time right now to take a closer look.) I would also like to take a look at your pyabiword packages in the next month and see if we can get them standardized and such. Thanks! Ryan -- Ryan Pavlik www.cleardefinition.com #282 + (442) - [X] A programmer started to cuss Because getting to sleep was a fuss As he lay there in bed Looping 'round in his head was: while(!asleep()) sheep++; ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
