Re: [sugar] another response time
On Wed, Oct 1, 2008 at 2:39 AM, Mikus Grinbergs [EMAIL PROTECTED] wrote: Launched XaoS-2 (on 766). The activity is being launched screen pulsed and pulsed for a couple of minutes. I had definitely concluded that it would *never* launch, and that this was the Sugar launch timeout that kept the screen pulsing -- when suddenly the XaoS activity screen was drawn. It is likely that some people will not have the patience to wait that lng. [How *could* they tell whether the pulsing would end well, or would not end well ?] Hi Mikus, as you probably installed previously the Wikipedia activity, my guess is that the jffs2 gc thread was taking most of the CPU. Sadly, we can expect greatly reduced overall system performance after any significant allocation or deallocation of flash space. This means to testers that before reporting any Sugar slowness, should be checked with top that the jffs2 gc is not taking cpu. It's not my area, but I guess this only will be solved when we move to another fs, hopefully by 9.1. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] evince/poppler
Simon Schampijer wrote: Hi, we are using an old version of evince and poppler. Are there any intentions to update? Current poppler we use is 0.6 and the latest stable is 0.8 http://poppler.freedesktop.org/ And in jhbuild we use a custom evince branch http://dev.laptop.org/git?p=users/rwh/evince;a=summary Thanks for clearing up, Simon Hah, found the answer :) http://dev.laptop.org/ticket/7926 Best, Simon ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] another response time
as you probably installed previously the Wikipedia activity, my guess is that the jffs2 gc thread was taking most of the CPU. If I understand correctly, this raises the possibility that other actions performed *prior* to the launching of an Activity can noticeably affect the time it takes to launch that Activity. Would someone else please launch XaoS, and see what kind of response time for the launch they get? Tried it again, after the XO had sat there overnight (having now hopefully done everything it needed to, for jffs2 housekeeping). For me, the launch screen for XaoS pulsed for 100 seconds before the activity screen was drawn. [My guess is that it is calculating the fractal picture before showing it.] mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Image Viewer Activity
On Wed, Oct 1, 2008 at 9:22 AM, Gary C Martin [EMAIL PROTECTED] wrote: On 29 Sep 2008, at 17:13, Sayamindu Dasgupta wrote: A screenshot is at http://dev.laptop.org/~sayamindu/Captura%20de%20pantalla_1.png The code lives in Git: http://dev.laptop.org/git?p=users/sayamindu/imageviewer-activity;a=tree Comments, patches and brickbats are welcome :-). No brickbats (or patches), but just wanted to report one (very minor) Image Viewer misbehaviour. I noticed today that if I open an image, and then rename it within Image Viewer, it generates one of those Keep Error warnings about loosing all changes. The new name does actually change correctly. This error seems to crop up on a number of activities so I'm not sure if it's a Sugar bug or some common issue catching out Activity authors. Yeah - I'm waiting for Tomeu's new datastore to land in sugar-jhbuild, so that I can fix that. Regards, --Gary P.S. No one seems to have raised any issues yet with the icon sample I posted, so if you're happy with it, and I get no other feedback, I'll turn it into a SVG at end of tomorrow (though I may also try a version with a looking-glass partially over the image frame). The one you sent looked quite nice enough. I think that should be enough for now :-D Thanks a lot, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] human factors when launching an activity
Last night did a lot of activity launching (on 766). My overall impression was that feedback by the system was way too slow. The pulsing launch screen (which I like) was introduced to give positive feedback to the person clicking on an activity's icon - but the system was taking much too long to begin showing that screen. When launching from Home View, I found the most reassuring way to launch was to RIGHT-button click on the icon, wait for the palette, then right-button click again on 'Start'. The disappearance of the palette was a positive indication that my launch request had been accepted. The problem was that I had learned to left-button click - remembering to right-button click was difficult. If I left-button clicked on the icon, all I could do was wait for the pulsing screen to appear. Several times, looking later at Frame, two instances of the activity had been launched (perhaps my hands are more spastic than I thought). [There was ALWAYS a time interval between my click and the showing of the pulsing screen.] If I remember correctly, I even had instances where the pulsing screen did not appear. [And there definitely were instances where the activity showed *its* screen -- I worked with it and then closed it -- and then the pulsing launch screen was shown again -- I had to wait for the pulsing to time out and go away.] All in all, not confidence-inspiring. When launching from Journal view of a removable storage device, I concluded afterwards that Journal was first installing the activity in /home/olpc/Activities, and only then launching it (i.e., showing the pulsing screen). That could mean a wait of a minute before seeing the pulsing screen. NOT good human factors. mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Filesystem path ordering overrated.
C. Scott Ananian writes: The response usually is that additional context is sufficient to disambiguate tag sets, you don't actually need ordering. That is, it's okay if a/b is indistinguishable from b/a -- in practice one will really be c/a/b and the other will be b/a/d or whatever, and you can use the extra tag 'c' or 'd' to disambiguate. Two big problems with this: 1. usually means on rare occasions we overwrite your files 2. Getting excess files is a problem. Imagine trying to use this (perhaps with a FUSE filesystem) with a Makefile $(wildcard *) or shell *. Extra files show up and get processed in some way. Maybe it's rm -rf foo/bar/* even. There is also the matter of assuming that tags are easier to handle than directories. The fact that some people struggle with directories does not automatically imply that any alternative will be easier. I tend to find tags more difficult in fact; they are disordered by nature and that's a disorganized mess. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] human factors when launching an activity
On Wed, Oct 01, 2008 at 09:52:24AM -0400, Mikus Grinbergs wrote: Last night did a lot of activity launching (on 766). My overall impression was that feedback by the system was way too slow. In my experience the feedback is very fast (less than 1s to come up, which is hard to ignore unless you're double-clicking). About two weeks ago I had this same impression as you do now, though, before I noticed that it was because the datastore was busy indexing a few kernel build trees on two usb drives I had plugged in. When I stopped plugging those drives in[1], the problem went away and the activity launching feedback was very acceptable. Are you sure that the machine is otherwise idle when you're experiencing these undesireable delays? Martin 1. Or just forcibly unmounting them from the datastore (but not the actual filesystem, IIRC), by doing something like: dbus-send --session --print-reply --reply-timeout=2000 \ --type=method_call --dest=org.laptop.sugar.DataStore \ /org/laptop/sugar/DataStore org.laptop.sugar.DataStore.unmount \ string:datastore mount id ...for example, ugly little script to tell the datastore to unmount all the plugged in devices: #!/bin/bash datastore_mount_ids=`dbus-send --session --print-reply --reply-timeout=2000 --type=method_call --dest=org.laptop.sugar.DataStore /org/laptop/sugar/DataStore org.laptop.sugar.DataStore.mounts | grep 'string [0-9a-z]\+-' | cut -d '' -f 2` for id in $datastore_mount_ids ; do echo -n ds unmount $id... dbus-send --session --print-reply --reply-timeout=2000 --type=method_call --dest=org.laptop.sugar.DataStore /org/laptop/sugar/DataStore org.laptop.sugar.DataStore.unmount string:$id done pgpKpaloLhLid.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] another response time
Yeah, this sounds like something that should be added to the HIG. Activities should strive to put up a screen as soon as they can, even if it will take more time to fully present the UI or the content. I opened #8739 to keep track of this, when I get a chance to get back into the HIG. - Eben On Wed, Oct 1, 2008 at 8:49 AM, Mikus Grinbergs [EMAIL PROTECTED] wrote: as you probably installed previously the Wikipedia activity, my guess is that the jffs2 gc thread was taking most of the CPU. If I understand correctly, this raises the possibility that other actions performed *prior* to the launching of an Activity can noticeably affect the time it takes to launch that Activity. Would someone else please launch XaoS, and see what kind of response time for the launch they get? Tried it again, after the XO had sat there overnight (having now hopefully done everything it needed to, for jffs2 housekeeping). For me, the launch screen for XaoS pulsed for 100 seconds before the activity screen was drawn. [My guess is that it is calculating the fractal picture before showing it.] mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] another response time
On 1 Oct 2008, at 13:49, Mikus Grinbergs wrote: as you probably installed previously the Wikipedia activity, my guess is that the jffs2 gc thread was taking most of the CPU. If I understand correctly, this raises the possibility that other actions performed *prior* to the launching of an Activity can noticeably affect the time it takes to launch that Activity. Would someone else please launch XaoS, and see what kind of response time for the launch they get? Tried it again, after the XO had sat there overnight (having now hopefully done everything it needed to, for jffs2 housekeeping). For me, the launch screen for XaoS pulsed for 100 seconds before the activity screen was drawn. [My guess is that it is calculating the fractal picture before showing it.] Hi Mikus, XaoS on my XO B4, launches instantly. No seriously, it's absolutely the fastest launching activity. Here's the rub, because its so quick, it even beats the launcher window getting going, the working activity is hidden behind the launcher pulse effect window, which now can't tell that the activity is actually already running so does its blind 'I'll sit here and strobe for a fixed time-out because I have no idea what happened.' Take a look in the frame and you'll see the default grey circle that you can switch to. Worth a ticket if there's not one already, it's an interesting case in how quick XO-1 HW really is with the right software (must be and absolutely massive price being paid currently for having the Pyhton environment I'd guess, but I'm sure there is a whole heap of optimisation to be made if/when made a dev cycle focus and team resources made available). Made some great strides for 8.2, fingers crossed for 9.1. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] another response time
On Wed, Oct 1, 2008 at 2:15 PM, Gary C Martin [EMAIL PROTECTED] wrote: On 1 Oct 2008, at 13:49, Mikus Grinbergs wrote: as you probably installed previously the Wikipedia activity, my guess is that the jffs2 gc thread was taking most of the CPU. If I understand correctly, this raises the possibility that other actions performed *prior* to the launching of an Activity can noticeably affect the time it takes to launch that Activity. Would someone else please launch XaoS, and see what kind of response time for the launch they get? Tried it again, after the XO had sat there overnight (having now hopefully done everything it needed to, for jffs2 housekeeping). For me, the launch screen for XaoS pulsed for 100 seconds before the activity screen was drawn. [My guess is that it is calculating the fractal picture before showing it.] Hi Mikus, XaoS on my XO B4, launches instantly. No seriously, it's absolutely the fastest launching activity. Here's the rub, because its so quick, it even beats the launcher window getting going, the working activity is hidden behind the launcher pulse effect window, which now can't tell that the activity is actually already running so does its blind 'I'll sit here and strobe for a fixed time-out because I have no idea what happened.' Yes, ticket please! =) Thanks for the report. Take a look in the frame and you'll see the default grey circle that you can switch to. Worth a ticket if there's not one already, it's an interesting case in how quick XO-1 HW really is with the right software (must be and absolutely massive price being paid currently for having the Pyhton environment I'd guess, but I'm sure there is a whole heap of optimisation to be made if/when made a dev cycle focus and team resources made available). Made some great strides for 8.2, fingers crossed for 9.1. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] adding versions to journal/datastore
On Mon, Sep 29, 2008 at 3:54 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Hi Eben and other sugarites, I'm trying to find a simple way to add some version support to the journal, but for that I need to know what's the sweetest spot (no pun intended) between value and complexity. I'm thinking about making the next notable changes to the UI: - the journal list shows one line per interesting entry. Interesting entries are tips of branches and a branch is created every time the user clicks the Keep button or resumes an entry. Activities can also choose to make a branch in behalf of the user at any moment, for example just before the user selects Erase all in Paint, I'm want to become a bit clearer with your terminology, because I'm not sure that branches line up in my mind. I agree that we could/should have a number of incremental saves which are created within a given activity session. The latest of these would be promoted to a new interesting entry should the activity crash, or the machine restart, etc. I agree that upon closing an activity session, or pressing the keep button, a new interesting entry is created, also. I'm unsure, however, that each of these entries represents the tip of a branch, or that only the tip should be shown. Should a branch only be created when the user duplicates an entry or keeps a copy? A branch would certainly be created when resuming an old entry (not the tip/top entry), but would you branch when the top entry itself is resumed? Also, to clarify, in your vision would resuming a given activity instance (always from the tip, let's assume) several times result in a new interesting entry for each, or would you collapse it into a single entry unless a branch is made? While this results in fewer entries in the Journal, it defeats the idea of the Journal as a historical record of versions, instead making it a flat folder sorted by modification date. - in the detailed view of an entry, all its ancestors are displayed in a list, including non-interesting entries, The latest designs actually include a popup menu in place of the date, which allows one to select versions of the document by date without exposing the whole list permanently in the view. Ideally, this list would include icons which indicate those which have been starred, so that digging through a potentially long history is easier to manage. Walter, could you elaborate on your comment? - Eben - and that's it ;) Eben: is that too simple? If it's enough, I'll propose an API for it. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] adding versions to journal/datastore
Walter, could you elaborate on your comment? My comment was in regard to the anticipated additional complexity we may run into if/when we have versioning between multiple users, as would be dictated by most of the bulletin board schemes. Not sure if Tomeu's model will work, but it doesn't seem a bad first step. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] adding versions to journal/datastore
On Wed, Oct 1, 2008 at 3:49 PM, Walter Bender [EMAIL PROTECTED] wrote: Walter, could you elaborate on your comment? My comment was in regard to the anticipated additional complexity we may run into if/when we have versioning between multiple users, as would be dictated by most of the bulletin board schemes. Not sure if Tomeu's model will work, but it doesn't seem a bad first step. I see. I think we partially circumvent the complexities by restricting the notion of versions to, in the end, a flattened tree. That is, the user isn't concerned with the details of branching structure. Instead, the most recent version (from any branch) I've resumed is the one that sits at the top of my Journal. This is consistent with the Journal as a time-based structure, because the tip of that new branch I created was created last in the timeline. When you have several kids, potentially with different versions of the same activity, they can all get back together, do manual merges, and then continue work in whichever instance they choose. When they all stop working on that implicitly agreed upon true version, that then becomes the tip, and the latest entry for all of them in the Journal. This model does, of course, eliminate (at least with the current UI proposal) potential advantages of a truly hierarchical versioning scheme, but I think it simplifies specifically to the point you raised earlier, which is that the last thing I did will be the most important thing to me. - Eben PS. The one place this causes problems is when you go back to an old version, rename it with the intent to use it as a base for a completely different project, and then work from there. In this case, you really want to have a new root node, instead of a new version. We should discuss the implications here, and if we might want to create a copy (a new root node that contains the contents of the copied node) on rename. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ 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] human factors when launching an activity
On Wed, Oct 01, 2008 at 03:06:34PM -0400, Mikus Grinbergs wrote: [many rhetorical questions] dbus-send --session --print-reply --reply-timeout=2000 \ --type=method_call --dest=org.laptop.sugar.DataStore \ /org/laptop/sugar/DataStore org.laptop.sugar.DataStore.unmount \ string:datastore mount id THIS is what I have the greatest amount of difficulty with. I fail to see the necessity of users having to learn the internals of dbus usage in order to be able to control their systems. If there is a knob that users need to turn, DOCUMENT IT !!! The journal UI lets you unmount one device already. It's documented already. Why is another way of doing it, automatable and suitable for very advanced users doing unusual things (like you), causing you difficulty? Besides which, I have my removable storage devices mounted __for a purpose__. [They contain software and data which I reference every time I use the system.] I have no intention of unmounting them. So I'm puzzled as to why would you single out the launch feedback feature. I now understand that your XO's cpu is busy for reasons that you know about, and you're just noting that one UI feature that depends on being able to run quickly doesn't run so quickly when the cpu can't run it quickly. And that that happens only when you do something that most people don't do. Of course it'd be great if people could do that without such deleterious effects. mikus Martin pgpNTLJmSHqXW.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
