Re: [sugar] XO identity shared via Browse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sebastian Silva wrote: Clearly, the provider should not be on the laptop. That would defeat the entire purpose of having an Identity Provider. You misunderstand our purpose. The immediate technical goal is to authenticate that a given connection goes to a particular XO. The machine itself then becomes the identifying token used to authenticate the identity of the user. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkk1tuEACgkQUJT6e6HFtqSraACghQTdVFQ393qfQtMmaunUNpW8 FR8AnRgqh871GjKC5SfTwVRXCzFMPXb1 =fLmO -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] XO identity shared via Browse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Langhoff wrote: - A backchannel call using SSH - A challenge-response call using the fact that the XS knows the public SSH key of the XO. You really like SSH! I'm less sure, though. I'd prefer a standard system. One interesting option is OpenID authentication over Jabber (standardized as XEP-0070), e.g. http://openid.xmpp.za.net/. In this system, OpenID authentication requests appear to the user as chat messages. This means that the Identity Provider can live on any jabber server with which the school server is federated. In fact, if we can accept standard chat invitations in the UI, we could simply federate the school server with xmpp.za.net and declare victory! Architecturally, this approach is appealing to me because Jabber IDs, not SSH pubkeys, are our principal identifiers. It also gives us the flexibility of putting the identity provider almost anywhere. If the XO runs its own jabber server, then the identity provider can live on the XO or any jabber server with which the XO is federated. An ideal form of this scheme would include creating an implementation of XEP-0070 (still standard-compliant) that sends the authentication approval request over XMPP in a machine-readable format, to be received by a consumer on the XO that approves or denies the request, possibly based on some interaction in a special-purpose GUI. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkk1xM8ACgkQUJT6e6HFtqQYOwCfX94DBVpPikPkvmDGkaXYezgV Ql0AoIg7iizkouSv7Ake6856qJT/GqRM =SJ0s -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] list of complaints from sugarcamp community building talk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary C Martin wrote: Just a nit pick, SciPy is much replaced by Numpy though SciPy still overlaps enough the documentation seems pretty useful. This is a typo. You mean that Numeric and Numarray are replaced by NumPy. SciPy is NumPy's sister project. NumPy provides fast array primitives for Python, and SciPy uses NumPy to implement a variety of high-level sci/math functions such as clustering, quadrature, maximum entropy methods, and signal processing. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkrTEIACgkQUJT6e6HFtqSLewCeKW4C92DSwpVDPjrTLfO6cWVM CWQAn1adMk0FP59jQf8Nq6U7bTl9WNvj =Js/Z -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Wrapping Sugar activities for other desktops
Marco Pesenti Gritti wrote: On Fri, Nov 7, 2008 at 2:21 PM, Martin Langhoff [EMAIL PROTECTED] wrote: Well, our journal use model says that the document is picked before the app is called, so if we support $ sugar-wrapper Write.xo mydocument.rtf then we're done. (Again, I might be extraordinarily naive about this :-) ). Currently activities uses the datastore dbus service to open/save files (ultimately they just open/save from disk, but there are some dbus calls to interact with the datastore), so it would mean to support two different code paths in the activities. For the simple case of launching an activity by resuming an instance from the Journal, I don't think that's true. The only case when things get tricky is when an activity uses the Object Selector. Even then, we could impersonate the datastore API, but replace the UI by the standard GTK filechooser. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Wrapping Sugar activities for other desktops
Marco Pesenti Gritti wrote: On Sat, Nov 8, 2008 at 6:45 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: Marco Pesenti Gritti wrote: On Fri, Nov 7, 2008 at 2:21 PM, Martin Langhoff [EMAIL PROTECTED] wrote: Well, our journal use model says that the document is picked before the app is called, so if we support $ sugar-wrapper Write.xo mydocument.rtf then we're done. (Again, I might be extraordinarily naive about this :-) ). Currently activities uses the datastore dbus service to open/save files (ultimately they just open/save from disk, but there are some dbus calls to interact with the datastore), so it would mean to support two different code paths in the activities. For the simple case of launching an activity by resuming an instance from the Journal, I don't think that's true. Can you elaborate? I'm probably missing something... In the resuming case currently a journal UID is passed to the activity, which gets the path to the corresponding file using the datastore dbus API. How do you propose to change that to work without a datastore/journal? There are two issues here: 1. I don't know how the inner workings are designed, but as a Python activity author I never have to write a datastore call. My impression is that the Journal asks Rainbow's launcher service to start the activity with a particular object-id. The launcher service starts the activity, loads the file from the Journal, and then calls the activity's read_file() method on the resulting filename. 2. I'm not suggesting that we work without a datastore/journal. I am suggesting that the sugar-wrapper will instantiate a D-Bus daemon that provides the datastore API. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Wrapping Sugar activities for other desktops
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marco Pesenti Gritti wrote: On Sat, Nov 8, 2008 at 10:56 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: There are two issues here: 1. I don't know how the inner workings are designed, but as a Python activity author I never have to write a datastore call. My impression is that the Journal asks Rainbow's launcher service to start the activity with a particular object-id. The launcher service starts the activity, loads the file from the Journal, and then calls the activity's read_file() method on the resulting filename. Yeah, the Activity class has high level read_file/write_file methods which could be probably replaced with a non-datastore implementation. But not all activities are using the high level API. 2. I'm not suggesting that we work without a datastore/journal. I am suggesting that the sugar-wrapper will instantiate a D-Bus daemon that provides the datastore API. Ok. But afaict that's not what Martin is proposing here. Using the datastore and providing a Journal view would be certainly the most straigth forward implementation, but the level of integration with the rest of desktop would be very low. Maybe it's fine until we get a POSIX compatible datastore though? Argh. We are speaking at cross purposes. My point is simply that we could create a very thin dummy layer that provides the launcher API and datastore API but implements them very simply. For example, the object selector would simply pop up the GTK filechooser pointed at $HOME, and the launcher would just provide the filename indicated by an argument to sugar-wrapper. This functionality is exactly what wrapper means to me. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkWDscACgkQUJT6e6HFtqROCgCfX+Cv5EGquwok1i31auJaGFI6 HoMAnin+B18fNMH4n+lph4nTlZIMw5oQ =7ipL -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Proper D-Bus usage (was Re: October 29 - Tarballs due for 0.83.1)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tomeu Vizoso wrote:
And see xattrs for a design that
avoids this mess.
xattr values are also just bytes with no type, and so will have exactly
the same problem. Their behavior would be equivalent to D-Bus's a{ayay}.
Python's behavior in this domain is also in flux. Python 3.0 will have
separate types for unicode strings and unencoded bytestrings.
- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkkLC60ACgkQUJT6e6HFtqSgwACdERgkXfq2kFuDiYufYdoQLCaP
rI8AmQGEQCDTop7U0D6bJHAoE66DA/xz
=1slO
-END PGP SIGNATURE-
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Data Storage and User-facing System Requirements [was Re: 9.1 Proposal: Files]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Garrison wrote: It seems from my reading of mailing lists, IRC logs, and listening to conversations with people that we are trying to resolve all of these issues by implementing more code to get around difficulties imposed by our current data storage implementation and security model. My argument is that we can do less work and get an improved result from the user's perspective by removing the layers of code (datastore and security restrictions) which prevent applications from behaving as they normally do on other systems. Erik: If you want applications to behave as they do on other systems, then why not just use an other system? I am not being facetious, and I hope I don't seem disrespectful. If you are not interested in Sugar's goal of rearchitecting the computer experience to optimize for our students, then don't use Sugar. It sounds to me like your goals would be achieved, for example, by running Andres's debxo-LXDE or the Fedora XO spin, perhaps with minor UI customizations. Sugar is not nearly finished, but it is headed for a realm of new features, including an entirely new metaphor for stored data. You seem to be proposing that we stop that development process because our current betas (Sugar is still in beta) are not up to the quality of mature systems. This upsets me. Please don't derail this train just because it has not yet reached its destination. If you would like to argue that OLPC should not be shipping Sugar, because it is not ready, then I am happy to listen. If you would like to argue that the datastore and Journal, once their implementation catches up with our designs for the future, will still be inferior to traditional filesystems for our target users, then that is an architectural discussion we can have, though you will meet a great deal of resistance. I think you should take a look at Ubuntu Netbook Remix. It's a very stable, simple platform that presents a classic Linux desktop environment in a UI optimized for small computers. You might find that you prefer it over Sugar. There's nothing wrong with that. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkKBlwACgkQUJT6e6HFtqQrBACdGR27QDeNyHkxYb58CsJjya4l gOQAni6nBGlJZ9E9/a0uqpatCaFV/cyE =O/tm -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] October 29 - Tarballs due for 0.83.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomeu Vizoso wrote: I have stopped work on the DS and Journal because OLPC is apparently funding the development of a replacement for them Really? We could easily hack the DS in 0.83 to return D-Bus strings for standard properties that are known (or rather, expected) to contain textual data, but introducing this inconsistency in the API may not be such a good idea. OK. What happens to Journal entries with non-Ascii titles? - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkIaqIACgkQUJT6e6HFtqRTnwCfbF/xMepr4GRsJdMvLKiHeBHG AtUAn3Rut7Sr+7e0a/RZaXcIvLbtMaqD =B9Dk -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 Proposal: Translation improvements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 C. Scott Ananian wrote: I expect Sayamindu can probably give a better talk than me on this. But I'm willing to give a short talk on translation things I'd like to see in 9.1: * multiple languages, multiple places: translation system should look in local, then activity, then system translation tables, then repeat for each in a set of fallback languages (eg, quechua, spanish, english) * separable translation packs * click-to-translate: wiki-like editing of translatable labels in the UI * Consideration of the security implications of separable translation packs. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj474gACgkQUJT6e6HFtqRx0ACdHb9CzPfi8h2z8tpsz2heHUPA YM8An3GzOGHhENLUi4OMbXDFD6CI0N/R =JOLC -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] MEETING with the Chandler Devs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As some of you may know, Chandler [1] is a project to build a PIM/Messaging/Calendaring application. After many years of development, the development team has released Chandler, now at version 1.0.2. Like Sugar, Chandler is a free software project, written in python and gtk (on linux), devoted to enabling collaborative effort over the network. Like Sugar, Chandler has had a few organizational hiccups along the way, including some controversial publicity [2], and is now trying to reduce its reliance on a single benefactor. The software designs created for Chandler and Sugar to manage data, especially chronologically ordered objects, have some striking similarities. Both Chandler and Sugar are currently undergoing design/architecture reviews. Chandler has the potential to provide Sugar with a collaborative calendar, e-mail, addressbook, etc., none of which we currently have. The Sugar developers have learned a great deal about collaborative network systems, and about engaging a larger community of developers. We have a lot to talk about, which is why THERE WILL BE A MEETING PLACE: #sugar-meeting on irc.freenode.net TIME: 2008 October 20, Monday 11 AM Pacific time (US) 2 PM Eastern time (US) 6 PM UTC Please suggest a better time if this time does not work for you. - --Ben [1] http://chandlerproject.org/ [2] http://www.amazon.com/Dreaming-Code-Programmers-Transcendent-Software/dp/1400082471/ref=sr_1_1?ie=UTF8s=booksqid=1224182864sr=8-1 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj3kCUACgkQUJT6e6HFtqQDxgCdGDzwn0QZxEJZMJ9BWlBrmi7e oY8AmwRkUswMjA2Fc4KW82FTwgmhcYdm =1m0m -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Datastore and Nautilus, an amusing ponder
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It seems to me that the points of controversy at Scott's datastore talk primarily concerned the way data is stored. In particular, the Journal requires the storage of a certain amount of metadata about each file, and the way we store this metadata constrains how we can store the data. The metadata we wish to store takes several forms, including a preview, a comment, and tags. As I thought about these properties I remembered that Nautilus has some curious little-known features, and so I fired up Nautilus and clicked Properties from the drop-down menu on the first file I found. Sure enough, Nautilus provides both tagging and commenting for every file on the system. The tags are called Emblems (or keywords in the code). They are unfortunately limited to a fixed set by the UI, though these helpfully come with distinctive icons. The comments are called Notes. Also, Nautilus keeps thumbnails according to the Thumbnail Managing Standard (http://jens.triq.net/thumbnail-spec/index.html). The metadata is stored in the ~/.nautilus/metafiles directory. That directory has one XML file for each subdirectory in which a file has been tagged. Each file contains a list of entries, and each entry encodes the complete metadata for one file. Also, thumbnails are stored in ~/.thumbnails by the MD5 hash of the filename. With the exception of versioning, it seems to me that the Journal could easily use Nautilus's storage system for Object metadata. This might be attractive to those who value the reuse of widely-used techniques. However, it is worth noting that Nautilus's Emblems and Notes are so little used that their wide deployment does not provide a strong guarantee about their robustness. Using ~/.nautilus/metafiles could potentially provide us with a very distinctive, if bizarre, advantage. When Nautilus moves a file from one directory to another, it preserves metadata. If the Datastore works by simply indexing the (recursive) contents of ~/Desktop according to the Nautilus metadata, then Nautilus and the Journal can happily coexist, looking at the same underlying filesystem. Users could spend most of their time in the Journal, but occasionally switch to Nautilus to make directory trees and move their files around within those trees. Unfortunately, I don't think this idea is actually workable. Most obviously, accessing the files using command-line tools will still result in a corrupted Datastore. For example, renaming a file using mv in the Terminal will result in Nautilus being unable to associate any metadata with it, which will cause the Journal to lose track of it entirely. The Journal could perhaps detect the presence of files that lack metadata and prompt the user to fix the metadata, but this seems pretty disgusting. The Journal permits duplicate names, and perhaps even empty names, but file systems do not. The Journal also carries mime type as explicit metadata, whereas Nautilus guesses it from the file's extension and contents. Thus, files created in the Journal would have to have their names munged in some way on disk. Present datastore designs solve this by using a cryptographic hash as the file name, but this would not be acceptable if users were expected to interact with the files directly. Munging filenames is not so hard, but recovering correctly when the user changes the name of a file to something which cannot be inverse-munged is an obvious tarpit. There are many other issues here, not least of which is the potential for unexpected behaviors in Nautilus to corrupt the Datastore for the Journal. ~ The gain, of being able to use Nautilus and the Journal but no other file management tools, is of questionable value. I'm really not sure why I wrote this e-mail. Maybe it's to say that even our easiest options for interoperability are actually quite complex, fragile, and dangerous. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj2ftAACgkQUJT6e6HFtqSGVQCfZ8NO4iXbbwE4QSxWEp8bDbHk g3wAn20KWTtCqU2Zx5EpESbfcZIu1EYi =cFHa -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Tagged Journal Proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote: | Proposal (off the cuff, please poke holes in this): We might beef up | the HIG in the area of tagging, and even suggest a set of canonical | tags for various types of content. (Localized, of course.) Combining | this with Scott's path-tags, we might introduce Images/, Videos/, | Documents/, and Audio/ tags in such a way that we get the best of both | worlds. The system can automatically file things away in a | reasonable subdirectory of the Journal, but the kids can always find | *anything* they've done, in chronological order, by looking in the | Journal itself (before selecting one of these path-tags as a query). Please don't conflate a good idea with a bad one. Activities providing localized metadata (both tags and key:value pairs) automatically could be a very good thing. Even better would be internationalization: if Activities use specific machine-readable words, then when objects are passed around, those words can be localized for each user's Journal. This is completely independent from the path tags, which would be useful only when trying to maintain compatibility with non-Journal filesystems, and are tremendously confusing otherwise. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj2iiwACgkQUJT6e6HFtqQRGACffQ6zRi3sOM+UdKztvR5+hG3l VgQAn2EBk+9Va0PV6utSykMKsh2j4LQG =6zjn -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Sugar Clock
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote: | On Mon, Oct 13, 2008 at 6:53 AM, Carlo Falciola [EMAIL PROTECTED] wrote: | Carlo : nowhere in the default GUI there is a clock, even if, in the control panel there is a panel to configure it. I think that personal watches are maybe not so easily owned by kids around the word, so a standard clock could be a little, but welcomed feature. (not talking about the clock activity that it is more a learn to read a clock thing than an everyday tool). any feedback and suggestion regarding how and where to put/show it are welcomed. | | I personally would like to see this built. I've always thought that a | clock device would fit perfectly into the bottom edge of the Frame. | I'd really like to see us rework the devices a bit so that they are | more naturally pluggable (at most, the user would only have to add | one directory at some location in the system to add a new device). In | the future perhaps we can extend this to a user-facing management of | installed devices. | | Apart from the trickiness (and potential CPU hit) of dynamically | updating the clock icon (I envision an analog clock here, with digital | display and date and/or calendar in the palette, so granularity would | be on the order of a minute or so). There are a few issues here: 1. The current Sugar icon system is problematic in general, and especially in this case. The Frame Device code does not allow arbitrary widgets. Instead, each device must specify a discrete group of SVG icons. The device may then select one of these icons to display. I tried to build a frame device clock, but gave up when I realized it would require generating hundreds of different icons. (The same problem affects the signal strength meter icons representing each network, which are naturally continuous, but are drawn by selecting one of about 10 different fixed icon shapes.) Fix: change the frame device system to allow arbitrary widgets, or at least arbitrary pixmaps. 2. The current power management system on XO provides no timed wakeups. Timed wakeups require significant work in both the kernel and EC. As far as I am aware, no one is actively working on this. Without timed wakeups, the system could easily suspend with the clock displayed, freezing the time and misleading users as to what time it is. Until we have timed (or periodic) wakeups, a clock cannot be part of the default view, because an incorrect clock is worse than none at all. Fix: Relegate the clock to an Activity, which can inhibit suspend when visible, to ensure that the clock updates appropriately. Work on EC-based timed wakeups. A good intermediate target might be to have the EC wake up the system every 60 seconds without hooking into the scheduler at all, so that any wakeups scheduled in the previous minute (e.g. from the presence service) can fire. 3. Analog clocks are deprecated. Outside of the West, clocks vary widely, and 12-hour mechanical circular dial clocks are by no means the norm. In Europe, 24-hour digital clocks are the most common type. Even in the US, children often have difficulty reading small analog clocks until late in middle school, because virtually all such clocks have been replaced by digital displays. The small XO screen will make an analog clock icon even less legible. Fix: Draw a digital clock to 1-minute precision using a simple GTK text display. Format the time according to strftime's %X or %c. (See http://docs.python.org/library/datetime.html#strftime-behavior) - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj02XYACgkQUJT6e6HFtqTaCQCgmdA0T0MQ851hTh/UkSwidthj 3X0AoI8hbXoACleQ9pUglXTFEZvhHC8N =dJni -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar Clock
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomeu Vizoso wrote: | Crazy idea: put in the frame a widget that only updates (and displays) | itself 20 seconds after the mouse has been over it. If it was an | analog clock, the arms could dissolve when it stops updating, if a | digital clock, it could display some text instead of the time. | Hopefully, the user would learn to hover it with the pointer when | wanted to see the current time. This could work, if the clock also inhibits suspend during that 20-second period. Another fix would be to inhibit suspend indefinitely whenever the clock (or the frame) is visible. We could even make the frame inhibit suspend for N seconds, and tell all volatile widgets (like the clock and network icons) to blank themselves before releasing the inhibition. This is a policy decision, and none of the options are very good until we have timed wakeups. - --Ben P.S. I think this is a good example of why contributing to Sugar is necessarily hard. Many small technical contributions from the community require significant policy decisions by the leaders. When Sugar's subsystems are as mature and rationalized as the kernel's, then perhaps we will be able to add small components without needing big decisions, but that point is still years away. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj08q0ACgkQUJT6e6HFtqSPKACfXlWjujv15ELoH9xcefQ69f0H YXYAnA54GVbNJ6v5PIJywMv2UGAvTxmz =w9q6 -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Mathematical Diversions 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomeu Vizoso wrote: | On Sun, Oct 5, 2008 at 3:51 AM, Benjamin M. Schwartz | [EMAIL PROTECTED] wrote: | I have written up an algorithm for quasi-optimal placement of items in the | Mesh View. ... | I am not sure whether this algorithm is of use for Sugar. | | To determine so, I'd make some questions: | | - how it compares with the existing implementation functionality-wise? New features: - - Allows each icon to specify a preferred location, and attempts to place each icon as near as possible to its preferred location (for consistent locations between laptops and over time). - - (optionally) Dynamically shrinks icons when there is no other way to prevent overlap* - - (therefore) Always finds a non-overlapping arrangement* Lost features: - - There are valid arrangements that this algorithm cannot produce. For a dense mesh view, its appearance may be somewhat different from the current algorithms. There are a number of tunable parameters and design choices that affect the appearance, but no tuning has been done. - - All icons are treated as circles, though it might be possible to have circles coexist with rectangles and even ellipses in the future. | - and performance-wise? Computing the positions and shrinkage for 50 shared activity rings, all large and overlapping, takes less than a second on my Thinkpad. It would probably take several seconds on an XO, but 50 shared activities is a very large number. I have made no attempt to increase speed, so some improvements may be possible. We can run this algorithm after the screen has been preliminarily updated to reflect a change, so that the computation time does not introduce any latency. | - which dependencies eliminates or brings? how heavy are them? It depends on the CVXOPT package, which weighs a bit over 2 MB. That's much bigger than I expected, and now I'm curious why it's so large. - --Ben *: These features are in new code, not yet posted. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjrhlQACgkQUJT6e6HFtqQawQCfUuhxcCiiwFdvZ3zBu93zM803 GuEAoJppKgxAq51t/vX7+JeHx+h/QrQf =CPGq -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Acoustic Measure problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 elana langer wrote: | a) In response to the question about the Mesh - there are a whole | bunch of issues that come up. -- to use acoustic measure only two | computers can be on at a time so it makes the tool almost impossible | to use in a class or workshop without explaining that the mesh is a | work in progress and doesn't work as well as it should. -- the | sharing/collaborating tool shuts down with too many computers on the | same channel at the same time. | | I'll check my bug reports/notes and look for the other specific | issues. Tyler might be able to fill y'all in on this issue. He was in | Mongolia with me and saw a lot of these issues first hand - maybe he | can chime in on a few details. I wrote the acoustic measuring activity, so I'm interested in exactly what kinds of problems you saw. I'd also like to know which version you are using. You're not the first person to report a problem using acoustic measure in a classroom with many XOs, but so far I haven't gotten enough information to figure out what is going on. If it's convenient for you, I'm happy to have this discussion here, or as a new ticket on dev.laptop.org. If we can find it, we can fix it. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjrvnAACgkQUJT6e6HFtqRAHACdHN3euZ7R87x0xg0xNKBLDvbm jDMAoJ3Z4RkBSC9BTAsYcGZYlrFICoQ+ =7PWF -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Narrative
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bryan Berry wrote: | There is something I would like to add. Folks from rich countries (like | myself) underestimate the importance of narratives b/c we are surrounded | by libraries, online tutorials in our native language, extensive | versions of wikipedia in our language, etc. There's a real drought of | narratives for poor countries. I don't know what you mean by narrative. If I were to pick a word to describe libraries, online tutorials, wikipedia, and other similar resources, I would choose information. I go to wikipedia to learn facts, not stories. I agree that providing information is good and important for education. I don't see how OLPC or Sugar lacks tools to provide information. Including a digital textbook into a Sugar build for XO is extremely easy. ~ We simply don't have the textbooks. The problem, in this case, seems much more like a lack of content and translators. That effort is important and worthwhile, but seems quite independent of Sugar. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjoXcEACgkQUJT6e6HFtqR3awCgg4lNrxa3nTDLVf1NIATAgwdF ymEAn1DJ7qaNwIHgirT32K00Gj2ufEKI =XKff -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Mathematical Diversions 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have written up an algorithm for quasi-optimal placement of items in the Mesh View. It involves linear algebra. I have actually implemented it, in less than 100 lines of python. It is described here: http://wiki.laptop.org/go/Circle_positioning_algorithm Implementation: http://dev.laptop.org/~bemasc/discus.py I am not sure whether this algorithm is of use for Sugar. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjoHY0ACgkQUJT6e6HFtqRm2gCfSoaGNTkWZFaTh7+avn+wC46o rzkAnA6V1P8Oypj1T7guJN2F154bRxWv =mrBS -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] adding versions to journal/datastore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I very much like Tomeu's version model, but I am also unsure whether I have interpreted it correctly. My feeling is that each object in the Journal is associated with a tree of versions. The tree has one node with no ancestors: the root node, which represents the initial version. The tree also has at one or more nodes with no children: these are the leaf or tip nodes, which represent the most recent versions. Resuming any version and editing it produces a new node whose ancestor is the node of the version that was resumed. An editing session that contains many incremental saves may produce a long chain of such nodes. ~From a user interface perspective, I think the idea is extremely simple. Each object is actually a leaf from the version tree, and the detail page of an object shows its predecessors. This does not conflict with the Actions view of the Journal or the Objects view. The history of an object is only visible in its detail page. Under normal circumstances, editing an object causes that object to move up toward the top of the Objects view, but does not cause any duplication. Keep also does not induce a duplication; it just ensures that a new leaf node is made for the current state. The only way to duplicate an Object is to explicitly resume an old version from the version history in the details view. When that resumed instance is saved, either automatically or through the Keep button, a new leaf node is created, and so a new entry appears in the Objects view. Adopting this idea would make the current Journal behave like the future-designs Objects view, with each object appearing only once, rather than once for every time it has been edited. We may then add a separate Action view to complete the future-Journal. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjj2qIACgkQUJT6e6HFtqRRIACdF+5ZOi/+qe6mPXCfS7OE3RYz 4GYAoJA3mpl+3HbKMi2fiUHRED1BWfEj =NZQm -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] U3 flash drives
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Walter Bender wrote: | Anyone know much about U3 flash drives? Would this be the simplest | (for the end user) way of booting a LiveUSB image of Sugar? (I worry | about asking people to change their BIOS to enable USB boot as being | too off-putting.) | | -walter | U3 is a Windows-only technology. I presume your question is: How can we create a usb key for Sugar that, when inserted into a Windows machine, launches a Sugar emulator with a minimum of user interaction? If so, I think the answer is to use the standard autorun.inf system: http://www.exponetic.com/blog/blog/2006/07/07/autorun-an-executable-from-a-usb-key-in-windows-xp/ This can be configured to launch an instance of Sugar in QEMU. It should work on any standard USB key, and does not require U3 at all. In fact, we should be able to produce a key with a single QEMU disk image and static QEMU binaries for Windows, Mac, and Linux. Such a key could be configured to autorun correctly on all major desktops. Even cooler would be to make this key bootable as well, for those who do have correctly configured boot from USB. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjhLRUACgkQUJT6e6HFtqRgkgCdHOMjXWpH2UPlva981TkIwGB+ ds4An1WpIYeYdzhBMFWVNyDQqUCBmJKU =8//d -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik Garrison wrote: | Hello all, | | On tabbing we are currently auto-toggling the frame. Are we sure that | this is necessary? Could we include a configuration option to change | this? | Another option, which I would prefer, is to show only the top bar of the frame. In general, when only one of the four sides of the frame is relevant, I think we should show only that side. Showing only the top bar should save something like 75% of the redraw CPU, while retaining the helpful display of available instances. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjaW6QACgkQUJT6e6HFtqQfDQCfWR7Y83T07PqYl+NritKeZIvL mgoAoIHZUNrngiqy7YgmFiFiK9c7dKDb =LUV/ -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Congrats to Telepathy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Congratulations are in order, I think, for the Telepathy developers. Gnome 2.24 was just released, and from http://library.gnome.org/misc/release-notes/2.24/ GNOME 2.24 announces the inclusion of an instant messaging client based off the Telepathy communications framework. Empathy also supports XMPP/SIP audio and video conferencing as available on the Nokia N800/N810 devices (video requires H.263 codecs for GStreamer to be installed). Empathy is a great companion to Ekiga, GNOME's audio/video SIP client (see Section 2.3 ― Ekiga 3.0). Telepathy provides a common framework for applications to access instant messaging functionality. It can utilise many common protocols including Jabber/XMPP, Google Talk, MSN Messenger and Apple's Bonjour/Rendezvous local network chat. Any application is able to utilise the instant messaging session. As well as the Empathy client, GNOME 2.24 provides libraries enabling developers to add presence and status information, transfer files or set up sockets (known as Tubes) for collaboration and games over the Internet. See Section 4.4 ― Instant Messaging Libraries for more information on how this technology can be utilised in your application. In other words, Telepathy is now a bona fide upstream project, and will likely soon have many more non-Sugar users than Sugar users. This is good news for us. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjax6wACgkQUJT6e6HFtqQWrgCfd+XMuimmRxI6G3et5qCPGRAH w9YAnRqTHrtqvb5bblSEuRA+enmjk15m =jxL1 -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] OOM and accidental activity launching
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Some people have mentioned that they would like to see bugs of general interest advertised on the mailing lists. As such, if you are interested in the subject line, you may enjoy a proposal at http://dev.laptop.org/ticket/8611 - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjY7KUACgkQUJT6e6HFtqRe8gCfQIdNu/l7SHUA8iBEOxRoI1Zt wN8An02qzrMXzmiifkhU8lsuXJVF0NEw =dM/5 -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] simple datastore replacement, take two
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomeu Vizoso wrote: | 2.- all metadata properties are just strings. I think this is a good decision (especially since by strings you mean byte arrays). However, it's not quite true. Your design actually has two classes of metadata properties: strings in metadata and files in extra_metadata. I like this design, but I think we can make it both simpler and more powerful. Consider, for example, using a single djb-style database. metadata/ author difficulty sessionkey preview Each item is stored in a file whose name is the key, and whose contents are the value. The Datastore can then provide two accessor functions: get_by_value(key) and get_by_reference(key). get_by_value() returns the contents of the file as a bytestring in memory. get_by_reference() returns the path to the metadata file, or another path linked (soft or hard) to that file. This provides all the needed functionality for large and small metadata entries. If the API requires file-like and string-like metadata to be completely distinct, for example to create a dict for the string-like metadata, then we can achieve this by using two such databases: string_metadata/ author difficulty file_metadata/ sessionkey preview I hope that these designs may allow your datastore to become even simpler. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjZPGkACgkQUJT6e6HFtqTepQCdEvOgcaFsvfmhEu0tk0q0in4A /qMAnin7C9wP/7avdyrtztd7sBXLGx8z =37uH -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Tagged Journal Proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 C. Scott Ananian wrote: | On Tue, Sep 23, 2008 at 2:13 PM, Benjamin M. Schwartz | [EMAIL PROTECTED] wrote: | -BEGIN PGP SIGNED MESSAGE- | Hash: SHA1 | | C. Scott Ananian wrote: | | A hand-drawn proposal for what a Journal supporting directory | | traversal as well as tag space exploration is in the attached PDF. | | Discussion welcome! | | Could you please point me to a description of the semantics for these | ordered tags? Since I do not know how the tags are meant to work, I | cannot provide any feedback on the UI. | | Previous discussion: | http://lists.laptop.org/pipermail/sugar/2008-September/008432.html | | Briefly: in addition to specifying multiple tags as a b c you can | also separate some of the tags with slashes, like a/b c. A search | for a/b only turns up entries tagged a/b not entries tagged b/a | or a b, although a search for a b turns up all of them. OK, so if I understand you correctly, you are not actually adding any semantics at all to the tags. What you are saying is that I can tag objects with arbitrary strings that may include the / character, and then filter objects by substring search on their tags. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjZWOsACgkQUJT6e6HFtqRBpgCfd+Gxdi1Jfmam1++tTZLtyiBP d60AniDjqESTQAMD3H+2/TYHYl36teI1 =WI64 -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Walter Bender wrote: | (I run SKYPE in Bert's X Activity | without a problem.) The principle goal of this discussion is to make the X Activity unnecessary by moving that functionality into Sugar's window management. Possible motivations for this include: more seamless integration with legacy apps, lower overhead when running legacy apps, easier installation of legacy apps. Personally, I have not used the X Activity, and so I don't actually know what its overheads are, how difficult it is to set up with a new application, or how well it integrates with Sugar (e.g. copy/paste, localization, theming). - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjWcE8ACgkQUJT6e6HFtqQ0BgCfU7jUQvLwJ1ZLM3QpM1T8aV3O buIAn2nkv5tIoqYuzsL3KSp+phgwE/1W =qs6X -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marco Pesenti Gritti wrote: | On Fri, Sep 19, 2008 at 12:13 AM, Benjamin M. Schwartz | [EMAIL PROTECTED] wrote: | Let's keep thinking about this. For example, I wonder what Metacity does | to a window that is both _NET_WM_STATE_FULLSCREEN and | _NET_WM_STATE_BELOW? Does it stack it below the Frame, if the Frame is | _NET_WM_TYPE_DOCK and _NET_WM_STATE_ABOVE? If not, could we convince the | Metacity developers that this is a good idea? | | I just thought of a worst problem with the FULLSCREEN approach. | FULLSCREEN windows are always on the top of NORMAL windows. Why is this a problem? When do we need an Activity to be visible, full-screen, and yet below a NORMAL window? - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjT7zMACgkQUJT6e6HFtqRNUgCeIEI1prZOLgGWycAdRcGCefq4 LUgAn0jMC1yiHd2LkOAhZ/iPYwoJHyi6 =IHRK -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We are talking about replacing Matchbox with Metacity in the XO build of Sugar. C. Scott Ananian wrote: | When I run | sugar under metacity, I don't *want* my activities to be full screen. I think you mean When I run Sugar inside a standard desktop environment on a computer with a large monitor... | Some of the links at the top of | http://wiki.laptop.org/go/9.1.0#Suggestions_from_User:CScott point to | window managers we could run on the XO to provide better support of | the 'each activity has a full screen' window management mode. That is the role for which we are discussing Metacity. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjT/m4ACgkQUJT6e6HFtqQ2dQCgmcNRf5982XIG3oIMEXaB4pG4 IrEAn3XbUFrVPOuMy0cJ13U7V6l2xvd5 =JLrm -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
Sayamindu Dasgupta wrote: The simplest way to do this is mentioned in the draft, namely, to have a new _NET_WM_WINDOW_TYPE hint, called _NET_WM_WINDOW_TYPE_NETBOOK_APP (feel free to suggest a better name :-P). I do not understand at all why _NET_WM_WINDOW_TYPE_FULLSCREEN is insufficient. For example, try (under Metacity) launching Firefox and then pressing F11 to go into Fullscreen mode. This results in a full-screen, undecorated window that seems to behave exactly as we desire full-screen Sugar apps to behave. Here is a quick experiment I did to compare Firefox when Maximized and Fullscreen. $ xprop /tmp/full.txt $ xprop /tmp/max.txt $ diff -u /tmp/max.txt /tmp/full.txt --- /tmp/max.txt2008-09-18 16:38:49.0 -0400 +++ /tmp/full.txt 2008-09-18 16:38:33.0 -0400 @@ -3,10 +3,10 @@ WM_STATE(WM_STATE): window state: Normal icon window: 0x0 -_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 25, 1 +_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 0, 0 _NET_WM_DESKTOP(CARDINAL) = 0 -_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW -_NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_HORZ, _NET_WM_STATE_MAXIMIZED_VERT +_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW +_NET_WM_STATE(ATOM) = _NET_WM_STATE_FULLSCREEN WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benjamin M. Schwartz wrote: | ... _NET_WM_WINDOW_TYPE_FULLSCREEN ... That should be _NET_WM_STATE_FULLSCREEN. Oops, Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjSvfMACgkQUJT6e6HFtqRgwQCfaOj++xeB6DNjk3raFu+ZIicp g/oAoImzaINzdSSsaVNtsTyQd1LQc6Yy =p/Mn -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marco Pesenti Gritti wrote: | However, though we do not always show frames (or panels), there are | some environments which show at least a single panel all the time (eg: | Ubuntu Netbook Remix). In those cases, fullscreen might mean that | frame may have to be covered as well. Who knows, maybe in the future | sugar may also decide to show a single frame permanently on the | screen. This is an interesting problem, but it is not relevant for Sugar at this time. I think a discussion with the Ubuntu developers would be wonderful, but since we do not have such a semi-permanent bar in Sugar, we can implement all our desired behaviors using simply the existing EWMH. | | I'm not even sure why it works with the current frame... The wm is | supposed fullscreen windows on the top of docks: | | http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#STACKINGORDER For usability/security reasons, the Frame must always be on top, regardless of what hints an Activity sets on its windows, so we cannot follow this recommended stacking order. The window manager will have to enforce the ordering, eventually in conjunction with a real X security framework. | Another point is that Sugar activities would have to be modified to | run correctly on a normal desktop (or we would have to come up with | some logic to set the fullscreen hint conditionally). Running Sugar Activities in a standard desktop environment is something that we have not discussed enough. It's important to remember that Activities (e.g. Write) require Sugar's UI to load files, save files, join shared instances, monitor current sharing partners, etc. Activities will never run on a bare desktop; they will always require a launcher shell, even if it is much less comprehensive than a full Sugar shell. This shell can also be responsible for setting window hints appropriately, or for providing Activities with enough information about the environment for them to set appropriate window hints. In summary, I believe we can safely move to a lightly patched Metacity while tagging our windows purely according to the EWMH. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjSyWYACgkQUJT6e6HFtqQSfgCfWR0riur6iMJiqxSkRmkY+mu8 3MAAn1iM/D2RX+aivuljZPLyqvFM8ytd =i782 -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marco Pesenti Gritti wrote: | On Thu, Sep 18, 2008 at 11:34 PM, Benjamin M. Schwartz | [EMAIL PROTECTED] wrote: | In summary, I believe we can safely move to a lightly patched Metacity | while tagging our windows purely according to the EWMH. | | That would mean to make Sugar impossible to use on a standard distribution. You mean because it would make Sugar depend on a nonstandard branch of Metacity? I can understand why distributions might be reluctant to carry such a thing. Let's keep thinking about this. For example, I wonder what Metacity does to a window that is both _NET_WM_STATE_FULLSCREEN and _NET_WM_STATE_BELOW? Does it stack it below the Frame, if the Frame is _NET_WM_TYPE_DOCK and _NET_WM_STATE_ABOVE? If not, could we convince the Metacity developers that this is a good idea? What about making Activities run as _NET_WM_TYPE_DESKTOP? How does Metacity handle multiple DESKTOP windows? (It probably isn't happy about them...) EWMH specifies a _NET_RESTACK_WINDOW message. Could Sugar, acting as a pager, send this message to Metacity at appropriate times to raise the Frame to the top, above FULLSCREEN windows? It may be that we can find a way to make this work under stock Metacity if we're creative. If not, Metacity is under very active development. Perhaps we can find a small change that resolves our problem and is satisfying to upstream Metacity. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjS0nwACgkQUJT6e6HFtqT9CQCgoNuyrq73SGUwzfvW/E2JHWhN 8sAAn1YDg6ro9fCc3W2E3OiyUXZ8rnYk =/BHQ -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Activities] Panorama activity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christoph Derndorfer wrote: | Sweet, I totally missed that! | | Is anyone actively working on integrating that functionality into 'record' | or making it available as a seperate activity? | | Christoph | See http://lists.laptop.org/pipermail/sugar/2008-February/004307.html The Panorama Activity is snot quite barely functional. It might be best to roll this functionality into Record, and Erik Blankinship has expressed some interest in that. However, Record's UI is very unusual, and I am not about to attempt integration with it myself. Also, as you can see in the examples, this process is only likely to work well once the camera's automatic white balance and gain control are deactivated. The only way I know how to do that is to run in Bayer mode. Bayer mode was introduced in a recent gstreamer, but gstreamer was recently downgraded, which leaves me without a known reliable way to access Bayer mode. - --Ben P.S. For Bayer mode info, see http://lists.laptop.org/pipermail/devel/2008-February/011029.html -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjBM3oACgkQUJT6e6HFtqRowgCfUlngIFr+Gl3jxKRYZAXBNl/x 2hEAnAnoDrrvcd+vIHO68aJthULDKAQC =cvG0 -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [OLPC Security] P_READ_LOGS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mikus Grinbergs wrote: | The easiest way to present logs, especially failure logs, is to make them | available through the standard Journal/Datastore interface. For example, | we have some agreement that when an Activity fails to launch, the failure | should appear as such in the Journal time-view, connected to an object | representing the log file for that failure. This log object has a text | type, and so can naturally be opened by any Activity that accepts this | type. No additional permissions are required. The user is responsible | for determining when to provide both sensitive data and P_NETWORK to the | same Activity. | | I find the Journal interface to be cumbersome. I also do not | believe the Journal ought to be cluttered up with footprints | a kid would probably not be able to do anything about. -1. I agree that the current Journal would be a poor place for log files. This proposal is in the context of http://wiki.laptop.org/go/Designs/Journal , the next-gen Journal UI, which provides a much more effective system for organizing information. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkigSCcACgkQUJT6e6HFtqTdLACeKPvOMhe40NZ7eU1LKC5Eu1A/ ghUAn2yjHmpvmFZTPL2RIRpTgbigGyos =40Pk -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [OLPC Security] P_READ_LOGS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jameson Chema Quinn wrote: | For when we actually have bitfrost permissions in the interface, I propose | another simple bitfrost permission: P_READ_LOGS. I agree that reading logs is a valuable capability for Sugar to provide. I don't see why any new Bitfrost permissions are required to enable it. The easiest way to present logs, especially failure logs, is to make them available through the standard Journal/Datastore interface. For example, we have some agreement that when an Activity fails to launch, the failure should appear as such in the Journal time-view, connected to an object representing the log file for that failure. This log object has a text type, and so can naturally be opened by any Activity that accepts this type. No additional permissions are required. The user is responsible for determining when to provide both sensitive data and P_NETWORK to the same Activity. Perhaps it would be helpful if you could give an example of a case in which a P_READ_LOGS permission is the best solution, and better than simply exposing the logs through the Journal. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkifqvEACgkQUJT6e6HFtqT6hACfc6zPgteAJRf1zFWD6WjGAQLc lREAn1Baic0HhwGDiOGLHB/diN5XLOh1 =Xpe7 -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] video bleeds through somewhat between sessions
Quoting Martin Langhoff [EMAIL PROTECTED]: There is probably a bug in the mplayer wrapper (are you using an mplayer 'activity' wrapper?) in that it's not getting rid of the overlay setup when it loses focus or is minimized. This is not a bug, at least in the case of losing focus. Color-keyed video acceleration is designed specifically for the case of playing video in a background window that is partially obscured by a window in front of it. This works correctly so long as the chosen key color isn't present in the foreground window, and so the favored key color is hot pink because it is so rarely used. The problem here appears to be that mplayer has chosen a key color that is a shade of gray. That's a poor choice, and arguably a bug. However, Mikus has a good point here. Insofar as XVideo's color keying is designed to overlap windows correctly with live video, it is unnecessary in our single-window UI. The GPU is doing a great deal of unnecessary work to blit a video that we already know to be completely occluded. Minimizing Activity windows might be a good way to start fixing this. We should also consider what happens when two running Activities both want to use XVideo. Can we multiplex access to XVideo, knowing that only one Activity is ever actually visible at a time? --Ben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] specifying what services Activities may use
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jerry Williams wrote: | Seems like this problem for linux was solved with RPM. | With rpm if something is missing for something you want to install, it | complains and won't let you install it. That's not really the problem we're discussing. We're talking about the case in which you try to install an old bundle onto a new build, or vice versa. RPM solves this problem by just not letting you do that. You can't install a rh9 RPM on FC8. I don't think many people around here would be happy to require all new .xo bundles for every release. I don't have a solution to suggest, but I don't think classic dependency management is going to do the trick. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiOdOEACgkQUJT6e6HFtqTGkwCfc1+dfhpyyBOeunbv0IWUeaaa GccAnRZGstdun3UbDMJ9INwCtfXYUt8T =TrAc -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Congratulations! but Sugar sucks
(Foreword: I originally intended to send this e-mail after the release of 8.2.0, but I have been convinced to send it earlier in order to prompt discussion) Dear OLPC developers, Congratulations on your work so far towards 8.2.0, with its new UI, new underpinnings, and thousands of individual improvements. It took years of effort to get this far, and a tremendous amount has been done to reinvent the entire notion of a software stack to better serve the educational needs of children. This release will be a triumph. Unfortunately, it is also an abysmal failure. There is hardly a worse operating environment available than Sugar as it currently stands. In addition to an amazing variety of terrible bugs, this failure is due to a handful of major missing features. I list here six major missing features, and what can be done about them to ensure a 9.1.0 that moves Sugar from mediocre to outstanding. 1. The datastore Sugar's design calls for a centralized rich data storage system, the datastore. The datastore provides secure, limited file access to Activities, manages file metadata, maintains a differentially compressed history of all work, ensures reliable backups to a trusted server, and mediates the connection to removable media. Every one of these features is crucial to Sugar's functioning, and almost none are really working at this time. We cannot afford another release based on the present datastore, as it fails to implement the features we require, and is unreliable even in the features it supposedly implements. Solution: There have, at this point, been at least five distinct proposals for a next-generation datastore design, all differing in underlying implementation and user-facing functionality. We need to have a Once And For All datastore summit, draw up a compromise datastore design, and implement it. We can do this by 9.1.0, if we are willing to make it a priority. 2. OS Updates We now have hundreds of thousands of laptops deployed in the field, running a variety of OS versions. OLPC cannot afford to support a multitude of decrepit versions, and children cannot afford to suffer defects that have long since been fixed. We need a reliable, fast, update system that does not rely on the network, so that children everywhere can move to the latest version of Sugar without losing their data. The update system must support tremendously invasive upgrades, like repartitioning the NAND and replacing JFFS2, because we expect to do this in short order. Solution: A secure usb autoreinstallation stick is required. It is not technically challenging to implement, but it must be made a priority, and then be made widely available and idiot-proof. 3. File Sharing Students and teachers have no good way to distribute files directly from one person's Journal to another. If all Activities that open a file do not implement Collaboration, then there is simply no way to transfer that file over the network. This is the most basic possible network functionality --- FTP was standardized in 1971 --- but it is completely missing from our system. Solution: A number of technical proof-of-concept programs have been written for distributing files, using methods like HTTP over stream tubes and Cerebro's Teleport. There is an excellent set of UI mockups for this functionality. All that is left is to Get It Done. 4. Activity Modification A keystone of the Sugar design has always been the user's ability to edit any Activity, and to cement this a View Source key was designed right into the hardware. This functionality is simply missing, and that prevents us from making our principal claim regarding an emphasis on user modification. Solution: Develop must be polished, finished, and included by default. This will require modifications to the core system, in order to support an endless variety of slightly modified Activities. It will also require work on the Develop program itself. If volunteer efforts are not moving fast enough, OLPC must ensure that someone is working on the problem as a professional. 5. Bitfrost Sugar, as it currently stands, is among the least secure operating systems ever, far less secure than any modern Linux or Windows OS. I can easily write an Activity that, when run by the user, escalates to root privileges and does anything I like with the system. Given Sugar's competitive status against Windows XO, this failing threatens the very existence of the project. The Sugar designs have long stated that safely running untrusted code from a classmate is a key goal for learning, but the current software accomplishes precisely the opposite. Solution: NO ONE IS WORKING ON BITFROST. That's right. Everyone who was working on Sugar security (after activation) has either left OLPC or moved into another role. Someone must be assigned to continue the security work, or it will certainly never make progress. Anyone who _does_ take on this challenge will start from a much better position than
Re: [sugar] Congratulations! but Sugar sucks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mikus Grinbergs wrote: | I'm not familiar with the details of the Rainbow implementation, but | I question this claim: | | Sugar, as it currently stands, is among the least secure operating systems | ever, far less secure than any modern Linux or Windows OS. I can easily | write an Activity that, when run by the user, escalates to root privileges | and does anything I like with the system. | | My understanding was that something called an 'Activity' would be | assigned its own userid-groupid. The standard Linux permissions | would prevent such an 'Activity' from messing up the system. The problem is the loophole'd activities: Journal and Terminal. These two activities run with the full privileges of the user. The identity of an activity is simply its D-Bus name. Therefore, if I write an Activity and set its D-Bus name to be org.laptop.TerminalActivity, it will run as user olpc, not as an isolated user. It will therefore have root access via passwordless su. This loophole was meant as a temporary workaround, to be replaced once Sugar acquired a secure mechanism for providing specific Activity bundles with elevated privileges. I'm merely suggesting that it is time to implement that mechanism. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiI3QEACgkQUJT6e6HFtqSOKQCcCwW0dNZ9nnrHgF/bzEuU0YPj wdUAn2Vnfx+RVw95W/fUXqtcQVF2aGSI =bs5K -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Congratulations! but Sugar sucks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bert Freudenberg wrote: | Am 24.07.2008 um 14:25 schrieb Benjamin M. Schwartz: | | 1. The datastore | 2. OS Updates | 3. File Sharing | 4. Activity Modification | 5. Bitfrost | 6. Power management | | Note that half of these items have nothing to do with Sugar, oo the | subject line is a bit misleading. Every one of them requires work on the Linux-based software stack that runs on the XO. The name of that stack is Sugar, as far as I'm aware. Perhaps a breakdown would be helpful: 1. The datastore: Glucose 2. OS Updates: Ribose. (Ribose is all the low-level software that keeps Sugar running on the XO) 3. File Sharing: Glucose 4. Activity Modification: Glucose and Fructose. 5. Bitfrost: Glucose and Ribose. 6. Power management: Glucose, Ribose, and EC. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiI+dwACgkQUJT6e6HFtqROZgCeLfWTvjKraknjHT9MkrkK2Dhe LcEAn2mHnSx0+2uvpEQpkCVOUCii/Zlx =rbFq -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Congratulations! but Sugar sucks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kimberley Quirk wrote: | I think many people will agree with much of what you have identified | in your rant; and we have been working on making the most progress we | can given the constraints of the 'real' world: Kim: Though I was obviously trying to be a bit provocative with my letter, I did not mean to imply a criticism of the work that has been done so far. ~ I have been very impressed with what you and the Sugar team have been able to accomplish, given the many constraints under which you have been operating. The point of my letter, ideally, is positive. Stated more formally, my thesis is: The list of missing features needed to make Sugar a first-rate system is really surprisingly short. Each item on the list has been debated to a stationary point over the last two years, so all that is left is to make a final decision for the engineers to execute. Each task could be completed or hugely improved by a single developer in a few months, provided that we do not allow changes to the requirements, and the developers are not asked to split their time and focus. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiJG8oACgkQUJT6e6HFtqQ3rACeIcRBMnaaCaLuFWjoDogq8PDx AGYAniKBirOfFkA7CycAmHg0ObPcX5OL =peKD -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity names vs. types
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Polychronis Ypodimatopoulos wrote: | At any rate, I will add (I filed a ticket) a sufficiently large (255 | chars?) name field for activities, although I would much prefer | designing this mechanism properly (any suggestions by Sugar(ed) | developers?). I last discussed this issue with you at http://wiki.laptop.org/go/On_Presence_updates/User_Profiles/Collaboration. ~ I didn't understand your perspective then, and I still don't understand it now. I don't know what you intend to achieve with Activity Type IDs, why they're so short, or how they will be exposed through Telepathy. However, I can ask a question: Why does the name field have to be some fixed size? Would it not be more efficient and flexible to use delimiters and let the size float? - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiJWckACgkQUJT6e6HFtqT6nwCfcSAHTKkrFOoSlBnX4wwTJsfY h1gAn0l19BcTCuLqKhjs2R6VYHqHiKUD =k+PK -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Remarks on the Work of Sugar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Stone wrote: | 5) Sugar is built on technologies that incentivize its developers to | recompute prior results which could be cached across boots. Sugar was intended to write to disk absolutely as little as possible, and also to reboot as infrequently as possible. I will attempt to find references to these intentions from years ago. Regarding the majority of your points, I would say: Sugar has been, and continues to be, in a constant rush just to implement the desired functionality, regardless of efficiency. The question has long been how can we code this as fast as possible, not what is the ideal way to implement this. I think that is a good thing. I think we will need retain this mindset through 9.1, in order to finally deliver a Sugar that has the features required for usability. I hope that Sugar developers can spend 2009 focusing on efficiency, laziness/memoization/eagerness, and delayering. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiGe9wACgkQUJT6e6HFtqRQlgCcD5u0UXpqr+tR5Yf7aeSFd6yy QHQAoJ72ZXy7+PCVF66av7BsMahd+VNz =IsWm -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Using threads in an Activity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Shikhar wrote: | What am I missing? Where's the code? The Distance activity uses threads, gtk, and dbus without any problem, so that may be a good reference code. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiCozMACgkQUJT6e6HFtqTGZwCfb0VFmJbJbKV/BNzCWcz/M9z9 yu0AniAIRZHqB/4YycDBq5yi0XRpcqsw =nEdg -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Design Question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg Smith wrote: | The new Home View in 8.2.0 will have three available styles. Really? The home view top bar will show three buttons, for three different views? This is news to me, though not bad news. | Vote for your favorite as default first exposure to OX Really? Here, on the mailing list? Ring. - --Ben (bemasc) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiBA9oACgkQUJT6e6HFtqQTYACeNdIOkQYlN9CJigniqhaD/MK1 6MMAn0CUMHX462MqC5ZiELZzXRF80sP8 =qqRn -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Programming environments on the XO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Ball wrote: | Another useful feature would be for | Write to have unique background colors for collaborators, as Gobby does. | I wonder if that would be a small enough task for someone to take on. See also #7447. Currently, Write doesn't support background colors at all. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkh/ZTUACgkQUJT6e6HFtqSdzwCfXnq/N5tEk/jhuBttxx77vauD wtkAnj4JzHOxwswpf/12WKnoPeKA4LBd =FTjC -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Programming environments on the XO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Sevior wrote: | Hi Folks, | Just so you know. The only reason for #7447 is because we | haven't put the UI in to enable it. I would like an additional control for background color. Eben, what do you think? | I'm not sure different colors for different users is such a good idea | though. The document will quickly become a mess. Though if the kids | want to do this they can. Have you used Gobby? It's the shared editor that people at OLPC _actually_ use, and having per-user background colors is among its key features. The colors are stripped for print; clearing the text colors in a Write document is similarly easy. Per-user coloring could work even better in Write, because text has a foreground and background color, and each user also has a foreground color and a background color that appear all over the UI. Those colors are guaranteed to have good contrast against each other, as required in the rest of the UI. Automatically setting the user's text to those settings in a shared Write session would make it instantly obvious who is typing what. I would most prefer a design in which the scheme is black on white by default. When the first user shares the document, the text entry colors are converted to her XO colors, but the existing text is not altered. As each user joins, that person's colors are set to their XO colors, but users may modify their color settings at any time after join+share. It occurs to me that this may work best if colors can be made more sticky, so that anything I type keeps my current colors, not the colors of the text I've selected or am typing into. This is a tricky UI question, which I will leave to the UI folks. Perhaps a sticky checkbox next to the color selectors that checks itself upon sharing? - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkh/9LYACgkQUJT6e6HFtqTiFQCgiwn7n2I5FT253t30YxDAN57M D2wAn0Qaw5gkl/4X/wOsQwYjZ13g/pXw =ovJY -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Langhoff wrote: | After | all, if an activity writer wants to use Klingon characters for | versioning, hey, let them go wild! This is actually the key point. Currently, the versioning system is embedded into the Glucose code itself, and our plans for handling multiple versions would require even more code to handle more complex versioning situations. I'd like to pose an alternative goal, inspired by your comment: Glucose should never attempt to parse version strings. I believe that we can accomplish this without sacrificing any of the user-facing behaviors that we truly desire. The choice of an appropriate versioning scheme may then be left to the author. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkh73RoACgkQUJT6e6HFtqR2TwCfZeK//hNeyD6XxFGD1NkrtcYL BMYAn0WolFwatGoVgtqwryGHV03WbaH6 =RNKc -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jameson Chema Quinn wrote: | It is desirable for Sugar to be able to compare versions and | guess which one is newer. Newer means more recent. If this capability is important to you, then we may simply include a datestamp in each bundle, separate from the version. However, I do not know of any planned Sugar feature that would require the ability to determine which bundle was created most recently. | If, as is the current plan, multiple versions of | an activity can coexist on an XO, it is reasonable to want sugar to present | these in some sane order, and possibly give hints and/or aid if the user | wants to update and/or garbage collect. Otherwise, we might as well just be | using activity hash, which can be calculated without being explicitly | included in activity.info. I favor including a version string with every bundle. I favor displaying this string in places where it is needed to disambiguate multiple versions of an Activity. I'm merely suggesting that the system not attempt to parse it. You mention ordering. The Journal designs have long called for all columns to be sorted, with the user selecting the order of sorting precedence. One intermediate position would be for the Version column to be sorted according to a best-effort ordering that attempts to do something sane when faced with any of the common version string conventions. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkh75ZgACgkQUJT6e6HFtqQePgCglNaySAW67tZIHgbYjIPDmqMt gKQAn2hV9jHTrZqPfGu7dHkx7KVlvi25 =1hsE -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote: | I guess the point here is that performing intelligent string comparisons on | several of these schemes requires parsing the string. ;) I would be happy to whip up a universal approximate ordering for version strings in a few lines of Python. My emphasis here is on _approximate_; nothing should depend on precisely correct interpretation of version strings. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkh7748ACgkQUJT6e6HFtqR+PACfa4VCNDYT7iqbDyq4ER7doTbU jCsAnAmR0TWlhah9sRG6YNx/ve9tqWT6 =CxR/ -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 C. Scott Ananian wrote: | On Tue, Jul 8, 2008 at 1:32 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: | We could add many more of the missing features to Browse if all the | developers weren't so busy with the rest of Sugar. Also, although most | of the sugar developers have occasionally hacked on Browse, we are far | from experts in the big piece of code that Mozilla is. | | This was my original point. We either have sufficient resources to | develop our own browser, or we don't. I think it will (in the end) be | more efficient to develop small Firefox extensions to support Journal | integration and collaboration, rather than taxing the sugar developers | with an attempt to (basically) reimplement large parts of firefox. I disagree. I expect that these two options will require a very similar amount of code... but one of them is already largely complete (if beta), while the other is hypothetical. Browse a custom UI on XULRunner, with brand-new code for sharing and datastore access. Moving that code into extensions doesn't reduce the amount of code. Neither of these scenarios is more our own browser than the other. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhzsIgACgkQUJT6e6HFtqRclQCfRSZXm2NgTztwVMnXMhcW4LEL CAEAoIj2t4FVX0PRqcjdAVm0PYLLHVl3 =crMM -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Journal able to use open with for activity bundles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a proposal for how to manage objects in the datastore, to resolve the various issues we have discussed. I call it the Objects and Translators model. The fundamental idea is this: the datastore is a flat, non-hierarchical listing of objects (versioned, but that does not come into play here). The datastore provides these objects for use by Activities. However, the datastore (or perhaps the Journal) also contains a new element: Translators. A Translator is a non-interactive object processing machine that takes an object as input and returns a set of objects as output. Each Translator has a specified set of input types on which it can act. The user, having selected a particular object, should be provided with a list of all compatible Translators. Clicking on a Translator should show the list of output objects that Translator would generate for this input object, and the user may repeat this process on each of those objects as well. This model allows us to reproduce the usual sorts of directory hierarchies, simply by using a group object (I think of it as a .tar file) and an untar Translator. To the user, this looks very much like a directory hierarchy. However, because each directory is in fact a first-class object, it can also be associated with Activity instances, or passed from one XO to another over the network, etc. The Translator system is appealing to me because it can provide far more than a simple storage hierarchy. For example, I have often had to extract a particular image from a PDF file, in order to include it in a class project. I, and most people, have done this by blowing up the image and performing Print Screen, or perhaps opening the PDF in the GIMP, which rasterizes it. However, there is a much better solution, provided by xpdf's command-line utils, which allows one to split a PDF into its component images and text, losslessly. Almost nobody uses these tools, because they are command-line only, and obscure. It would be trivial to wrap them up into a Translator, though, and then every PDF, in addition to showing options for viewing in Read, would show an option for splitting into it components, for further editing. Nothing could be more in keeping with our goal of creating an editable world. You can easily think of many other interesting Translators. For example, one could also provide a PDF-PNG rasterizer, a ODT-PDF renderer, or a Theora-JPG frames decompressor. The APIs should be designed so that Translators can be lazy, computing the contents of output objects only when necessary. Translators provide tremendously powerful object management, with a simple path to implementation. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhP8SkACgkQUJT6e6HFtqRQrACfcd5ntZ1ZXovZtTVI5k4LEG96 oDwAnjswhuiV1uKJ5cWhVV9N6uFNgT6E =x7ie -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Journal able to use open with for activity bundles
On Wed, 2008-06-11 at 12:11 -0400, Michael Stone wrote: On Wed, Jun 11, 2008 at 11:37:13AM -0400, Benjamin M. Schwartz wrote: Cute. Incidental thought: is performing a translation an action? Thank you. No, I don't see it as an action, especially because I imagine that the translation is performed lazily. Translators provide a menu of potential new objects, but an object is actually created only when some other action (like opening a frame of video in Paint, or sending it to a friend) demands it. Secondary thought: if translating is an action, then have we simply produced transient or instantaneous activities which have no GUI? I very much think of these as passive translators, in opposition to Activities. I imagine that they are non-interactive, and their nature is infrastructural, not creative. If an Activity is something fun and productive to do, a Translator is something so basic, like viewing the contents of a directory, that one does not even notice that one is doing it. Ultimately, the key difference between these forms of computation is how they are presented in the interface. To me, the interesting claim is that these transient activities (or translators, if you think they're different) should be able to advertise that they can turn types A into (potentially) B, C, and D.) I imagine translators as being integrated tightly into the Journal, rather than being independent programs. Also, I'm not sure that they need to advertise output types in advance. Instead, I think they should advertise input types, and when invoked, provide a list of potential output objects, including types. (If we expect the activities to be able to read the user's data in order to state make this determination, then we have even greater incentive to implement the Bitfrost P_DOCUMENT_RO and P_NETWORK protections - they seem to be ideally suited to this use case.) There is certainly a resemblance here. I imagined that translators would have no network access, and could only read the single object in question. They would not have write access until an output is requested, at which time they may write a single object to a particular location. However, for a first pass, I am not concerned about allowing untrusted, user-generated translators. I am happy to simply leave them as part of Glucose, running as trusted code. Once we have the next-gen datastore working, then we may worry about better exposing its parts. --Ben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Proposed Governance - was: (Re: [IAEP] Sugar Digest 2008-06-09)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Gettys wrote: | 3) The decision panel mechanism seems cumbersome, and fraught with | political danger; if people don't believe the oversight board is being | fair, they should get rid of the oversight board. There is the | (possible) issue of how to evaluate technical decisions in dispute if | the board ends up less technical than many projects (which might in fact | be the long term outcome we'd like to see in Sugar). | | Some mechanism that permits the board to delegate decision authority (or | solicit advice) may be useful. It might just be the same committee | mechanism, if committees are easy to establish/de-establish. | | In a (technical) meritocracy, often many of the people *best* able to | judge the technical merits of technical controversy end up serving on | the board, and I think it a mistake to forbid oversight board members | from serving on such committees. In short, while there may be | circumstances where such a panel is needed, I suspect as currently | proposed, the decision panel being enshrined in governance is a mistake; | and we can use the general committee mechanism to handle the cases where | it may be needed. As the instigator of this Decision Panel business, I should attempt to clarify the idea. My goal is to make serving on the Oversight Board as unappealing as possible. Ideally, it should be _difficult_ to find seven people willing to serve on the Oversight Board. As such, the document specifies that members of the Oversight Board _cannot_ decide controversial issues. It also specifies that members of the Oversight Board _must_ act as secretaries, taking minutes for every meeting of every committee. Oversight Board members are also prohibited from voting in any of the committee meetings, even though they must attend to take minutes (that's been part of the draft from the beginning). I hope this will be a very frustrating experience for members of the Oversight Board. I am a firm believer that the worst people to give power are those who want it. The Oversight Board, as described so far, has the responsibility of keeping Sugar Labs running smoothly, but almost no power to decide the interesting issues. This makes me very happy, as the Oversight Board is therefore most likely to attract people who are interested only in keeping Sugar Labs running, not pushing a particular personal agenda, even a technical agenda. My hope is that people will be elected based on a history of being calm, focused, personable, and reasonable, not on the basis of any platform (they don't have the power to execute it) or technical knowledge (they can't use it). I would much rather keep the technical experts _out_ of governance until a technical decision must be made that requires domain-specific expert knowledge. Most technical decisions should be made on the mailing lists anyway; only issues that must be decided in order for work to continue, and on which the community is otherwise deadlocked, should be escalated to a Decision Panel. I expect the Oversight Board to be concerned almost exclusively with the mundane details of managing finances and partnerships, making sure the communications channels are open, etc. I do not want the Oversight Board to be a Court of Last Resort. I still favor the presence of the Decision Panels section in the draft, but that's not surprising. I see it as an easy lightweight system for moving political issues away from the Oversight Board. I welcome other perspectives. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhNTY0ACgkQUJT6e6HFtqRf/wCfbxVOReVm1u0PKZOdPc6ClgBu 4ukAoIRfEGck6TBcIy8hOYzkv/DiVsn9 =1hDU -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Idea: Aerial photographs of all villages where XO's are deployed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wade Brainerd wrote: | Too bad the new Google Earth API is much too high level for these purposes, | it would be great if Google would open up the data. Check out openaerialmap.org It's fantastic. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhJe5sACgkQUJT6e6HFtqSh6wCdGpj7VD3PtfQMCHuzNBmKrxU+ Vj8AnjFjt8mcdm3vZfO9JETZAi4FJ7w1 =Jd4L -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Experiments with Metacity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sayamindu Dasgupta wrote: | Hi, | | On Mon, May 19, 2008 at 5:14 PM, Marco Pesenti Gritti | [EMAIL PROTECTED] wrote: | On Mon, May 19, 2008 at 11:41 AM, Marco Pesenti Gritti | [EMAIL PROTECTED] wrote: | Maximize + undecorated might work. It has to be done by each activity. | We could add an option to make metacity show *no* decoration for | maximized windows. As long as we have a Close menu on the frame that | should be desired also for desktop applications. | | Ideally we could figure out a way to make metacity maximize activity | windows by default, but I can't think of a clean way to do it. One | problem with doing the maximize in the activity is that it would still | do so when running on a normal desktop. | | | I tried the alternative of modifying metacity instead of playing | around with the activities. | My plan is to make metacity behave a little differently (ie: maximize | and undecorate any window with the hint GDK_WINDOW_TYPE_HINT_NORMAL, | as suggested by Marco in | http://wiki.sugarlabs.org/go/WindowManagement) when it runs inside | Sugar. For this, I think a possible way forward is to have | olpc-session export a environment variable SUGAR_SESSION_RUNNING=1, | which would be checked by metacity before it goes into the sugary | mode [1]. Does this sound sane ? No. Why not just have activities run with _NET_WM_STATE_ = _NET_WM_STATE_FULLSCREEN in their EWMH X properties? There is no need to modify Metacity. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhEDBkACgkQUJT6e6HFtqTzaACeNOMw0xhBDGgRQ4s3NpzPbs27 YnUAn0ldWN2InfL0lmdX6JhGe9bWZZE0 =KXs8 -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Capturing all mouse events
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Dengler wrote: | On Fri, May 30, 2008 at 09:38:39PM -0400, Benjamin M. Schwartz wrote: | | Does anyone know how to capture all mouse events? | | In trying to do this with pygtk, we both have run into gtk bug | #156948[1] - for the record/to close the loop, we tried calling | add_filter() on gtk.gdk.get_default_root_window()'s returned | gtk.gdk.Window. This should, in theory, give us all events[2]. But the | bug prevents the information from being useful, and it's not clear | that we're really getting all events[3]. I've been trying to use the RECORD extension, which provides access to ALL input events in a simple way. Unfortunately, I can't seem to load the RECORD extension. I have added the line Load record to my xorg.conf, and my Xorg.0.log now shows a line (II) Loading extension RECORD but xdpyinfo doesn't show RECORD in its list of loaded extensions. Why won't Record load? - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhDR2wACgkQUJT6e6HFtqRGGgCfUCz/95yQa2/AwLAe5d3b2oYh W0YAnAj6pO/BpuXtMJzfL2DhkWvyB5Yy =7Uae -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Cursor modifications
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Dengler wrote: | On Thu, May 29, 2008 at 04:53:03PM -0400, Benjamin M. Schwartz wrote: | I do not know anywhere near enough about X to make this happen. I hope | you will respond with advice about what to do, or perhaps volunteer if you | understand this area. It certainly doesn't sound like a hard problem. | | Each gtk.gdk.Window (subclass) can have its own cursor[1]. Can/should | X be doing this? Or were you thinking of Sugar - just the shell | in Glucose[2] - behaving like this, and encouraging all the Fructose | to implement the same behavior (...s that are applicable)? I imagined this being implemented in Glucose, perhaps at the level of the window manager. I hoped that Activities would not have to be involved. The ability of each window to modify the cursor does make things somewhat more confusing. One helpful note is given in the API doc page though: By default a gtk.gdk.Window uses its parent's cursor.. This suggests that if we change the cursor in the root window, the cursor will change unless it has been explicitly overridden by the current window. This seems to be the sanest possible behavior. If the root Window is a gtk.gdk.Window, perhaps we can just use gtk.gdk.Window.set_cursor(cursor) on that Window. That would be easy. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhAKTwACgkQUJT6e6HFtqRwVQCghYUB0c8P9EoI1VAykCcaLM36 7DAAnA1S5w494TAl25h+Dcm6h5/uhJ+O =jwSn -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] On the Naming of Sugar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think Sugar has a naming problem. There are a lot of different digital objects being produced by this project, and referring to all of them as Sugar is becoming increasingly confusing. For example, the discussion about Sugar on Windows has been all but incomprehensible, because each author means something entirely different by the term Sugar. Similarly, the recent proposals for inclusion in Sugar are extremely confusing, since these components will not be required to run Sugar. To resolve this, I am going to attempt to list a number of important, distinct digital objects that this work has produced. I will also introduce cutesy codenames. I hope that the Sugar developers will adopt a clear set of distinct names, and I do not care if they choose these names or other names. Component: The abstract design of the interface Codename: Sweet (the taste of sugar) Description: Sweet is the abstract design of the interface's appearance and behavior, independent of any code actually implementing this style. The mockups at http://wiki.laptop.org/go/Designs represent this component's second major release, or perhaps 2.0-alpha. Component: The base Sugar environment Codename: Glucose (the fundamental, simple sugar used by all life forms) Description: Glucose is the minimal system that must be added to a standard Linux distribution in order to enable Activities to run. This includes all the python code and graphics files that implement the shell, as well as the Journal. Glucose's dependencies may include xorg-server, xulrunner, squeakvm, rainbow, etc. Some of these dependencies may be marked optional by distributions. Glucose does not include any Activities except those like the Journal that are non-optional. Component: A set of demonstration activities Codename: Fructose (the main sugar in fruit, which is how we're supposed to get our sugar.) Description: The Sugar developers will need some example set of activities with which to demonstrate Sugar. This set is Fructose. The packages in Fructose should be selected to make the resulting environment as impressive as possible for a potential client or user. Packages should therefore be stable, polished, and exercise the widest possible range of features. Fructose may also serve as an example for people constructing their own Activity sets. Component: The interface, plus a set of demonstration activities Codename: Sucrose (table sugar, the kind you buy in the store. It consists of glucose and fructose, combined.) Description: Sucrose consists of both Glucose and Fructose. It therefore represents a complete example Sugar environment, ready to be installed through a package manager. The purpose of Sucrose is so that prospective deployers can install the sugar-sucrose package, and immediately say Wow! Look at all the cool capabilities that this system has!. Component: The base Linux distribution being used by Sugar Codename: Ribose (the sugar used by all lifeforms to control their hardware, in the form of RNA. It's important, but not sweet.) Description: Ribose is the set of hardware-centric software components that have been developed throughout this project. It includes the XO kernels, OHM, any init-script customizations, etc. Ribose should be construed as including all components necessary to boot the system, enough to install Glucose if it has not yet been installed. Component: A complete disk image for Sugar Codename: A starch (starch is composed of multiple sugars bonded together.) Description: We often distribute complete disk images for Sugar, ready to boot. These images are composed of multiple elements of the above stack. ~ For example, the current Joyride images are composed of Ribose (the non-graphical work) and Glucose (the shell) but not Fructose (the activity package). Each image series should be named separately, to minimize confusion. For cutesy codenames, we could have a development build (glycogen, a starch used to produce Glucose) and a stable build (cellulose, an extremely stable starch). -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFILdvCUJT6e6HFtqQRAleBAJwP4SdcydEj65jMx+0oFUQo5O23IACfcRbA /eEeP6Lp7k7WachUYxe3uGM= =jvwh -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Release schedule and process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marco Pesenti Gritti wrote: | Blessing a browser is not going to remove competition. | | In practice, GNOME blesses a browser and despite most of the | distributor/users are using another one, with no interoperability | issues. This is the key example: Gnome has an official browser (Epiphany) and an official mail client (Evolution). I don't know anybody who uses either on their own computers. Yet most still have both installed. This is stupid and wasteful. In truth, I think we are in agreement. As I said before, we should maintain two builds: sugar-base and sugar-demo. sugar-base is essentially a virtual machine for Activities. It does not come with any activities; it is just the empty shell. sugar-demo is an example build, containing a complete set of activities to show what we imagine a typical sugar installation to look like. Both of these builds should be built whenever there is a change, like joyride. Most developers will run sugar-demo. Most users will run custom builds created by their deployments. Deployments will create custom builds by starting with a release version of the sugar-base build and using a customization system to add Activities. The resulting custom build may be similar to sugar-demo, but need not contain all the activities in sugar-demo. I think our problem is just naming. Which of these things is Sugar? We should name these components separately, so that we know what we're talking about. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIKvdvUJT6e6HFtqQRAvhfAJ4pxYC1egYaerryeVlBZkwyRAdJnQCgnA8V yQ6WwmaYuAOkbvRI23qTutQ= =49C2 -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] OLPC priorities for Sugar in the August release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jameson Chema Quinn wrote: | One low-hanging fruit for faster activity start is having activity install | compile .pyc files, with (tiny) extra points if the .pyc gets hints to not | use jffs2 compression. This is on my gameplan with the bundle format update | stuff, but I have gotten stuck on the signatures (openssl cannot read ssh | public keys) so I am behind on that. I had hoped to finish it in my free | time this week but starting next week I cannot be so sure I'll have time. Pretty small fruit. Based on my measurements (http://lists.laptop.org/pipermail/sugar/2008-March/004669.html), we are talking about less than 200 ms for typical Activities. The only Activities I know of with enough code for this to matter are the TamTam activities. Even the Journal spends much less than one second compiling. ~ Additionally, my measurements include the time to write the pyc file back into jffs2, so the real launch delay could be even less. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIK5JwUJT6e6HFtqQRAhbqAJ9jrt0gENi+ar1CCq0QU2O891SH7wCdFlsD JW1/uQlAarBii8WB7V4WVkA= =z9mP -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Release schedule and process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomeu Vizoso wrote: | I agree that limiting the number of components released as a whole | brings important benefits. I think that the idea of releasing some | activities as part of Sugar is because they provide services that | are considered a basic part of the user experience inside Sugar. Could you name an example of such an Activity? It seems to me that the presence of any such Activity represents a design bug in Sugar. In the case of Chat and Journal, these are known design bugs. Chat will eventually be rendered mostly obsolete by pervasive overlay chat, and the Journal is planned to be merged into the Sugar interface itself. The question of whether activities are included by default refers either to prefabricated disk images or packages for distros like Fedora and Ubuntu. Regarding disk images, the answer is clear: do both. We should have minimal disk images, with just the Sugar base, and also demo images with all the activities we think someone might want. Determining what to do in the case of packages for other distros, the situation is much muddier. The plan for Activity packaging is designed around the idea of thousands of unknown authors writing code that installs and runs with minimal privileges. Users will be able to install multiple distinct activities with the same name, distinguished by cryptographic authorship and history, upgrade or downgrade them, and modify their source code, all without superuser access. It's already difficult to harmonize this with yum/rpm and apt/deb, and it's only going to get harder with the new Activity bundle system. I think our best option is to let Sugar retain control of Activity installation, even when running on a system with its own package management. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIKdDXUJT6e6HFtqQRAjsdAJ9TbLwUGlzM+hyWNV47k5AH/oX79ACgj0MD HEQu4wpYffdtpYCfMANPh4I= =KxvY -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Shared Terminal Idea
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Walter Bender wrote: | In general, it'd be great to be able to share like this for most | activities. Another way of thinking about sharing would be to share | resources of multiple laptops to get a bigger workspace, e.g., some | times it is useful to have multiple xterms open. This would seemingly | be simple to do in the context of the X Window System if we wrap the | appropriate Sugar/Collaboration model around it. I can think of lots | of activities that are someone space constrained at times--having the | option of a larger or multiple screens--putting the debugging output | on a separate laptop, for example. Future feature wish list. What you are describing is very similar to the Distributed Multihead X system (DMX, also called Xdmx). See, for example, the pictures in (http://www.ibm.com/developerworks/opensource/library/os-mltihed/index.html) There has been renewed interest in DMX among X developers, especially in the context of Multiple-Pointer X (MPX) and the new rendering plans. If you think this is of interest to Sugar, it might be worth talking to an X expert. For the record, I think that this is probably not a good idea for Sugar. DMX requires a potentially huge amount of network bandwidth, with little tolerance for latency or packet loss. It also seems inevitably, tremendously complicated for a user to manage. But don't listen to me; talk to someone who actually knows where the DMX work is headed. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIKfICUJT6e6HFtqQRAvBfAJkBxjAd1TofcLBAaS3Os+aCNhamHQCgmEe6 Wum2SQFNByhhuXN6zHTNCRc= =/2lk -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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Dengler wrote: | 'F12': 'volume_up', | 'ctrlF11' : 'volume_min', | 'ctrlF12' : 'volume_max', Given our ctrl/alt/shift distinction, it seems to me that these should be shiftF11 and shiftF12 This is philosophically consistent with the idea that shift makes small letters into BIG LETTERS, and similarly makes small volume changes into maximum volume changes. Alternatively they could be altF11 and altF12. But in any event, if we're going to avoid ctrl shortcuts in the shell, then these should change too. | +'alt0xDC' : 'screenshot', I think alt0x93 would actually be better (this is what I meant to suggest). In other words, I think altframe is better than altsearch 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] xomail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joshua N Pritikin wrote: | On Mon, Apr 28, 2008 at 07:39:13PM -0500, Dennis Gilmore wrote: | On Monday 28 April 2008, Joshua N Pritikin wrote: | Do we really want to encourage HTML email? :-P | We should add the option, but i would prefer plaintext as the default. | | I wasn't really serious about plain text email. I mean, do you want to | try to explain to a 7 year old why he shouldn't email a photo to a | friend? Supporting attachments (and rendering them appropriately) is entirely separate from automatically generating HTML for the body text. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIFpLrUJT6e6HFtqQRAgh2AJ9iecDSWeH9V8h/XH1lVdtZupvL3wCfb+kE wPSKMDJS5tbvmTcv31HpK+w= =n7+Z -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] DS possibilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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, 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. Fixing this behavior before the next release is clearly a very high priority. We have considered many possible strategies, and we must now determine which of them we will pursue. There is no need to pursue only one; most are not exclusive. Personally, I expect that more than one will be undertaken. Actions: Make Activities more robust to DS failures. By handling DS exceptions correctly, Activities might fall back into a no-datastore mode, or a read-only mode. This may require modification of sugar.activity.activity, as well as many Activities' codebases. Pro: Reduces the severity of DS failure and corruption Improves user experience immediately Con: A tremendous amount of work to modify every piece of code that use the datastore's API. If the DS is not working, then the system is of very limited utility, if nothing can be saved, or nothing can be read. Thus, this resilience provides only a very small benefit. The DS is as critical as the filesystem, memory manager, or process scheduler. It should absolutely never fail, and creating contingencies for its failure sets entirely the wrong perspective. Improve logging. By logging the details of what the DS, and the rest of the system, is doing, we might be able to determine what has gone wrong. For example, we might notice that DS corruption occurs due to OOM killing the DS process, or due to the system shutting down unexpectedly after loss of power, or due to removing a usb stick without unmounting it. Pro: Lets us know what's going on so we have a chance of fixing it. Improves possibility of reproducing it here. Con: Doesn't solve the problem. Potentially slows down the system. We already have a lot of logging. Notify the user when things go wrong. If the DS is broken, we may attempt to improve the user experience by presenting the user with a blue screen or other notification indicating what has happened. This might also improve debugging, since users would be more likely to send bug reports (and logs) back for analysis. Pro: Improved user experience beyond silent failure. Suggests that the developers are at least smart enough to recognize how the system can fail. Improves the probability that we will get back logs after failure. Con: The DS is as critical as the filesystem, memory manager, or process scheduler. It should absolutely never fail, and creating contingencies for its failure sets entirely the wrong perspective. Set up a datastore test system. These datastore bugs still exist largely because they have not been reproduced in any systematic way. If we find, perhaps by forcing the datastore to crash on command, that we can reproduce the corruption, then we may begin to fix it. Pro: Improves the ability to fix the system Improves the ability to determine that the system is reliable. Con: ? Fix the current datastore implementation. By improving the ability of the datastore to avoid corruption, and increasing its resilience to corrupted files, we may solve this problem. The solution may be complete, or it may be incomplete, depending on whether there are issues of race conditions or atomicity that cannot be fixed in the current implementation. Pro: Least likely to introduce new bugs Possibility of fixing the existing bugs Con: The current datastore doesn't support versioning, and will eventually be thrown away entirely. Thus, doing more work on it is annoying. The system relies on Xapian, which is likely responsible in part for the corruption, and is much more difficult to fix since it is taken directly from upstream. The problems may require drastic alterations to the current design. The current datastore design is deeply incompatible with backups due to the potential for simultaneous access to a single file. Write a new datastore implementation to the same API. Given the complexity of the current datastore, and its dependence on Xapian, it may be very difficult to remove the corruption bugs. Instead, we may consider writing a new datastore that uses a much simpler backend to implement the same API. See http://dev.laptop.org/git?p=users/mstone/sds;a=summary . Pro: Drastic simplification is possible, and could greatly reduce the chance for bugs to appear. Simplicity is extremely valuable. A simpler datastore design might also be more amenable to easy backup solutions. Con: This code would have to be written and then thrown away, since it does not help us to reach our goal of versioning. The drastic simplification would presumably come at the cost of indexing performance, which might become much slower. Many
Re: [sugar] Ad-hoc Networking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Gilmore wrote: | The presence implementation only works on access points and on meshes -- | but not on non-meshed, ad-hoc 802.11. The vast majority of computers | with 802.11 don't have mesh, but they would benefit from being able to | see nearby laptops and share applications with them (whether or not | a local access point, or global Internet access, is working). For full | integration, this probably requires some driver work, but most of the work | is probably at a daemon and library level. There is explicitly support for this idea in 802.11s. It is called a Mesh Access Point, or MAP, and it is the inverse of a Mesh Portal (MPP). A Mesh Portal is a 802.11s device (e.g. an XO) that is acting as a client to 802.11b/g Access Point and is then sharing that connection (perhaps an internet connection) into the 802.11s mesh. A Mesh Access Point is connected to an 802.11s network, and also acts as an 802.11b Access Point whose clients can essentially join the mesh. With both of these things it is possible to have: Satellite internet -- Standard 802.11b access point -- XO acting as MPP -- XO -- XO -- XO acting as MAP -- Standard 802.11b laptop and thus provide a relatively distant internet connection to a standard laptop, which also sees all the XOs on its local network. MPP support is in place, but it does not play well with the School Server (and possibly DHCP), so it has been disabled. MAP support has not been a high priority, and I do not know anything about its current status. I would certainly love if the XOs and Active Antennas could be made to run in MPP and MAP mode. I do not know to what degree the Marvell device is capable of this. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFID6mDUJT6e6HFtqQRAlAQAKCF7J67YVbula0X2jwmee2v2/GdrACeKXQU XJ6mDBDtIDXRyiP+hKcDkeQ= =y5cW -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Ad-hoc Networking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Gilmore wrote: | The IETF ZeroConf protocols provide for self-assignment of IP | addresses in such a case. (The same thing happens if you plug two | laptops together with a short Ethernet cable and no DHCP server.) | | Does the OLPC Presence Service work in such a case? I believe so. I know for a fact that it works on simple direct wired ethernet, as you say, because Michael Stone has tested it. There is a complete abstraction barrier between the presence service+collaboration, and the link-layer protocol. It makes no difference whether it is mesh, ad-hoc, wired, or wireless, as long as everyone is on the same subnet so that zeroconf/bonjour/avahi works. Ricardo Carrano wrote: | Ban (...) the troublesome Mesh you say. This is a misunderstanding. He was merely trying to clarify that he was discussing legacy hardware with no 802.11s components. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFID9ApUJT6e6HFtqQRAgUIAKCaxqrE0ZSkNkbA9iIiZtROhYJb5wCgmrwU QElGJF0/5INA5ABxGJN2VYw= =S8h1 -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Mesh View and XO-presence
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Suppose that I am participating in 3 shared activity sessions, all public. ~ I am switching back and forth between them, perhaps copying things from one to another, and occasionally checking in on the third. The current mesh view design shows my XO icon as attached only to the activity which is currently shown on my screen. I feel strongly that this is the wrong design choice. Instead, my XO icon should be shown next to all the activity instances of which I am a member. Abstractly, placing my XO next to only one activity instance conveys the wrong information. Just because I am currently viewing a single activity does not mean I am not an active participant in many activities. There may be activities for which being an important participant only requires very occasional participation. For example, I may be the lead author on a team paper, but not shown in that activity because I am only checking it every hour or so. The current design is a privacy violation. IM programs typically provide optional idleness detection, and many users disable it entirely. When the user enables idleness detection, the user may opt either to show idleness on the basis of total system activity (e.g. whether screensaver is active) or on the basis of IM activity. There is never an option to indicate whether each IM window has focus at any given time, because users do not want everyone else to know whether they are looking at that particular window. For a classic example, see http://bash.org/?365072 . In a school setting, this visualization directly enforces a harsh classroom discipline, in which the teacher demands that everyone look only at one particular activity, and can tell immediately if they look somewhere else. The current design is tremendously inefficient. Every state change, like moving between activities, causes O(N) work in the best case (and currently O(N^2)). In a classroom of 30 active students, updating status once a minute results in a broadcast every two seconds on average, with many collisions, grinding the network to a halt. Many of our classrooms have far more than 30 students. If the user has used 3 activities in the past minute, the resulting visualization is also misleading at best. Making a single XO appear multiple times in the mesh view is not confusing, because each of these XO's is reduced in size, and clearly represents the association of a user with a particular activity. It is much more confusing for a user to look in the mesh view and see that her own XO icon is not attached to the activities that she is sharing. Please clarify the mesh view, improve the user's privacy, and reduce network congestion, by not sending notifications regarding which activity has focus in the window manager, and instead showing each XO icon next to each activity in which it is participating. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIB5AyUJT6e6HFtqQRAjk2AJ4oYC7ctEl2ln6qI4AtjSriIzKa3QCfU10D OLZWOTmf1pDW3a6yk/ekqUI= =O6KA -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] sugar roadmap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patrick Dubroy wrote: | On Sun, Apr 13, 2008 at 2:44 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: |Another option would be to create a version of Sugar that appeals to |programmers. But I can't imagine creating such a version that wouldn't |require a lot of programming resources. | | So here's another question: are any of the Sugar developers using it | as their desktop shell? I was thinking of giving that try. If all the | Sugar developer were eating their own dogfood, I'll bet you'd get a | programmer-friendly system in a hurry. In fact, I don't see why it | would be considered to be programmer-friendly already -- it's got | terminal and a text editor, what more do you need? ;-) Yes: I take my XO with me to class and take notes in Write. I used to take my Thinkpad with me everywhere; now it never leaves my desk. I run unmodified Joyride builds on my XO, and I find the interface to be both superb and useful. I recently developed the DOSConsole activity solely on the XO itself, not because I was trying to prove any point but because it was the most convenient way. No: On my desktop I run in Xinerama with two different-sized LCDs. Together, they have about 8 times the area of an XO screen. Sugar will never make sense for that hardware without a serious redesign. On the other hand, running individual activities in windows managed by Metacity would probably work fine. | Anyhow, speaking as someone who has only very recently gotten involved | with the project, I can say that the Sugar interface was one of the | most appealing things to me. I'm sure there are other potential | contributors out there who would be attracted for the same reasons. Me too. The project was vaguely interesting until I ran Sugar in Qemu, at which point it became compelling. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIAq8OUJT6e6HFtqQRAgfFAJ0eOrVMly2CwnNGf83tuWUXHklakQCfcRjS yOFnnT+++KnA4/QKJNgkARg= =aEVp -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Wine Activity and DOS Console
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benjamin M. Schwartz wrote: | In order for it to run, you must first add 'org.winehq.WineConsole' to the | list of RAINBOW_CONSTANT_UID activities in | /usr/lib/python2.5/site-packages/sugar/activity/activityfactory.py I have now posted http://dev.laptop.org/~bemasc/DOSConsole-2.xo which no longer has this restriction. DOSConsole-2 will run perfectly happily without RAINBOW_CONSTANT_UID. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIAOziUJT6e6HFtqQRAuSrAJ465+I3o62zs/o4vtfMHojBo6WtrwCdFZps ngH2j2HKt+4H9Wz9Dv3FMbY= =CmnF -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Matchbox window management hints
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am trying to make Wine work as a Sugar activity. One of the most serious problems is that the Wine desktop window appears as a dialog. It appears in front of the frame, with decorations. I presume this is because it is non-resizable. However, it has a fixed size of 1200x900. How can I configure matchbox to handle this window like any other activity window? Where is our matchbox configuration source repository, anyway? Thank you, Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIARu8UJT6e6HFtqQRArUSAJ44v8Xn1B0A2JXwBhS7E/cGsMqcpQCfcBLs AcZecRWX4tsiF6eIkKuJVVE= =aFoR -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] sugar roadmap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote: |3. Need easy way to group links to activities, such as in a lesson |plan. | |Use Case: |Kid reads through geometry tutorial and clicks on first activity which |opens up Dr. Geo. After finishing w/ Dr. Geo he does some more reading |in the tutorial and then clicks on a second link which opens up a |related GCompris activity. | |We need a way to launch different activities from within a graphical |context, e.g. a tutorial. HTML is the most practical way to do this. I |know there are issues w/ Rainbow and activities calling other activities |but this is very important to the learning process. | | Interesting, would like to know what Eben thinks about it. | | This is an interesting idea, and one I don't really have a direct | solution for, at present. One potential option, and perhaps the most | interesting, is also a fair bit of work. It entails adding a bitfrost | permission (does it already have one?) akin to P_EXEC or something | similar, which allows an activity to make a request to the shell to | launch another activity, passing it a URI (could be a file, could be a | URL, etc) and having it ask the user to confirm the action. With such | an approach, any activity that wanted could embed links to other | activities, or to web sites. If we build this into the shell, and | offer it as a permission, I don't believe that it will pose any | security problems*. | | * I could be very wrong, though. IMHO, the best solution is the one already used by Browse in the case of PDF downloads. The files are downloaded, and then the Journal is asked to present the user with information about the item and the option to launch it. This is akin to how most modern browsers handle media files that will launch outside the browser. They present a window saying You are downloading a file of type PDF. Would you like to open it using Document Viewer? They also offer a drop-down list of alternative applications. Letting the Journal handle all open requests improves usability, in my view, by ensuring that the user can always postpone an opening action, or choose an alternative handler. I also think it improves security, by avoiding a number of potential DoS, privilege escalation, and information disclosure (e.g. #6837, #6838) problems. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH/2uEUJT6e6HFtqQRArQ7AKCKZcPpfy+WSwVXh4gEXa7kUZ9VzgCfVm/8 xQbxF13HGL9ibnY4hCETGvM= =BKz7 -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Clicking links (was Re: sugar roadmap)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote: | On Fri, Apr 11, 2008 at 11:15 AM, Bert Freudenberg [EMAIL PROTECTED] wrote: | I personally find addressing this scenario not worth the awkwardness | we currently have, clicking a URL in any activity should open a | browser on that URL, no questions asked, IMHO. If necessary, invent a | new permission for this. | | Well, perhaps a permission is in fact needed then. Of course, I still | see that there could be worth in a service which allows activities to | launch others. Perhaps the Develop activity eventually wants to | launch an SVG editor for its icon. Perhaps Write wants to be able to | embed links to other projects (as was initially mentioned as the use | case) for writing tutorials. I'm not sure how to accomplish this. I'm pretty sure how to accomplish this. If an Activity wants to open the browser, perhaps in response to clicking a link, it should 1. Save the link as an object in the datastore. It should have a mime type indicating that it is a URL, like text/uri-list. 2. Ask the Journal to display the detailed view for this new object. That's it for the activity. 3. The user opens the object like any other Journal object. This requires one click. Alternatively, the user decides not to open the object, or decides to do something more complicated with the object. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH/8H1UJT6e6HFtqQRArdrAKCg6xsqwmJiiN/SAAbNeGAeJ4dBpACffS9E XSS5VcjthaGAtpXC9zQ7ZJw= =2asn -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Clicking links (was Re: sugar roadmap)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote: | In fact, this exploit could happen even without a launcher service. | Any activity that wants to could write the users private data to the | disk in a URL format, as an object, and give it a fun preview image. | When the later discovers and becomes curious about it, she'll open it | and send out her private data to whatever site the other activity | wanted. Is there something in place to prevent this that I'm unaware | of? I would argue that there is no way around this, and that it should not be seen as an exploit. Users must understand that any object produced by an activity instance can potentially contain any information available to that instance at that time. The best we can do is to show the user which instances have written data in each object, and which objects those instances had access to. That list is the list of all private data that could potentially be enclosed in each object. This is relevant not only to HTTP access but also to Sharing. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH/8cNUJT6e6HFtqQRAj8FAJ0bHSY+MZRUTIsWDikpqZ6BOVDq+gCeIX1Q QLCFODVjOiq2ZbRXGJvulPA= =id1g -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Choosing defaults for the activity ring
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote I prefer option (1) because it's the behavior I would want as a user. With option (1), it's more obvious that new activity bundles have been installed. It's also more straightforward to implement. | Option (2) is somewhat more complex, but ensures that the user doesn't | have to repeatedly un-favorite activities which they don't want in | their ring. Where repeatedly means each time a Customization Stick is inserted. I do not imagine this happening more often than once a semester, i.e. very infrequently. It does not sound very inconvenient to me. Remember, this is the same frequency with which we anticipate that new OS releases will be installed. In fact, once we have automatic network activity updates, as recently discussed, I suspect that customization sticks will be used very little. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH9sUxUJT6e6HFtqQRAoDTAJwLvas9mWk4DBz3U/82s3u/rE/xMQCfZX0o wCSPmarE//HK7RVRCAevjzQ= =UWRr -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] GVFS, OLPC, and GIT ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexander Larsson wrote: | On Mon, 2008-03-24 at 15:34 -0400, Benjamin M. Schwartz wrote: | Dear Mr. Larsson, | My name is Ben Schwartz, and I am a volunteer with OLPC. As you may be | aware, the OLPC design calls for a centralized versioning differential | datastore, in which all of the user's work is kept. The versioning | requirements are similar to the capabilities of git, so git, or a | similar version control system, might be used as the backend. | | In addition to versioning, OLPC also requires that objects in the | datastore support extensive metadata for tagging and commenting. | | Would GVFS be an appropriate layer in which to implement generic access | to a version-controlled storage system like git? In my perusal of the | GIO API docs, it was not clear to me that GIO's notion of a file is | sufficiently generic to encompass multiple versions. I do not fully | grasp the layering between GIO and GVFS. | | GIO is the API. It is used by applications to access, enumerate and get | info about files. It models the filesystem as an abstract entity that | has a behaviour somewhat similar to posix, but more generic, with some | extended operations (copy file, save, etc), and with somewhat less | strict semantics. It contains an implementation of this for local files, | but also allows plugins to extend this functionallity. | | GVfs is a plugin for gvfs that allows support for access to non-local | files. This is achieved by a model where each mount of a remote (or | otherwise virtutal) location is handled by a daemon. The gio plugin uses | dbus to inititate operations with the daemon. GVfs also contains a set | of backend daemons for different types of mounts (ftp, dav, sftp, etc). | | What would you do, if you were trying to provide a version-controlled | datastore as a desktop service? | | The gio file model is somewhat generic. For instance file metadata are | namespaced key-value pairs that you can extend however you want, and the | backing of your filesystem can be whatever. However, it doesn't really | have explicit versioning support. So, reading files from the latest or a | particular snapshot in history of a versioned filesystem is handled | fine, but the actual operations related to versions are not naturally | expressed. | | However, it certainly can be done in a variety of ways. Some options off | the top of my head are: | | * Mount the specific tree version you want (or HEAD to follow latest) as | a separate mount (off the same backing version store) | | * Have some kind of operation that takes a versioned filesystem mount | (globally) to a different version. | | * Expose multiple versions of the same file/directory using different | names. For example each directory could have a .history subdirectory | with files like .history/filename/version which is a historic | version of filename. | | What kind of user interface are you expecting to have for this? A | timeline/time-machine kind of browser, or a per-file open-old-version | kind of thing? The desired UI is something like this: http://wiki.laptop.org/go/Designs/Journal There are large number of different, independently revision-controlled directories, but the user can select any item and look through previous versions of it. I think there are also plans for a more detailed time-line exploration view, but I do not know if any details have been drawn yet. It sounds like in order to use GVFS for a revision-controlled system, one must either represent versions as paths or mounts. Neither seems ideal to me, as versions are something else altogether. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH6Qw/UJT6e6HFtqQRAtcGAKCSr4WQmfMSxiuHkRezkdDGe2rBEQCeKa+8 fnWEU36rSJkHvN4/RIZWzws= =Tote -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Automatic transfer/update of activities on the mesh (Was: Sharing behavior in the core Read activity)
On Tue, 2008-03-25 at 13:46 -0400, Eben Eliason wrote: Naturally, there are some security concerns, but those could be easily addressed, I believe, with the usual signing mechanisms. Updates to activities would only be transparent if the update was signed, etc. I agree. For a first implementation, only basic signing is required. Eventually, we may have activities written by teams of children in which new members come and go, and the projects occasionally fork. This requires a more complex signing/upgrade system. I sketched one proposal at [1]; it is not perfect. The bigger question is really determining how to make the whole transfer process work smoothly in these cases. Can we use a torrent model to make it easy to get activities from the mesh, even as people come and go on an unreliable network? For a first implementation, this is not necessary. Most Activity Bundles (.xo's) are about 100 KB or less. Over a direct mesh link, transferring small bundles takes about a second. Only with very large activities, and very bad links, will simple transfers be insufficient. Can we transfer it directly from someone who is in the activity we join? This seems the simplest solution. If so, can we still ask the next activity participant for the remainder if the first one leaves? Yes. However, for a first implementation, the download should probably just restart. This optimization will only be important for activities with exceptionally high turnover. As there has been interest expressed in developing basic OS integrated object transfer as a GSoC project, I wonder if those efforts could also be applied to this problem, or if this should be offered as another distinct project alternative. Current implementations of file transfer (Read, and therefore Distribute) work by getting a Stream Tube from Telepathy, and then running a HTTP server on this tube. Any near-term implementation of transferring Journal Entry Bundles or Activity Bundles is likely to use the same mechanism. This works, and will work for the proposed case. For the future, I see file transfer as precisely the sort of thing that should be handled internally to Telepathy. Perhaps Telepathy should implement XEP-0234 (file transfer)[2] or even XEP-0214 (file sharing)[3]. What do people think? I think it would not be too hard, and should definitely be on the to-do list. It would be a major user-visible milestone in the journey toward Complete Sugar. There are several things that have to happen first: 1. Basic activity signing. 2. Pushing SVG files through Presence, so that I can see the icon in the mesh for an activity I don't have. 3. Sane activity storage: What if the shared session is a newer version of an installed activity, but it's been modified by someone other than the original author? I should then be able to join, but it should be treated as a new activity, not an upgrade, even though it has the same name. This means we need an activity storage mechanism that can handle multiple activities with the same name. Also, all installed .xo bundles must be kept around, or Sugar must be able to reconstitute them on demand without invalidating the signatures. --Ben [1] http://lists.laptop.org/pipermail/security/2007-December/000341.html [2] http://www.xmpp.org/extensions/xep-0234.html [3] http://www.xmpp.org/extensions/xep-0214.html ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Activities are recompiled on every launch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In order to run a python program (.py), the python interpreter must first
compile it to bytecode. The bytecode is stored in a .pyc file, when
possible. In the case of installed packages, like NumPy or Sugar, the
.pyc files are generated during installation (i.e. while the build is
being prepared at 1CC). However, in the case of Activities, the .pyc
files are never generated.
~From [1]:
When a script is run by giving its name on the command line, the bytecode
for the script is never written to a .pyc or .pyo file. Thus, the startup
time of a script may be reduced by moving most of its code to a module and
having a small bootstrap script that imports that module. It is also
possible to name a .pyc or .pyo file directly on the command line.
This trick unfortunately cannot work with Rainbow, because the Activity
runs as a user who does not have write access to the directory containing
the .py files. The Python interpreter does not use any setuid tricks to
write .pyc files into system paths, nor does it cache bytecode in a
~/.python/ directory, etc.
The module compileall can create .pyc files (or .pyo files when -O is
used) for all modules in a directory.
This seems more appropriate. Perhaps all the .py files could be compiled
upon bundle installation.
Overhead measurement:
As a measure of overhead, I tried the following on my B4 running joyride-1790:
# time python -c import py_compile
real0m0.108s
user0m0.080s
sys0m0.030s
# time python -c import py_compile; py_compile.compile('pippy_app.py')
real0m0.259s
user 0m0.250s
sys0m0.030s
# time python -c import compileall
real 0m0.110s
user 0m0.110s
sys 0m0.000s
# time python -c import compileall;
compileall.compile_dir('/usr/share/activities/TamTamEdit.activity/',
force=True, quiet=True)
real 0m3.902s
user 0m3.460s
sys 0m0.440s
All measurements were made multiple times to ensure cached reads. The
measurements may overestimate the amount of time actually required, since
these times also include writing the .pyc files into the compressed
storage. Nonetheless, I think that most activities spend about 0.2
seconds compiling on every launch. The Journal takes just over 0.5
seconds, Record takes about 1.3s, and the TamTam activities (with a huge
amount of code) take 3.x seconds.
I suspect that we would be willing to trade the slightly increased size on
disk for the slight improvement in launch speed.
[1]: http://docs.python.org/tut/node8.html#SECTION00813
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH5uGcUJT6e6HFtqQRAiFLAJ97RJ74D3ivVT0FLjDwvEwxTvs3ZACfeV3D
SOxU8XL3bVtL+kAowgZRRX8=
=x8o6
-END PGP SIGNATURE-
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activities are recompiled on every launch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Langhoff wrote:
| On Sun, Mar 23, 2008 at 7:02 PM, Benjamin M. Schwartz
| [EMAIL PROTECTED] wrote:
| # time python -c import compileall;
| compileall.compile_dir('/usr/share/activities/TamTamEdit.activity/',
| force=True, quiet=True)
| real 0m3.902s
| user 0m3.460s
| sys 0m0.440s
|
| All measurements were made multiple times to ensure cached reads. The
|
| That's a quick turnaround ;-) Do we know who implemented the python
| support for all this?
I don't, but it hasn't changed much for a decade or more.
| It sounds like it is a safety feature - or an
| avoid running stale code feature - that it won't use a pyo file from
| a script named in the commandline. In other words, it should be
| trivial to get Python to use it.
If you're proposing to patch the python interpreter...that sounds like too
much work. Instead of running python foo.py, you can do python
foo.pyc or python foo.pyo and it just works. Also, I think the faster
branch doesn't invoke the /usr/bin/python binary for launches anyway.
If I understand correctly, Tomeu's faster-launch implementation loads the
activity's .py files using the import statement, and the import
statement automatically uses a .pyc file if its timestamp is newer than
the .py file's timestamp. So all we have to is make sure the .pyc files
are present and python will do the rest.
- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH5vBHUJT6e6HFtqQRAt4eAJ9tnEyjc1N6npQAiEfoIZ73T/f6awCgij2r
klZpTTgUpBBWpACXtR8Gt44=
=Dt6N
-END PGP SIGNATURE-
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Image Recognition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 | A low-cost, low-power laptop with a built-in webcam and a somewhat | iconic interface offers some interesting possibilities for folks whose | primary means of communication is via sign language. | | I'm beginning to generate some interest on campus in the XO, and will | be hosting the next meeting of the OLPC Learning Club of DC when I get | back from PyCon 2008 (Chicago). With any luck, some of the people on | campus who claim to be interested in improving deaf ed outside the US | will attend. Higher rates of deafness in the OLPC target countries make this even more important. The XO has a distinct focus on real-time text-based chat (IM). I suspect that this will do a lot to improve communication between deaf children and hearing children, much as it seems to have done in the US. Chat also provides an easy opportunity to bring deaf children into the classroom, simply by designating one or two hearing students as transcribers for each lesson, and letting the trancribers and deaf children share a chat session. Regarding sign language, I doubt that automated video analysis and transcription of sign languages will be possible. The CPU is similar in processing power to the best desktops of 1997. In 2000, real time video analysis could recognize fewer than 100 gestures, with an error rate of almost 10% (http://doi.ieeecomputersociety.org/10.1109/ICPR.2000.906112). ~ Today, sign language recognition is still just a research project, even with unlimited processing time. Video capture is already possible on the XO, and may be useful for learning sign language if the teacher is only available over the internet. ~ Video playback could certainly be useful for learning a sign language, perhaps with a video course provided on a USB stick. There appear to have been a number of efforts to codify written forms for sign language, notably SignWriting (signwriting.org). There is even a Python-based program for SignWriting (http://signwriter.takdoc.de/). Is this writing system, or another writing system, viewed favorably by the community at Gallaudet? If so, creating a sign-language writing Activity for OLPC might be an appropriate endeavor for Gallaudet students. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH4IXeUJT6e6HFtqQRAqRgAJ9n8H67CEGlt6Y0fNC4MYbF9nqI9wCfdLS2 UPscfldIgknHjGBsTXRPPpg= =qot9 -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Memory allocation indicators
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kent Loobey wrote: | On Wednesday 12 March 2008 10:51:15 pm Benjamin M. Schwartz wrote: | The | question is: do users need to know how memory is being used, and if so, | what sort of indicator is appropriate? | | As a rule of thumb you shouldn't tell a user anything that you will not let | them do something about. So in this case unless you are going to list the | memory demand of all of the activities they could optionally start next there | is no point in telling them how much memory they are allready using. Users would quickly get a feel for how much ring space each activity takes, since the amount of space is shown at runtime. If launching failed with a not-enough-memory error, people would get the picture very quickly. | | I do think indicating how many activities they have running of the total | number they can run is VERY useful. The total number of Browse instances you can run is about 3. The total number of Terminal instances you can run is probably 20 or more. | | Also, it would be easy for Rainbow to enforce a pre-set hard limit on | memory usage for each Activity separately. | | Does Python support activity segment overlays? I was specifically referring to per-user memory limits. Since Rainbow creates a new, independent user for each Activity instance, all the standard Linux per-user accounting can easily be activated. These standard kernel-level tools include limits on amount of memory used, number of processes, amount of disk space, number of inodes, minimum process priority level, etc. | I think that this is very | interesting, since it would allow us to ensure that OOM never happens, by | only launching an activity if all activities could still max out their | quota afterwards. However, this reduces the functionality of the system, | by limiting the number of running activities to the worst-case scenario. | | Hmm, one could divide the total available memory into pages (say 16KB each). | Then each activity could specify the number of pages it needs to run. You | could then use that number to inform decisions. Paging is handled at the kernel level. Yes, Activities could indicate ahead of time how much memory they require. That is precisely the proposal I was discussing. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH2UyQUJT6e6HFtqQRAq7TAJ9ll6Os3Z1BDq9jzjgW3/oWRXQT4QCbBdWz +qhkyNFm2pA+xyFAMTg/b+0= =nPjL -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Memory allocation indicators
On Thu, 2008-03-13 at 16:03 -0400, Michael Stone wrote: Also, it would be easy for Rainbow to enforce a pre-set hard limit on memory usage for each Activity separately. I've thought about it before, but I don't think it leads to a good UI at the moment. The problem is that I don't think you really want to nuke activities that hit their hardlimit, or to start returning ENOMEM to ones that hit the soft (memory) limit. I agree, though I would say it in reverse: in order to ensure that correctly functioning activities don't hit their limits, the limits specified in activity.info would have to be so high that only a few activities could run simultaneously. I think that this is very interesting, since it would allow us to ensure that OOM never happens, by only launching an activity if all activities could still max out their quota afterwards. This safety property only seems to be true if we can give reasonable upper bounds on _all_ the software that we're trying to run, no? This is a good point. User olpc would also have to run with memory limits, and sugar would have to be debugged to the point that it could safely run within these bounds. P.S. - Ivan and I once kicked around the idea of modifying the 'hard' 'soft' limits notion into a 'sleepy' limit notion. In implementation, this might consist of sending SIGSTOP rather than SIGKILL and blocking a malloc() rather than returning ENOMEM until pressure is eased. Unfortunately, this hasn't gone beyond the drawing board. That's an interesting proposal, though it replaces OOM with a state in which all processes are SIGSTOPed one by one. I recall a complementary design in which, when a few MB of free memory remained, the kernel would call a userspace OOM prevention handler, which would SIGSTOP all activities and then present the user with a modal dialog to kill one of them. IIRC, there is currently no support for this in the kernel, and so it has remained on the very large back burner. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Memory allocation indicators
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The original inspiration for the Activity Ring was that the Ring could serve both to indicate which activities were running and how much memory they were using. This was considered important in order to provide feedback to prevent users from attempting to open many activities at once. ~ Typical Windows users have difficulty keeping track of which programs they have open, and so wind up having many programs open simultaneously, causing swapping even on machines with a great deal of memory. This problem is perhaps even worse on Mac OS X. Since the original XO design only had 128 MB of RAM, it was considered crucial that the UI provide feedback to prevent an Out Of Memory situation. With the Ring now being abandoned entirely, the UI will no longer contain an indicator of memory usage. The amount of memory is now 256 MB. The question is: do users need to know how memory is being used, and if so, what sort of indicator is appropriate? Also, it would be easy for Rainbow to enforce a pre-set hard limit on memory usage for each Activity separately. I think that this is very interesting, since it would allow us to ensure that OOM never happens, by only launching an activity if all activities could still max out their quota afterwards. However, this reduces the functionality of the system, by limiting the number of running activities to the worst-case scenario. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH2MDTUJT6e6HFtqQRAhknAJ9BOBfrzX9/hQ7lO25Um6AplNgZpgCgoJkY qDtoPLNbCbsuUEgv5V5zBV8= =FDCb -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Datastore: uid, entry_id, object_id, activity_id ?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tomeu Vizoso wrote:
| On Sat, Mar 8, 2008 at 11:17 PM, Benjamin M. Schwartz
| [EMAIL PROTECTED] wrote:
| According to this page:
http://wiki.laptop.org/go/Journal_entry_bundles ...
|
| Each journal entry has a unique uid. This 'uid' is listed in its
| metadata, and a conforming Journal Entry Bundle uses the uid calue to name
| various components of the bundle. However, the DSMetadata object
| retrieved by calling dsobject.get_metadata() does not have a 'uid' key.
| What is the uid, and, given a DSObject, how am I supposed to determine it?
|
| Use the object_id attribute of the DSObject:
|
| http://tinyurl.com/2sgulm
|
http://dev.laptop.org/git?p=sugar-toolkit;a=blob;f=sugar/datastore/datastore.py;h=334c866a6783463ff53146a35300fd1191bebcb1;hb=HEAD#l84
|
OK. On http://wiki.laptop.org/go/Journal_entry_bundles, you gave an
example of activity metadata:
{activity_id:67d38ab406143c6b6b023896e9efa8fc7706ff57,
~ title_set_by_user:0,
~ uid:15b114ad-1eed-461f-9315-129bba41ce2d,
~ vid:1.0,
~ title:Paint Activity,
~ timestamp:1192547469,
~ activity:org.laptop.Oficina,
~ filename:,
~ icon-color:#00588C,#00EA11,
~ mtime:2007-10-16T17:11:09,
~ mountpoint:18d7246f-72a4-4089-b7dc-2dbdf2b81aa6,
~ keep:0,
~ mime_type:image/png,
~ preview:15b114ad-1eed-461f-9315-129bba41ce2d}
This metadata dict contains a 'uid' key. Currently, the metadata
associated with a DSObject has no such key. Is this a bug in the
datastore, a problem with that wiki page, or a misunderstanding on my part?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH1Gd1UJT6e6HFtqQRAmI3AKCg5Sb2chM9M3H0BXb3tqrv8oRoagCgjjR8
aBqIC6v82gLsGssJcLLpq5g=
=4A1E
-END PGP SIGNATURE-
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
[sugar] Activity for Distribution of Arbitrary Stuff
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Long story short: http://dev.laptop.org/~bemasc/Distribute-1.xo Story: Currently, the only way to move data from one XO to another in the UI is by opening that data from the Journal with the program that edits it, sharing the editing session, and then closing the editing session without performing any editing. In cases where you just want to move a Journal entry from one place to another, Distribute provides a streamlined solution. Just share it, and anyone who joins will automatically receive the Journal entry in question. Distribute is extremely bare-bones right now. It has precisely one feature: it moves your stuff from one place to another. It doesn't do a very good job of telling you what it's doing, and it doesn't really have a GUI at all, but it works. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH1JODUJT6e6HFtqQRAik2AJ9yDVah79Khdb0jXVaNRI6+FZOhgQCglDB4 Hu/wyJ8MQZVliKddX2Dhtto= =Lm9q -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Datastore: uid, entry_id, object_id, activity_id ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to this page: http://wiki.laptop.org/go/Journal_entry_bundles ... Each journal entry has a unique uid. This 'uid' is listed in its metadata, and a conforming Journal Entry Bundle uses the uid calue to name various components of the bundle. However, the DSMetadata object retrieved by calling dsobject.get_metadata() does not have a 'uid' key. What is the uid, and, given a DSObject, how am I supposed to determine it? - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH0xBqUJT6e6HFtqQRAtbXAKCKHEeKvgfFSfFCDYoXejzvEO99pACgorFp EX3q+vopHGn5KOV8HKoxYJA= =Y1Q9 -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Does datastore.write() work at all?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When I call datastore.write(jobject), my program dies, producing the
appended logfile. The error is
~ File /usr/lib/python2.5/site-packages/olpc/datastore/datastore.py,
line 177, in _resolveMountpoint
~mp = self.mountpoints[mountpoint]
KeyError: dbus.String(u'1285c87a-1b13-4463-9e19-87f0ad8e1828',
variant_level=1)
This is very mysterious to me.
Please help,
Ben
Log:
groupadd: group 10001 exists
Creating mailbox file: File exists
(sugar-activity:1141): libgnomevfs-WARNING **: Unable to create ~/.gnome2
directory: Permission denied
(sugar-activity:1141): libgnomevfs-WARNING **: gnome_vfs_init(): .gnome
does not exist
Archive: /home/olpc/isolation/1/uid_to_home_dir/10004/tmp/1205022091.xoj
~ creating:
/home/olpc/isolation/1/uid_to_home_dir/10004/instance/2a21b50d415bff49d9cac7b55cc87ab4887cc550/
~ extracting:
/home/olpc/isolation/1/uid_to_home_dir/10004/instance/2a21b50d415bff49d9cac7b55cc87ab4887cc550/preview/2a21b50d415bff49d9cac7b55cc87ab4887cc550
~ extracting:
/home/olpc/isolation/1/uid_to_home_dir/10004/instance/2a21b50d415bff49d9cac7b55cc87ab4887cc550/_metadata.json
~ extracting:
/home/olpc/isolation/1/uid_to_home_dir/10004/instance/2a21b50d415bff49d9cac7b55cc87ab4887cc550/2a21b50d415bff49d9cac7b55cc87ab4887cc550
caution: excluded filename not matched: mimetype
- ---
class 'dbus.exceptions.DBusException' Traceback (most recent call last)
/home/olpc/Activities/Distribute.activity/distribute.py in
_download_result_cb(self=DistributeActivity object at 0x86ffbbc
(SugarActivity at 0x879), getter=GlibURLDownloader object at
0x83c2504 (sugar+network+GlibURLDownloader at 0x87c7190),
tempfile='/home/olpc/isolation/1/uid_to_home_dir/10004/tmp/1205022091.xoj',
suggested_name='1205022091.xoj', tube_id=dbus.UInt32(463787902L))
~113 self._bundle =
journalentrybundle.JournalEntryBundle(tempfile)
~114 _logger.debug(Saving %s to datastore..., tempfile)
- -- 115 self._bundle.install()
~self._bundle.install = bound method JournalEntryBundle.install of
journalentrybundle.JournalEntryBundle instance at 0x83c0d4c
~116 self._load_document()
~117
/home/olpc/Activities/Distribute.activity/journalentrybundle.py in
install(self=journalentrybundle.JournalEntryBundle instance at 0x83c0d4c)
~108 jobject.metadata['uid'] = ''
~109 jobject.file_path = os.path.join(install_dir, uid,
uid)
- -- 110 datastore.write(jobject)
~global datastore.write = function write at 0x84ba374
~jobject = sugar.datastore.datastore.DSObject object at 0x83c0e4c
~111 finally:
~112 jobject.destroy()
/usr/lib/python2.5/site-packages/sugar/datastore/datastore.py in
write(ds_object=sugar.datastore.datastore.DSObject object at 0x83c0e4c,
update_mtime=True, transfer_ownership=False, reply_handler=None,
error_handler=None, timeout=-1)
~255 ds_object.object_id = dbus_helpers.create(properties,
~256 file_path,
- -- 257
transfer_ownership)
~transfer_ownership = False
~258 # TODO: register the object for updates
~259 logging.debug('Written object %s to the datastore.' %
ds_object.object_id)
/usr/lib/python2.5/site-packages/sugar/datastore/dbus_helpers.py in
create(properties={'activity': 'org.laptop.AbiWordActivity',
'activity_id': '2a21b50d415bff49d9cac7b55cc87ab4887cc550', 'icon-color':
'#5E008C,#AC32FF', 'keep': '0', 'mime_type':
'application/vnd.oasis.opendocument.text', 'mountpoint':
'1285c87a-1b13-4463-9e19-87f0ad8e1828', 'mtime':
'2008-03-09T00:21:42.626965', 'preview':
dbus.ByteArray('\x89PNG\r\n\x1a\n\x00\x00\x00\rI...{\xf8\x0f\xe6\x93\x00\x00\x00\x00IEND\xaeB`\x82'),
'share-scope': 'private', 'timestamp': 1205022102, ...},
filename='/home/olpc/isolation/1/uid_to_home_dir/10004/ins...887cc550/2a21b50d415bff49d9cac7b55cc87ab4887cc550',
transfer_ownership=False)
~ 43 def create(properties, filename, transfer_ownership=False):
~ 44 object_id =
_get_data_store().create(dbus.Dictionary(properties), filename,
- --- 45 transfer_ownership)
~transfer_ownership = False
~ 46 logging.debug('dbus_helpers.create: ' + object_id)
~ 47 return object_id
/usr/lib/python2.5/site-packages/dbus/proxies.py in
__call__(self=dbus.proxies._ProxyMethod instance at 0x83c0eac,
*args=(dbus.Dictionary({'activity_id':
'2a21b50d415bff4...on/vnd.oasis.opendocument.text'}, signature=None),
'/home/olpc/isolation/1/uid_to_home_dir/10004/ins...887cc550/2a21b50d415bff49d9cac7b55cc87ab4887cc550',
False), **keywords={})
~134 introspect_sig,
~135 args,
- -- 136 **keywords)
~keywords
Re: [sugar] Does datastore.write() work at all?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benjamin M. Schwartz wrote: | ~ File /usr/lib/python2.5/site-packages/olpc/datastore/datastore.py, | line 177, in _resolveMountpoint | ~mp = self.mountpoints[mountpoint] | KeyError: dbus.String(u'1285c87a-1b13-4463-9e19-87f0ad8e1828', | variant_level=1) No longer mysterious. This long string represents a mount point, in this case, the NAND flash of one machine. I was transferring this metadata to another machine whose NAND flash has a different identifier. datastore.write() was confronted with a DSObject that was asking to be saved to an unknown volume. Bug? Feature? Either way, understood. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH0zw9UJT6e6HFtqQRArbMAJ40Yn8AJtDkR9Lw4b7+FydJqkVljQCbBcig sefxQKRyoVi8yng+Fa6h9BE= =TBQi -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Journal Object metadata
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomeu Vizoso wrote: | On Sat, Mar 1, 2008 at 6:44 AM, Benjamin M. Schwartz | [EMAIL PROTECTED] wrote: | I have read all the documents I could find, and also the Sugar source, and | I am still confused: | | How can an activity get an object representing all the metadata for its | current datastore object? | | Can you please elaborate? Are you using the python API? If so, | Activity.metadata contains a dictionary with all the properties for | the current object. Yes, but then I'd have to serialize that dictionary myself in order to send it over a Tube. | | I ask because I am writing a trivial Distribute Activity, whose purpose | is to copy journal entries from one XO to another by sharing. This is | working, but since the copy does not have any metadata, like MIME type, it | cannot be opened from the Journal interface by any Activity except | Distribute, which created it. | | Ideally, I would like to acquire the metadata as a dbus object, so that I | may simply shove it over a DBus Tube and then pass it on to the receiver's | datastore. | | What if you serialize the whole entry (file + metadata) inside a zip | file and distribute that? | | http://wiki.laptop.org/go/Journal_entry_bundles | | The journal has already support for installing to the DS these | serialized entries: | | http://dev.laptop.org/git?p=journal-activity;a=blob;f=journalentrybundle.py | | Added because of http://dev.laptop.org/ticket/4380 . This sounds perfect. In Activity code, how do a I get a journal-entry-bundle from a datastore objectid, or datastore file path? - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHz0OJUJT6e6HFtqQRAlY4AJwJ9NFPnW+vGeQrpkTM8RqlnBQOVACePPA+ /wKXl7Vz7hYCs1hB7LIRBqk= =aORy -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] problem in sugar_jhbuild
On Thu, 2008-02-28 at 17:20 +0100, Tomeu Vizoso wrote: Right, I think there's some discussion going on about which view should be the default. As changing that will be rather trivial code-wise, I guess we can defer that decision. I have a proposal that might be relevant, based on a discussion with Chris Ball about hibernation (i.e. suspend-to-disk). Hibernation essentially saves all of userspace RAM into a file on disk, along with the list of active processes, then shuts down. On the next boot, it simply reads that file back into memory and continues those processes. This is a very desirable behavior, as it allows one to pause one's work and consume precisely zero power. However, hibernation can require a large amount of disk space, and is relatively fragile in relation to network connections and hardware state. I would like to propose a form of fake hibernation, implemented at the level of Sugar. If the user clicks the hibernate button, Sugar should tell all open activities to Keep their state, and also save: the list of open activities, which one was active, any clipboard objects, and which view was in the foreground. On the next boot, Sugar can simply restart all open activities from that latest checkpoint, activate the active activity, show the correct view, and recreate the clipboard. This approach would be far more efficient than hibernation, and IMHO more reliable as well. Fake hibernation relies on a standard reboot sequences, so boot-time optimization would be very valuable. Open questions: 0. Should fake hibernate be a user-visible option? 1. Should fake hibernate be the default shutdown behavior? Pro: makes system use feel very continuous. Con: requires manual shutdown of every activity. Potentially problematic interaction with memory pressure and OOM under current implementations. 2. Should OHM automatically trigger a fake hibernate under certain conditions, such as very low battery, or screen closed for 30 minutes and no mesh contacts made? ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] controlling AGC of camera on the XO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arjun Sarwal wrote: | I need to turn OFF the AGC of the camera on the XO within my Activity. I recommend that you simply process the input in Bayer mode, which automatically disables AGC, white-balancing, gamma correction, and other image manipulations. The instructions for testing Bayer mode are here: http://lists.laptop.org/pipermail/devel/2008-February/011029.html - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHvh9eUJT6e6HFtqQRAgObAJ9J9yu2fZtLVS9tY+STnoafYrpYBwCggX7c jqqyo/Qh0EM96Y3ZA71Y7es= =iyIO -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Distribute activity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomeu Vizoso wrote: | On Mon, 2008-02-18 at 22:37 -0500, Benjamin M. Schwartz wrote: | In light of the many requests for a way to distribute arbitrary Journal entries, | I am writing an activity tentatively named Distribute. This activity is | little more than the HTTP server code from the Read activity, made more generic. | | Cool. | | Distribute should be able to open _all_ journal entries. Therefore, I would | like to associate it with all mime types. How can I do this, with activity.info | or mimetypes.xml? | | What do you mean by open? You want Distribute to appear as an activity | able to start with all journal entries? Right. | I don't see a way of doing this | without hacking the journal (could be a simple hack, though). | | Another possibility would be for the user to start Distribute as a blank | activity, and then choose the object to share with the ObjectChooser | component. Isn't the ObjectChooser also supposed to be filtered by mime type? | | Some other people were interested in working on something similar (me | included), should we try to join our efforts? I remember SJ, Mako, | Michael, Scott and Chris showed interest at some point. I'm happy to work with others on this. Currently, my code is quite literally Read, without Evince. I cannot test it, because all the jabber servers are down and I'm missing one of my XOs, but I suspect it does not yet work. Ultimately, this is supposed to be a quick hack, to be replaced in future versions by distribution functionality built into Sugar. That makes design decisions (like ObjectChooser vs. launch from Journal) even more difficult, since the right answer may not be the best choice. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHuwJpUJT6e6HFtqQRAuiFAJ9Ui1GMSw7elBxRMOWU3qR92jAA1QCcDENh GeS7anGyxGo1fqAQboC3fKc= =Fo0D -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Disconnected backups.
On Tue, 2008-02-19 at 13:08 -0500, Chris Ball wrote: * Encryption/privacy probably isn't desirable here -- we're dealing with objects that the user has chosen to have backed up. The Bitfrost spec refers to this as a primary backup. It is inevitable, since in the case of hardware failure, any encryption key would be lost along with the data. Also, this would provide a good way for kids to turn in homework to their teachers: the teacher passes around a USB key, and as each child inserts the key, their homework gets automatically copied over to a directory named after them if it's marked favorite. Strongly disagree. This is precisely what the mesh is for. If handing in homework is an important, unsolved use case, we should solve it in software. It would also be good to have some consensus from the deployment team that this (backups without a school server) is something that's going to be needed and is worth spending time on. As a student growing up in the '90s, I know that my friends and I endured completely unreliable computers that routinely ate our homework due to hardware and software failures. Nobody made backups. It was still a huge improvement over typewriters or handwriting. For children, data loss is simply not a big problem. Backups are nice, but they are only critical if the government says so. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] GTK/pango fonts and non-european languages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I use monospace fonts to render numeric fields in each of my activities. For example, at one point to set the font for a label I use: valuefont = pango.FontDescription() valuefont.set_family(monospace) valuefont.set_absolute_size(300*pango.SCALE) self.value.modify_font(valuefont) This works perfectly in European LOCALEs. In Arabic, the resulting font displays Western-style Arabic numerals, but in a font that is script-like and definitely not mono-spaced. Is this correct behavior? What is the recommendation regarding monospace, numeric displays, and non-european locales? - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHr6yLUJT6e6HFtqQRApYPAJ4mxTETG4aw8abZhY8BK1Xuj487EQCePxQf teZN5AYyBB5NDNHk+GnS3Rg= =og0p -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] how to take a screenshot?
On Tue, 2008-02-05 at 13:51 -0500, Erik Blankinship wrote: Can someone suggest how to take a screenshot from within a sugar activity? Alt+1 , I believe --Ben. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] DBus-python and signals with changing types
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John (J5) Palmieri wrote:
Perhaps you are going about it the wrong way.
Indeed.
First of all decorators
are executed when the method is parsed, way before the class is
instantiated so you will get an error there.
True.
Also by sending different
signatures you are going to be giving back false introspect information
and basically making it harder for non-dynamically bound languages to
communicate with you. Also why would you make an external app specify
byte array or not?
I am writing a library for Python Activity developers. I would like to provide
the necessary plumbing to ensure that Activities can share a unified data model
in the face of arbitrary network problems, including unexpected group splits and
merges. Thus, I am writing code that talks over D-Bus tubes, but is sending
messages whose type is controlled by whoever is using the library. Since I do
not know that developer's types or preferences ahead of time, I would like to
allow them to control the types, and also message parameters (such as
byte_arrays and utf8_strings).
After talking to Simon McVittie, it seems that I can come close by setting all
my signatures to variant. The user may then either trust the introspection, or
set dbus types explicitly by constructing messages in this style:
dbus.Struct(('a', 42), signature='su')
This doesn't solve the byte_arrays problem, but that is less important.
Something that would be nice, in the future, is support for programmatically
generated interfaces. For example, Java now has support for parameterized
interfaces. Python is much more dynamic, but there is no support in dbus-python
for setting the interface at constructor-time. That would be an improvement,
though still not as Pythonic as setting the types on each call.
- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHpyZ0UJT6e6HFtqQRAi5BAJwK6PDXcXnfhr7cyZe7XJptBdWX8wCfVFQx
2//lakThgxl4LkGTNp3752Q=
=g6F6
-END PGP SIGNATURE-
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
[sugar] DBus-python and signals with changing types
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I would like to create a simple D-Bus signal of the form @dbus.service.signal(dbus_interface=self.IFACE) def send(self, message): return However, I do not know the type signature of message ahead of time. I also do not know whether the user wants byte_arrays=True, etc. I would like to set these parameters each time send() is called. How can I do this? The only way that I have thought of is to do: def send(self, message, signature=None, byte_arrays=True): self._sig = signature self._ba = byte_arrays self._actual_send(message) @dbus.service.signal(dbus_interface=self.IFACE, signature=self._sig, byte_arrays=self._ba) def _actual_send(self, message): return Will this work? Is it threadsafe (I think not)? Is there a better way? - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHpic9UJT6e6HFtqQRAnHjAJ9u4TwZ2kYN7+tYwvw10gMmFJE/OQCeNXjg 7LDPkt8lU4jG1o/ZBgk9vE4= =Vzmh -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Printing et al.
On Fri, 2008-01-04 at 13:40 -0500, Jim Gettys wrote: Sample 1: OLPC Trial School in Arahuay, Peru: Needs printing: but not for the kids (too expensive) for any routine printing. The teachers need to be able to use an XO for preparing tests and handouts for the kids, as conventional computers are not available in sufficient quantities (there is 1 conventional desktop system at the entire school). Printing should serve as a reminder of missing functionality in Sugar. Handouts and tests should not require printing; they should be accomplished within Sugar without even needing a server. At the moment, this is possible, but quite inconvenient, because there is no way to transfer instances non-collaboratively. Currently, to work on a test, which might be nothing more than a Write document, students would have to join, keep the instance, close it, and resume it from the Journal, in order to ensure that they do not edit the master copy. When they are done, they must share it by invitation with the teacher, who must accept, keep, and close. This is very inconvenient. Given an easy way to transfer activity instances non-collaboratively, and pen-tablet support, almost all tests (and handouts) should be convenient to distribute, complete, and return. To streamline the process further, we might consider: 1. Pre-authorized Push support, so that, once authorized by the student, teachers may send content to students without student action. a. Groups, so that something may be pushed to the whole class at once. b. pushback support, so that students can send the completed test back to the teacher without requiring teacher confirmation. 2. An activity for creating and taking written/drawn exams a. time limits b. lockdown, to prevent Chat-ing with other students during the exam (now there's a good topic for debate...) I understand that many of these features are planned, but clearly this is a high priority for the customers. Simple non-collaborative transfer should be in Update.2. --Ben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
