Re: [sugar] Finding cursors. Ripples in a puddle?
On Mon, Nov 24, 2008 at 08:27:26PM -0500, Ken Ritchie wrote: Does anyone else recall recurring debates about cursor size and the effect on one's ability to visually discover the location of a cursor? Yes, there are tradeoffs between simply making cursors larger (easier to discover location) or making cursors smaller (easier to place precisely, eclipses fewer pixels)...especially when the pointing devices are other than by directly touching the display screen. Such is the case with the present XO laptops. To sidestep those debates, I imagine a different way -- one in which cursors could be of any size, color, shape, etc. -- and yet still draw my eye quickly to the locus of the current cursor. VISION: Each time my finger tip lands on the touch pad I see a circular wavefront (on the display, of course) briefly emanating from the point of the cursor. The wave gently fades as it grows and dissipates. Thus, it appears as if the screen is overlaid with a clear puddle and I have lightly touched its surface. The effect could be simulated with a simple ring; probably a simpler and cheaper computation than a wave effect. A bitblt series would do. Like ripples in a puddle, the visual effect and conceptual metaphor would seem to draw on nearly universal human experience from early childhood. Of course, the HCI labs around the world could experiment with such effects (if not already) to understand the human factors and optimize the man-machine interface. Meanwhile, it seems worth trying, pragmatically. ;-) Back in the olden-days, when I used windows, I remember a function which would make it so pressing both control keys would highlight the mouse by making little concentric rings around it. I doubt it would be very difficult to do if you were interested in a bit of Xlib hacking. Erik ___ 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]
On Thu, Oct 30, 2008 at 03:09:16PM -0400, Benjamin M. Schwartz wrote: -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 far more than its data storage system and a security model. It is a community of people trying to build a very usable computing environment specifically geared toward use in an educational setting. I think that this community should continue; I don't want to derail it! I want to help it be more effective at its core goals. If writing our own data storage systems and upstream-incompatible security models frustrates the fundamental things that Sugar wants to do (among which I believe lie the requirements which I listed), then we should reconsider devoting resources to such tasks. I think there is ample evidence that this is the case. 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. I don't think we should be coupling important features of computer use, such as data storage and retrieval, to systems that are relatively untested or still under heavy development and design. By making the datastore and Journal lynchpins in the system we have caused serious issues for users. There are small changes we can make to the system design which resolve this issue by decoupling data browsing and data storage. The obvious system to use is the underlying POSIX filesystem. That said, I can find no clear reason why the unique work which we want to do cannot happen on top of such a stable base layer. Why does the use of files preclude the Journal and our unique metaphor for stored data? Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Data Storage and User-facing System Requirements [was Re: 9.1 Proposal: Files]
Thank you to the repliers to my original proposal. I missed a crucial
point--- which is that I must clearly draw the lines of connection between
user-facing requirements and the solutions provided by my proposal. I
am rewriting it with this pattern in mind. If you wish to reply on the
mailing list, please write *one* email per point, lest things get too
crazy. (I will post on the OLPC wiki shortly and reply with a link.)
Proposal:
Allow activities which run under Sugar to write regular POSIX files.
Where sensible and possible with respect to user-facing requirements,
restructure our systems to expect them to behave as such.
I am basing this proposal off the idea that the system has at very least
the following requirements. The system (Sugar on the XO) should:
1) Be Bug-free, stable
2) Allow users to save data
3) Allow users to find data later
4) Allow users to share data (collaborate)
5) Afford users wide choice in the applications they can run
6) Allow users to modify the system
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. For practical reasons this has immediate
rammifications for the requirements 1-5 listed above. I will now
discuss the use of file with respect to these requirements:
1) Be bug-free, stable:
Every line of new code written must be learned (both in effect and in
document) by everyone who wants to work within the framework it creates.
Provided this, it is preferable to write less code on our own, and share
existing solutions and design patterns with the larger open source
software development community. I base this in the commonly accepted
FLOSS theory that, provided feedback systems which connect users and
developers, bugs are a function of users, time, code complexity, and
changes to the codebase over time. Roughly:
complexity * changes
== number of bugs
users * time in use
Following this theory, writing our own systems decreases (users * time
in use) and increases (complexity * changes), thus increasing the number
of bugs. Using an existing system applies roughly the same bug function
found in that system to our case, provided our specific use doesn't
markedly increase complexity in code paths.
2) Allow users to save data:
Our users have potentially unique sub-requirements on this point. I
have gleaned the following from listening to discussions on olpc-related
mailing lists and in IRC logs. The system must:
a. Automatically save data.
b. Encourage use of names to make it easier to find things.
c. Don't require names for things for which naming is tedious or
unnecessary, such as photos.
Currently we meet all these features, but the implementation which we
use to do so has caused issues for users in some regards:
a. Automatically saving everything confuses users by mixing things
which they find important and things which they don't care about (the
'journal spam' problem).
b. We don't encourage naming strongly enough, even though doing so is
incredibly simple in the current UI. This confuses users when they try
to find things later.
c. We do this very well, but the lack of distinction in how we display
items in the Journal has caused issues for users (e.g. it is necessary
to click on photos to see previews of them instead of having the photos
visible in the top-level view).
Generally I have heard that most people thing we need to resolve (a) and
(b) by more strongly encouraging naming. (c) is little discussed, but
is something that 'traditional' file browsers such as Nautilus seem to
do quite well.
My impression is that if we switch to a 'stronger enforcement of naming'
scheme we may resolve (a) and (b). But also I note that switching to a
stronger enforcement of naming brings us much closer to the 'save named
files' pattern under which non-sugar applications function.
3) Allow users to find data later
Sugar's Journal is built around the idea that it should be easy for
users to find data they have produced. The exposition of this
requirement would be:
a. Provide application(s) which allow for the browsing and location of
past work in unique ways (search, tagging, metadata). The current
Sugar Journal is an example. Other similar examples are Beagle,
Tracker, and Pinot.
To help users find data later we must provide a way to browse all data
creation events on the system. This implies a need to index all data
events. We have chosen a design in which we log all user data events
by providing
[sugar] pie menus
Pie menus seem to be an innovative, unique, and potentially highly user-friendly way of presenting a user of a graphical interface with complex sets of options. There was some work on them, ostensibly by a community developer, but I only just heard about them today from Seth Woodward and was wondering what their status was in terms of being a potential future feature in Sugar. Is this a direction which the UI could potentially head? It seems quite applicable. See: http://www.donhopkins.com/drupal/taxonomy_menu/4/49/14/18 and the associated design pages, which has a lot of links to papers and abstracts: http://www.donhopkins.com/drupal/taxonomy_menu/4/49/14/19 Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] 9.1 Proposal: Files
By reintroducing the concept of files to our systems we can simplify our work in a number of areas relative to 8.2: - Compatibility with existing applications: One of the principal reasons that the tens of thousands of open source applications that run on Linux aren't usable under Sugar is that we have a custom API for saving data. To make them usable we have to exert developer effort for every ported application. This does not scale and is not sustainable as we are completely alone in this effort. Furthermore, reintroducing files to our APIs will simplify the process of running Sugarized apps in non-Sugar environments, and provide consistency to users who use them both within Sugar and outside. - Data access, user-perceived reliability: Using files forces users to be intentional about saving data (they must name their work). This makes it easier for them to find things they care about--- provided, of course, that they are taught how to save files as students are in virtually all computer-based education. - Resting on upstream stability: Files are used virtually everywhere else in the computing world, and most certainly in our upstream distributions. Using files means we have the same problems as upstream, and no more. If there is a filesystem integrity problem in the Linux kernel filesystem drivers we can more readily expect the aid of upstream users and developers in resolving the issue than we could expect such aid in the case of a custom data storage system. - Collaboration: Many collaboration issues could be resolved by exposing file-based asynchronous collaboration to users. Files are the core component of collaboration in every other computing environment in common use. Using them as a primary storage system will greatly simplify the process of sharing between an XO and a non-XO. - Hackability: From the beginning of this project there has been a lot of hype about the hackability of the system (Sugar) relative to other computing environments. Python was chosen as a programming language for the environment because of its legibility and ease of use, and we are still supporting it for this reason. However, it is unclear how hacking is supposed to proceed within Sugar without some exposure to the underlying filesystem. Even if it is possible to do via the Terminal, we are not making it easy for users to start by providing two incompatible views on data. - System modularity: Files are a common abstraction which allows the interaction of any applications which can do file I/O. Using user-named files as a base-layer storage system, and not a database or hash-based file naming scheme, allows us to decouple the application which saves data from those that are used to search and index it. I propose that 9.1 include a very simple (perhaps default) way to save files to the user's home directory, and that it also include a file manager skinned or redesigned to work well within Sugar. The most reasonable thing may be to simply save files into the user's home directory if the user explicitly names/saves their work in a given application. Sugarized apps which use the Sugar Activity API can be trained to auto-save files into an auto-save directory of some kind, from which data is eventually deleted if it is never accessed again by the user or tagged/named. Auto-saving seems to be a very important feature for kids--- but so is intentional saving, as it is a common feature on every computing environment in common use and consequently has great educational importance. To provide coherent access to these files we can index them and use the Journal or a compatible index browser for search and data access. I further propose that we use a webserver with a directory listing to enable asynchronous, file-based collaboration between any two XOs on the same network [1]. Doing such would also enable collaboration between XOs and non-XOs. If we want to enable a more interactive collaboration system of this nature we can investigate the use of WebDAV or an equivalent system. I also propose that to enact this solution we relax the security system which is used to sandbox applications running on Sugar. There are certainly ways to keep the security system and enable the use of files, but all of them are by definition more complicated from a development standpoint than relaxing the security system and simply letting applications write to user-owned directories. Erik [1] http://lists.laptop.org/pipermail/devel/2008-October/020660.html ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] The XO laptop gets a Windows makeover
On Sun, Oct 26, 2008 at 9:50 PM, Carl-Daniel Hailfinger [EMAIL PROTECTED] wrote: Hi Robert, On 27.10.2008 00:57, [EMAIL PROTECTED] wrote: On Oct 26, 2008, at 4:09 PM, Albert Cahalan wrote: Means of file sharing can be setup fairly easily in Sugar if you want to move raw files around. Currently file sharing is performed through activity sharing. Does setup fairly easily mean someone has to write a program (activity) to do it? If yes, it's not easy (yet). Will it work with arbitrary binary files? We can do asynchronous file-based collaboration intelligently. I am currently thinking about a very simple solution which can be hooked into Sugar to allow users to view each other's files provided they are both on the same network (mesh, router, wired net, etc.). The mechanism I am considering will work as follows: 1) User clicks on another XO icon in the Neighborhood view. 2) Browse is opened and pointed at a specific port on the IP of the XO. 3) A web browser on the 'host' XO sends a directory listing of the user's share/home/journal folder to the 'client'. 4) The client user can download whatever file they wish to share. 5) The client then opens the file in a suitable application. To satisfy privacy concerns, we could provide three configuration options to users: - Share all: share the entire user's home directory tree. - Share only: share only files and symlinks explicitly added to a 'share' directory. These copies or links could be enabled using a menu option in whatever data browser runs on the system. - Share nothing: don't run the webserver. Such a scheme would simultaneously open the collaborative possibilities offered by the mesh and cut the gordion knot of collaboration systems and APIs, allowing any computer with a web browser to enter the collaborative arena! This scheme would make it easy to collaborate asynchronously between Sugar and non-Sugar environments. To implement this it would be sufficient to provide a web interface to the journal. I believe a modular, file-based solution would be preferable from a programming and maintenance perspective, but the opaque nature of the filesystem from the users' perspective stands in the way. I am hoping that in 9.1 we provide users the capability to save files to their home directory by giving their activity instances names. (Perhaps we could autosave everything else, but delete it after some time period of non-use.) This would make it possible to provide collaboration by setting the webserver to provide a directory listing of the user's home instead of writing a specialized interface to the journal. This would make it much easier to find and extend existing upstream systems which do the job well to meet the specific needs of the XO. I am also hoping that it will be easy for users to run applications on files obtained from non-local, non-journal/datastore sources. Currently doing so is impossible from the Sugar GUI. A third hope is that our security model can be relaxed to allow the launching of an application against a file downloaded via a web browser. This would eliminate a step (back into the journal or file browser) to open a file from a remote source. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] The XO laptop gets a Windows makeover
On Sun, Oct 26, 2008 at 9:50 PM, Carl-Daniel Hailfinger [EMAIL PROTECTED] wrote: On 27.10.2008 00:57, [EMAIL PROTECTED] wrote: On Oct 26, 2008, at 4:09 PM, Albert Cahalan wrote: Means of file sharing can be setup fairly easily in Sugar if you want to move raw files around. Currently file sharing is performed through activity sharing. Does setup fairly easily mean someone has to write a program (activity) to do it? If yes, it's not easy (yet). Will it work with arbitrary binary files? We can do asynchronous file-based collaboration intelligently. I am currently thinking about a very simple solution which can be hooked into Sugar to allow users to view each other's files provided they are both on the same network (mesh, router, wired net, etc.). The mechanism I am considering will work as follows: 1) User clicks on another XO icon in the Neighborhood view. 2) Browse is opened and pointed at a specific port on the IP of the XO. 3) A web browser on the 'host' XO sends a directory listing of the user's share/home/journal folder to the 'client'. 4) The client user can download whatever file they wish to share. 5) The client then opens the file in a suitable application. To satisfy privacy concerns, we could provide three configuration options to users: - Share all: share the entire user's home directory tree. - Share only: share only files and symlinks explicitly added to a 'share' directory. These copies or links could be enabled using a menu option in whatever data browser runs on the system. - Share nothing: don't run the webserver. Such a scheme would simultaneously open the collaborative possibilities offered by the mesh and cut the gordion knot of collaboration systems and APIs, allowing any computer with a web browser to enter the collaborative arena! This scheme would make it easy to collaborate asynchronously between Sugar and non-Sugar environments. To implement this it would be sufficient to provide a web interface to the journal. I believe a modular, file-based solution would be preferable from a programming and maintenance perspective, but the opaque nature of the filesystem from the users' perspective stands in the way. I am hoping that in 9.1 we provide users the capability to save files to their home directory by giving their activity instances names. (Perhaps we could autosave everything else, but delete it after some time period of non-use.) This would make it possible to provide collaboration by setting the webserver to provide a directory listing of the user's home instead of writing a specialized interface to the journal. This would make it much easier to find and extend existing upstream systems which do the job well to meet the specific needs of the XO. I am also hoping that it will be easy for users to run applications on files obtained from non-local, non-journal/datastore sources. Currently doing so is impossible from the Sugar GUI. A third hope is that our security model can be relaxed to allow the launching of an application against a file downloaded via a web browser. This would eliminate a step (back into the journal or file browser) to open a file from a remote source. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] 9.1 Proposal: Performance
Proposal, Implement the following hacks for a big performance boost from the XO+Sugar user perspective. Other systemic changes which could be made to improve system performance from the user's perspective. Discuss. Erik http://lists.laptop.org/pipermail/devel/2008-October/020404.html In short, I have bundled a set of 'hacks' which generally (and in my observation, dramatically) improve the user-perceived responsiveness of the Sugar UI. The hack bundle is available at http://dev.laptop.org/~erik/faster-hacks.zip I write requesting independent evaluation of the costs and benefits of these modifications. To test you *must* be running our current official release: 8.2-767. -== Contents ==- There are several 'hacks' included in this bundle: 1) optionally disable frame appearance on activity switching, if the file /home/olpc/no-frame-on-tabbing exists 2) optionally disable autosaving on activity switching, if the file /home/olpc/no-auto-save exists 3) optionally start the X composite manager (xcompmgr) on sugar startup to prevent the redraw of activity windows when switching from one activity to the other (if /home/olpc/use-xcompmgr exists). 4) compcache, http://code.google.com/p/compcache/, which makes a compressed block device usable for swap out of a chunk of RAM. By compressing unused pages this system may offset memory usage increases incurred by using composite. -== Usage ==- To install and test on an XO, open the Terminal activity and run: wget http://dev.laptop.org/~erik/faster-hacks.zip unzip faster-hacks.zip cd faster-hacks sudo ./install-faster-hacks Restart Sugar, then, if you'd like to test with compcache, run: cd faster-hacks sudo ./start-compcache Note also that you can adjust the amount of RAM (in kilobytes) devoted to compcache by passing an argument to ./start-compcache, e.g.: sudo ./start-compcache 5 By default it's set at 10Kb (~100Mb). You can enable hacks 1-3 while running Sugar by executing: ./enable-faster-hacks and disable with: ./disable-faster-hacks Effects will be immediately apparent. The changes in Sugar source files and installed executable (xcompmgr) can be reverted and removed with: sudo ./uninstall-faster-hacks This step is a failsafe and likely unnecessary; ./disable-faster-hacks should be sufficient to stop the effects and the size of the installed programs is negligible (30kb in xcompmgr). -== Discussion ==- Now continue to play with your XO as normal! Please report experiences and impressions. The 4 hacks are independent in operation and may be mixed and matched to achieve a variety of possible configurations. Keep in mind that these hacks present a tradeoff between existing features and UI responsiveness! The disabling of the frame removes a feature, but this feature (frame auto-appearance) may be unnecessary if we can rapidly switch between activities, as xcompmgr enables us to do. The disabling of autosaving removes a feature, but it drops the load on the processor which we incur when navigating between activities, thus improving switching performance. The use of xcompmgr represents a tradeoff between free RAM and system responsiveness. RAM is utilized to store offscreen framebuffers for each window in the X server. This obviates the need to have programs redraw themselves when they are switched into, dropping CPU usage during switching. But part of the RAM hit we incur by running xcompmgr may be offset by using compcache to provide a compressed swap partition-in-RAM. Comments more than welcome! Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] simple hacks to improve the performance of the Sugar UI
Per C. Scott's suggestion, I have created trac tickets for each of the first three items. A very old ticket exists for the 4th. On Fri, Oct 17, 2008 at 03:56:05PM -0400, Erik Garrison wrote: ... There are several 'hacks' included in this bundle: 1) optionally disable frame appearance on activity switching, if the file /home/olpc/no-frame-on-tabbing exists http://dev.laptop.org/ticket/8852 2) optionally disable autosaving on activity switching, if the file /home/olpc/no-auto-save exists http://dev.laptop.org/ticket/8853 3) optionally start the X composite manager (xcompmgr) on sugar startup to prevent the redraw of activity windows when switching from one activity to the other (if /home/olpc/use-xcompmgr exists). http://dev.laptop.org/ticket/8854 4) compcache, http://code.google.com/p/compcache/, which makes a compressed block device usable for swap out of a chunk of RAM. By compressing unused pages this system may offset memory usage increases incurred by using composite. http://dev.laptop.org/ticket/28 an old one! Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] simple hacks to improve the performance of the Sugar UI
On Sat, Oct 18, 2008 at 5:08 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Sat, Oct 18, 2008 at 7:35 AM, Andrés Ambrois [EMAIL PROTECTED] wrote: Just a couple of notes. [PATCH] sugar-homewindow-no-transition.patch This removes the usage of TransitionBox from HomeWindow.py. TransitionBox is used to animate the Xo Guy while moving between zoom levels. This patch makes transition from activities to the home box almost instantaneous and removes the annoying flickering. git master doesn't have an activity - home animation... I need to check if that's what Eben actually want though :) I'm also looking into fixing the flickering when closing an activity today. I have tried your hacks and I must say the frame behaves a lot better with compositing enabled. I haven't run any serious memory pressure tests, but I can have around 8-9 activities open before encountering OOM problems. No idea what the previous statistics were. Compositing will not make a huge difference about OOM. It's 2 mb per activity, so it would be something like 1.5 activities less you can run. The impact it's in theory going to have is to fill up VRAM and hence making graphics performance with a lot of activities open painful. I suggest testing xcompmgr without compcache (or with small/large RAM allocations for it). My impression is that when using xcompmgr, but not using compcache the upper limit in terms of number of activities before OOM was 5 or 6. I'm going to do a code review to better understand what compositing is doing with the window buffers. Also if anyone has advice about how to find where memory is getting stored (VRAM or RAM) please note. We need to test memory limits programatically but unfortunately there is a kernel bug which we're hitting in low memory situations in which the OOM killer is never invoked, but the system grinds to a halt. This will make automated testing of this aspect quite painful. Until we resolve this we can't just have the system look in the kernel messages for OOM events to help us test the limits. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 Proposal: Legacy compatibility.
On Fri, Oct 17, 2008 at 03:07:58PM -0400, C. Scott Ananian wrote: I'd like to present a few areas where sugar can play nice with others, including: * replacing the matchbox window manager, to provide better multiple-window support for legacy apps (think of the 'gimp', running as multiple windows without one full-screen activity area aka virtual desktop) * making sugar behave well when run in non-full-screen-mode under metacity. This includes refactoring home/friends/mesh view as operations on root window, so they make sense in a multiwindow setup. (It's been suggested that looking at the xpenguins code is instructive for understanding how nautilus,etc arrange their root window.) * Switch to standard freedesktop.org startup notification mechanism: ticket #5271 * Implement freedesktop.org notifications mechanism for alerts (low battery, low disk space, available software update) * Use standard fd.o notification area in frame -- I think this would also address cjb's desire to put the 'stop' button for recordmydesktop in the frame. I don't think I will actually have time to work on many of these areas in the 9.1 time frame, so I especially encourage interested/motivated parties to make concrete proposals on pieces of this work. (Or suggest other areas we should improve.) Perhaps we could also investigate the use of the xdg utilities for managing mimetype associations and installing activities? Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] simple hacks to improve the performance of the Sugar UI
XO Users, In short, I have bundled a set of 'hacks' which generally (and in my observation, dramatically) improve the user-perceived responsiveness of the Sugar UI. The hack bundle is available at http://dev.laptop.org/~erik/faster-hacks.zip I write requesting independent evaluation of the costs and benefits of these modifications. To test you *must* be running our current official release: 8.2-767. -== Contents ==- There are several 'hacks' included in this bundle: 1) optionally disable frame appearance on activity switching, if the file /home/olpc/no-frame-on-tabbing exists 2) optionally disable autosaving on activity switching, if the file /home/olpc/no-auto-save exists 3) optionally start the X composite manager (xcompmgr) on sugar startup to prevent the redraw of activity windows when switching from one activity to the other (if /home/olpc/use-xcompmgr exists). 4) compcache, http://code.google.com/p/compcache/, which makes a compressed block device usable for swap out of a chunk of RAM. By compressing unused pages this system may offset memory usage increases incurred by using composite. -== Usage ==- To install and test on an XO, open the Terminal activity and run: wget http://dev.laptop.org/~erik/faster-hacks.zip unzip faster-hacks.zip cd faster-hacks sudo ./install-faster-hacks Restart Sugar, then, if you'd like to test with compcache, run: cd faster-hacks sudo ./start-compcache Note also that you can adjust the amount of RAM (in kilobytes) devoted to compcache by passing an argument to ./start-compcache, e.g.: sudo ./start-compcache 5 By default it's set at 10Kb (~100Mb). You can enable hacks 1-3 while running Sugar by executing: ./enable-faster-hacks and disable with: ./disable-faster-hacks Effects will be immediately apparent. The changes in Sugar source files and installed executable (xcompmgr) can be reverted and removed with: sudo ./uninstall-faster-hacks This step is a failsafe and likely unnecessary; ./disable-faster-hacks should be sufficient to stop the effects and the size of the installed programs is negligible (30kb in xcompmgr). -== Discussion ==- Now continue to play with your XO as normal! Please report experiences and impressions. The 4 hacks are independent in operation and may be mixed and matched to achieve a variety of possible configurations. Keep in mind that these hacks present a tradeoff between existing features and UI responsiveness! The disabling of the frame removes a feature, but this feature (frame auto-appearance) may be unnecessary if we can rapidly switch between activities, as xcompmgr enables us to do. The disabling of autosaving removes a feature, but it drops the load on the processor which we incur when navigating between activities, thus improving switching performance. The use of xcompmgr represents a tradeoff between free RAM and system responsiveness. RAM is utilized to store offscreen framebuffers for each window in the X server. This obviates the need to have programs redraw themselves when they are switched into, dropping CPU usage during switching. But part of the RAM hit we incur by running xcompmgr may be offset by using compcache to provide a compressed swap partition-in-RAM. Comments more than welcome! Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] planning session for a technical conference for OLPC customers and community members
Mel Chua, Hernan Pachas and I will meet in #olpc on FreeNode at 1pm EDT to discuss a technical meeting for countries, community members, and OLPC customers in general. Such a meeting would be a forum to integrate feedback from the field with our work at OLPC. Hernan suggested the idea in late August but as of yet we have no plans to implement it: 11:24 hpachas-PE wad, jg , pienso que debemos estar mejor comunicados, y que cuando OLPC cree conveniente mejorar el sw, debemos reunirnos para que OLPC reciba el feddback de nosotros 11:30 hpachas-PE wad, jg : 1 o 2 veces al año, .. la diferencia entre los workshop que OLPC esta realizando, este workshop seria diferente. 11:30 hpachas-PE wad, jg : ya que seria una reunión técnica 11:31 hpachas-PE wad, jg : y OLPC debe anotar los puntos en los cuales todos los paises coinciden. y focalizarce en realizar esa mejora. Quick and dirty translation: 11:24 hpachas-PE wad, jg , i think that we should be in better communication, and when OLPC thinks it convenient to improve the software, we should meet so that OLPC can receive our feedback 11:30 hpachas-PE wad, jg : 1 or 2 times each year, the difference between the workshops that olpc is implementing, this workshop could be different 11:30 hpachas-PE wad, jg : it could be a technical meeting 11:31 hpachas-PE wad, jg : and OLPC should take note of the points on which all the countries coincide, and focus on improving them. Please join if you are interested! Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Window manager support for standard applications
On Sun, Oct 12, 2008 at 04:10:14PM -0400, Albert Cahalan wrote: Marco Pesenti Gritti writes: On Sun, Oct 12, 2008 at 5:21 PM, Wade Brainerd wadetb at gmail.com wrote: On Sun, Oct 12, 2008 at 4:11 AM, Marco Pesenti Gritti mpgritti at gmail.comwrote: 11 replace matchbox with a more traditional desktop window manager, with the ability to fullscreen windows when appropriate. I've been using the Awesome window manager[1] on my XO lately for standard X apps, perhaps it should be up for consideration? It's really fast and light, supports a mix of fullscreen and floating windows plus unlimited virtual desktops. It also has a tiling mode for people who want that, but it's completely optional. I use it as a tabbed window manager and ignore the tiling. Recent versions are also scriptable using Lua, which isn't Python but at least is very lightweight and fast. That would be a bad move. A coworker of mine has been picking through the Lua interpreter lately. The code is quite awful. It's not really all that lightweight, and it's anything but fast. I believe Lua is used as an extension language in Awesome and that the bulk of the system is written in C? There is at least one fast window manager written almost completely in Lua. See Ion. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 0.84/9.1 planning.
On Tue, Oct 14, 2008 at 06:15:31PM -0400, C. Scott Ananian wrote: On Mon, Oct 13, 2008 at 2:46 PM, Ed McNierney [EMAIL PROTECTED] wrote: I would also like to stop calling this 9.1 planning. We need to plan the development work we need to get done, regardless of whether that work will be able to ship next March. At a certain point we will have some of this work complete and available for qualification in a March delivery, and we'll ship that as 9.1. And we'll keep going to qualify and ship more of it in 9.2, and more in 10.1 (or is that 0.1??), etc. I disagree. Part of the focus of the meeting is to present all the ideas for future development, and then drive stakes in the ground for what's going to be in 9.1. ... In the past we have divided tasks into next release and future release where the future really means never because we don't do *any* of the work in the next release timeframe. That needs to stop. *Everything* we want in a future release must have *some* piece we can do now, so that we continue to make progress on our long-term goals. I think this is exactly the kind of issue which Ed's suggestion is aimed at resolving. By focusing our development on releases instead of problems, we tend to classify issues into next release and future release. It shouldn't matter what release a given issue will fall into. But this is not what occurs in practice. As release time draws near everyone is encouraged to drop long-term issues so that a release date can be met. And consequently the future issues are never approached. I agree with Ed in that I feel that focusing on the specific release so far before we have to pull software together is going to create exactly the dicotomy between next and future you note. I would prefer to have a general software planning meeting and not a 9.1-specific planning meeting. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Slowness (was Re: notes from the field - Mongolia)
Hey Elana, One thing which you can do to improve activity switching performance is to run xcompmgr (X composite manager). This prevents the activities from burning CPU time redrawing themselves every time they are switched to by persistently caching the video memory used by each window. The result is notably improved activity switching performance. But it does so at the cost of memory, as each window open consumes about 2MiB more RAM. One notable problem with this approach is that doing so requires more memory and thus, if the user runs a lot (in testing 4 or 5) of applications the system will become quite slow. It would be helpful to know if the activity switching performance boost provided by wholesale use of X composite is outweighed by the potential out-of-memory situations. How many activities are kids typically using? Would they prefer a system which had much better window manager navigation performance at the cost of not being able to run as many activities? What version of our software (what build) is being used for the tests? Scott suggests that you are running 649. I have tested the following procedure to run xcompmgr on that build: To install xcompmgr in the Terminal: su yum install xcompmgr # indicate 'y' when asked To run, again in the terminal: xcompmgr You won't be able to close the terminal while running the tests. You should notice an improvement in switching performance and frame redraw. The residual latency in switching appears to be caused by activity autosaving, but my testing experience with 649 is not sufficent to pass judgement on this issue. Erik On Thu, Oct 09, 2008 at 01:22:21PM -0400, elana langer wrote: in addition to boot and activity load time the time it takes to switch between applications is also a little frustrating - especially for kids who have worked on faster computers. I am in Mongolia for the next few weeks. There are several schools in the city that have computers so if you want any testing done (like the reaction to the boot time with 8.2) just let me know. If you send me a list of dream field feedback or something I can try to make that all happen. On Thu, Oct 9, 2008 at 4:59 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Hi Elana, you have brought a very needed point of view to this list. Let me try to start the process of translating your experience to actionable items. On Mon, Oct 6, 2008 at 5:20 PM, elana langer [EMAIL PROTECTED] wrote: 1) Computers are slow - So I was in a Ger in the west part of Mongolia and I thought I would show the computer to the family that was hosting me. The husband, wife and 8 year old child huddled around the computer and pressed the on button. Instead of being delighted by the computer they waited, and waited for the computer to load. I asked them in broken monoglian to be patient but once the computer loaded they wanted to open an application and again more waiting. The 8 year old lost interest as did the mom and only the man of the house stuck around to try things. This is not a unique experience. This is a culture that lives close to the land. Action- reaction. No one is used to waiting for an computer to load or a bagel to toast for that matter. (of course cooking takes time but they can watch as it changes form not just an unmoving screen) In the city the experience is worse. Kids used to PCs quickly grow impatient and leave the XO to find other faster computers. First, I would like to note that you are talking about perceived slowness, not the absolute time that takes to do anything. So to solve the issues you mentioned, we need to give a sense to the user that something is happening and, when possible, how much time it will take to finish, in case reducing the time it takes is too expensive resource-wise. Second, you talk about boot time and activity launch time. Is there any other action in the laptop that causes problems because of its slowness? And third, both booting and activity launching performance are known problems and some improvements already happened in the last stable release, 8.2.0. Do you think you could do some experiments with that release and see if things have improved and if so, how much? Thanks, Tomeu ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] notes from the field - Mongolia
On Tue, Oct 07, 2008 at 06:14:16PM +0200, Marco Pesenti Gritti wrote: On Mon, Oct 6, 2008 at 6:33 PM, Erik Garrison [EMAIL PROTECTED] wrote: In my mind the fundamental problem is that users aren't required to fully qualify names for their work. Doing so seems to lie outside of one of the core points of Sugar's design (There are no files, folders, or applications. -- http://sugarlabs.org/go/Main_Page). Is it conceivable that we could change this feature of the system in future releases to clarify data management on Sugar-running XOs? You keep repeating this and it makes no sense. As Eben said we need to encourage people to tag and name things. Saying that it's outside the Sugar philosophy is nonsense. I read there are no files ... to mean that requiring a user to name something before storing it for later retrieval is outside Sugar design philosophy. Named chunk of data is pretty much the definition of a computer file. So if we're asking users to name their chunks of data to address a usability problem, aren't we just asking them to engage in file management? Can we do this and still abide by the no files principle? Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] notes from the field - Mongolia
On Wed, Oct 08, 2008 at 08:30:27PM +0200, Marco Pesenti Gritti wrote: On Wed, Oct 8, 2008 at 8:21 PM, Nia Lewis [EMAIL PROTECTED] wrote: Thanks, MArco. I still think talking to Erik like that isn't very nice either:) Nia, this kind of flames are customary in a technical mailing list and I don't really think Erik should take personal offence about them. If you go back in the archives you will see way more offensive things said about my and the other Sugar developers work. Marco Nia, For what it's worth, I'm not hurt and understood what Marco intended. Email is hard because it's difficult to hear the intention of the person. I think this feature of electronic communication is probably a principal cause of flamewars in their various guises. Thank you, Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] alt-tabbing to the Journal
On Tue, Oct 07, 2008 at 08:55:09AM -0400, Walter Bender wrote: 1. When? Nobody's cited examples where it's more desirable to use Alt-Tab than the dedicated key. I use Sugar as much on a non-XO as I do on an XO and so I often don't have a dedicated key to access the Journal. I would need to resort to opening the Frame and then clicking on the Journal icon--too many steps. Speaking personally, having come from the wonderful world of Emacs, I tend to be more comfortable with key sequences than using dedicated keys. Of course, in both cases, we are not talking about a novice user. But my rule of thumb is that the Journal should be easier to access, not harder. Removing it from the Alt-Tab sequence makes it that much harder to find. Perhaps this has changed in more recent jhbuilds, but on the sugar-emulator downloadable from the Ubuntu Hardy repositories, pressing F4 gets me to the Journal. F1-F3 are neighborhood through home view. I think it's a little strange that the relative layout of the keys is different, but there does appear to be a dedicated key. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] alt-tabbing to the Journal
On Tue, Oct 07, 2008 at 03:37:02PM +0200, Morgan Collett wrote: On Tue, Oct 7, 2008 at 15:30, Erik Garrison [EMAIL PROTECTED] wrote: On Tue, Oct 07, 2008 at 08:55:09AM -0400, Walter Bender wrote: 1. When? Nobody's cited examples where it's more desirable to use Alt-Tab than the dedicated key. I use Sugar as much on a non-XO as I do on an XO and so I often don't have a dedicated key to access the Journal. I would need to resort to opening the Frame and then clicking on the Journal icon--too many steps. Speaking personally, having come from the wonderful world of Emacs, I tend to be more comfortable with key sequences than using dedicated keys. Of course, in both cases, we are not talking about a novice user. But my rule of thumb is that the Journal should be easier to access, not harder. Removing it from the Alt-Tab sequence makes it that much harder to find. Perhaps this has changed in more recent jhbuilds, but on the sugar-emulator downloadable from the Ubuntu Hardy repositories, pressing F4 gets me to the Journal. F1-F3 are neighborhood through home view. I think it's a little strange that the relative layout of the keys is different, but there does appear to be a dedicated key. F4 is the Activity view: http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines/The_Laptop_Experience/Zoom_Metaphor#Activity - so it is consistent with F1-F3 and the group of four zoom keys on the XO. If you open another activity, it doesn't take you to Journal any more... *doh* ! ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Need guidance from a Pygtk guru
On Sun, Oct 05, 2008 at 10:19:20AM -0400, Pierre Métras wrote: Hello, I've learnt Python and Pygtk writing the Clock activity (http://wiki.laptop.org/go/Clock_activity) and I'm now adding a new feature to write the time in full letters to help children learn how to write and read it. The clock has different display modes and the default one is to use a SVG background. I encounter a strange behavior and I don't know where to look at to correct it. The display of the clock activity is composed of a gtk.VBox with a custom ClockFace widget at the top, and a gtk.Label where I write the current time. The user can decide to hide/show the written time with an icon in the toolbar. When the Label is not displayed, the XO has enough power to update the ClockFace widget in less than 1 second, which is nice and what you would expect from a clock with a hand for seconds. But when the user selects to show the time and the code show() the gtk.Label, the ClockFace widget takes more than 1 second to refresh. The whole activity becomes unresponsive and it is even difficult to move the mouse to close it. Gtk timer event every seconds can't follow up... I've tracked the problem to these lines: if radius != self._cache_radius: f = open(clock.svg, rb) svg_data = f.read() f.close() loader = gtk.gdk.PixbufLoader(svg) loader.set_size(int(2 * radius), int(2 * radius)) loader.write(svg_data) loader.close() self._cache_pixbuf = loader.get_pixbuf() self._cache_radius = radius Combining the above code block and the following observation ... As I've said, this strange behavior seems to occur only when the ClockFace widget paints SVG. In the other display modes, the painting is drawn in the code. I've seen it in 8.2-761 and still in candidate-767. ... I suggest that the problem may have something to do with file IO. Are you doing this work on an XO? At present its filesystem has *extremely* poor performance and I would be unsurprised if the described latencies were incurred in opening and reading even a small SVG file. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] notes from the field - Mongolia
On Tue, Oct 07, 2008 at 10:49:25AM -0400, Eben Eliason wrote: On Mon, Oct 6, 2008 at 6:17 PM, [EMAIL PROTECTED] wrote: mikus wrote: - First off, every Activity has a 'Name Field' in its top menu. When running any Activity, the user should enter there a short Title to identify the resulting Journal entry from all others. - Then, upon leaving that Activity, the user should reflect on what was done, and update the corresponding Journal entry to make it easier to find later. This is particularly desirable if the Title is not meaningful enough by itself for later locating what the user is looking for: in a traditional system, when a user saves their work, they are pretty much forced to enter the (hopefully) useful name by which that work will be retrieved. if searching is the fundamental retrieval mechanism (which i think is fine), then my first reaction to mikus' advice is that activities and/or sugar should be more emphatic about asking for the descriptive information which be useful later. i.e., adding search tags shouldn't be an optional extra step, but a usual step which must be explicitly skipped by the user. Indeed. I had brought this issue up in the past thinking it might happen for 8.2, but it's definitely on the plate for 9.1. I have a few ideas about how we can make this system better, and encourage names and tags, without becoming a hassle. We also, down the road, have ideas about how to better expose the tagging system, and perhaps even make it fun, so that describing things becomes a natural part of the interface. Kids learn to speak by describing things around them; we should be able to tap into this to both help them learn and make the Journal a useful and searchable space. I am concerned that focusing on such systems is breaking simple use cases and causing problems for users in the field. I believe that this functionality is important, but do not agree that it should comprise the base layer of data access on a real-world system. Search is extremely powerful, but technically complicated to implement, and equivalently complex to learn how to use. Remember that almost all of us involved in this discussion have been using search on the web for at least the past decade, and while we now understand it as an intuitive process I contend this is not the case for new users. (I can remember, but not locate, at least one study which noted that uninitated users used search engines in extremely strange ways, for instance, running all their search terms together because it mirrored the typical format of DNS names.) Fully qualified names (file names) are simple. They are misused to the extent that users give things strange or confusing names. But, the names are qualified and the users can encounter their work simply by remembering most components of the name. The concept is straightforward: given this key I will always find the data I need, and only that data. Note that in prior art, notably the web and desktop systems, a layer of fully qualified names for resources has always come long before, and provided a base layer for search systems. Despite the fact that links can break, if resources are renamed, we have not yet replaced URLs with search queries to search engines. URLs are quite reliable in comparison to the databases and algorithms required to drive search systems. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] notes from the field - Mongolia
On Tue, Oct 07, 2008 at 06:05:41PM +0200, Marco Pesenti Gritti wrote: On Mon, Oct 6, 2008 at 6:33 PM, Erik Garrison [EMAIL PROTECTED] wrote: How are we going to rectify the general slowness of our user interface? It may not be enough to work on the performance problem from within the existing framework. How will we know if this is the case? We will spend more time profiling and understanding the system and less in uninformed mailing list discussions. My point is that the easiest way to improve the user-perceived performance of the system is probably to kill features. Profiling is not going to help us see this. It is merely going to help us compare one implementation of the framework to another. I am suggesting that we may need to think outside the existing box to resolve the issues described by Elana, and for this I believe that discussion is quite important. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] notes from the field - Mongolia
On Mon, Oct 06, 2008 at 11:20:04AM -0400, elana langer wrote: Hey Tech Community- I just wanted to give y'all some feedback from my experience in Mongolia. Feel free to contact me with any questions. Please excuse my lay language - it's how i roll. 1) Computers are slow - So I was in a Ger in the west part of Mongolia and I thought I would show the computer to the family that was hosting me. The husband, wife and 8 year old child huddled around the computer and pressed the on button. Instead of being delighted by the computer they waited, and waited for the computer to load. I asked them in broken monoglian to be patient but once the computer loaded they wanted to open an application and again more waiting. The 8 year old lost interest as did the mom and only the man of the house stuck around to try things. This is not a unique experience. This is a culture that lives close to the land. Action- reaction. No one is used to waiting for an computer to load or a bagel to toast for that matter. (of course cooking takes time but they can watch as it changes form not just an unmoving screen) In the city the experience is worse. Kids used to PCs quickly grow impatient and leave the XO to find other faster computers. I think this is very interesting, as I have often heard nearly the opposite argument--- that because the XO is often a child's first computer their standards for its responsiveness will be as low as we'd like them to be. What we have forgotten is that slow technology is, to the uninitiated, indistinguishable from broken technology. How are we going to rectify the general slowness of our user interface? It may not be enough to work on the performance problem from within the existing framework. How will we know if this is the case? 2) Can't save files - this should probably be the first item on my list. It drives teachers and students crazy. They make something in an application, take some pictures or write something and then have to go through a really tough process to find it and save it on an external drive. My impression is that the journal design stems from a belief that we have an opportunity to completely redesign human-computer interaction in terms of data storage. Unfortunately this is simply not the case. Teachers have experience with existing systems. If they have any computing experience (and let us hope they do if they are using computers in the classroom!), they have worked with a hierarchical data management system which required them to give fully qualified names to their work. In breaking with this paradigm we rob them of this valuable expertise and frustrate their work with our system. 3) Basically - The journal is really hard for people/ kids to use over a longer period of time. Kids and teachers can't find things that they did unless it was done within the last 30 minutes. This effect, brought about by the user interface of the journal, is exactly the opposite of its most fundamental design principle: don't lose user data. In my mind the fundamental problem is that users aren't required to fully qualify names for their work. Doing so seems to lie outside of one of the core points of Sugar's design (There are no files, folders, or applications. -- http://sugarlabs.org/go/Main_Page). Is it conceivable that we could change this feature of the system in future releases to clarify data management on Sugar-running XOs? 4) Mesh problems - my sense is that you are all pretty aware of those issues. I think we should start looking into software-level mesh protocols using the libertas thin firmware. This is not a solution to this problem, but it will at least move us to a place where we can have collaborative work on the base layer of our mesh networking stack. There are a bunch of bugs that I reported through reuben which include the problems with applications once they have been translated into cyrillic. These are some of the main foundational issues that folks are having. Let me know if you have questions. elana Thank you very much for your feedback and hard work! Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Feedback on Measure (was Re: Another pass through some basic Activity test results)
On Mon, Sep 29, 2008 at 08:47:36AM -0400, Erik Blankinship wrote: Do you need to do that for each window? Why don't you just listen for that signal in just the main activity window and stop everything when gtk.gdk.VISIBILITY_FULLY_OBSCURED and resume when otherwise? Full screen modes in Record completely obscure the main activity window. We don't just listen for visibility events on the video windows because sometimes these are fully obscured (when transcoding, for example). Therefore we listen on both the main activity window and the video windows, and in consultation with the activity's current state (fullscreen, normal, transcoding), decide if Record is the current activity. I've never fully understood the rationale for why the sugar api does not alert activities as to when they are active or not, thereby saving all activity authors these hassles. Is there any particular reason why Record does not use a single window? Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] composite memory usage [was Re: frame auto-visibility configuration]
We can file bugs on these issues prior to pushing composite into a build. Please file a ticket and add the tag 'composite', and describe the test setup. On Wed, Sep 24, 2008 at 11:27:59PM +0100, Eduardo H. Silva wrote: Just to follow-up with trying it, while at first the feeling of using composition was of a more responsive system, I did see performance degrade as I launched more activities and used it more. The saving grace was that there never was any ugly visual redraws (other than when a new activity is launching). How many activities could you comfortably run? Plus, there are a few bugs, like new activities launched after composition is turned on show their text in a smaller size (like in Browses address bar, and in its Back button palette). Strange, I haven't noticed this. Please file a ticket with a test case to demonstrate. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] alt-tabbing to the Journal
On Thu, Sep 25, 2008 at 09:48:06AM +0200, Tomeu Vizoso wrote: On Wed, Sep 24, 2008 at 10:26 PM, Erik Garrison [EMAIL PROTECTED] wrote: A thought which has come up a few times in my exploration of activity switching performance, and a few times in conversations on the sugar list, is that the Journal shouldn't be included in the set of activities which can be alt+tab'ed to. The most compelling rationale is that there is already a dedicated button on the keyboard for it (F1). This comes up regularly and I think we have a ticket where people are voting. I believe you can find the ticket if you search in this month archives. Please comment: http://dev.laptop.org/ticket/6251 Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] alt-tabbing to the Journal
On Thu, Sep 25, 2008 at 11:43:57AM -0400, Robert Myers wrote: Tomeu, On Wed, Sep 24, 2008 at 10:26 PM, Erik Garrison [EMAIL PROTECTED] wrote: A thought which has come up a few times in my exploration of activity switching performance, and a few times in conversations on the sugar list, is that the Journal shouldn't be included in the set of activities which can be alt+tab'ed to. The most compelling rationale is that there is already a dedicated button on the keyboard for it (F1). This comes up regularly and I think we have a ticket where people are voting. I believe you can find the ticket if you search in this month archives. Is this #6251? That's the only trac that I see that makes sense here. My 2c. Leave the Journal in the alt-tab ring. It's an activity. It just happens to be an activity that's always running. Think of the Finder on MacOS as a parallel example. The journal cannot be closed or saved. It cannot be opened. It's not an activity, but part of the shell, both in aspect and in implementation. Making it a special case that you have to use a special key to get to is more confusing than leaving it on the ring. An access path is also in the frame. Every time you alt+tab unintentionally to the Journal you waste time and keyboard interaction. This is why there is a dedicated key, to expedite the process of finding the Journal without necessitating that users see it when they don't want to. Continuing down that path, I think that the launcher pane should be treated more as just another activity, and also be on the alt-tab ring. Maybe it should also have an icon on the frame. Further still, every single view/window in the window manager--- neighborhood view, launcher, and group view included--- could be on the alt+tab stack. This would be conceptually very simple. But because such windows can't be closed, users who aren't using them would have no choice but to navigate through them on their way to what they want. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] frame auto-visibility configuration
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? Drawing the frame animation during tabbing robs us of processor right when we need it, slowing the perceived transition time between windows. Furthermore, as the XO only has one processor the frame animation (which requires available processor to run smoothly) will skip a lot of frames if the processor is loaded. As we're auto-saving and re-rendering the windows of every window we pass during tabbing, the processor is invariably quite loaded, and the frame draw consequently is quite clunky. The attached patch to sugar optionally disables frame appearance if the file /home/olpc/no-frame-on-tabbing exists. This is just a proof-of-concept hack to make it easier to quickly enable and disable the functionality and observe the performance change. I have created a trac ticket: http://dev.laptop.org/ticket/8633 Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
On Wed, Sep 24, 2008 at 11:03:01AM -0400, Chris Ball wrote:
Hi Erik,
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?
Sounds good, I'd agree with just removing it completely.
Me too.
The attached patch to sugar optionally disables frame appearance if
the file /home/olpc/no-frame-on-tabbing exists. This is just a
proof-of-concept hack to make it easier to quickly enable and
disable the functionality and observe the performance change.
The patch isn't attached, and the patch I found in the Trac ticket isn't
useful -- it has no lines of context and doesn't even specify which file
is being patched, so it can't be applied; please resend using diff -u,
or ideally git diff.
Whooops! Two errors. I put the wrong patch on the ticket and didn't
even attach the patch to the email.
Attached is the right file. I'm fixing the ticket... is there any way
to delete files from a trac ticket?
Erik
diff --git a/src/view/tabbinghandler.py b/src/view/tabbinghandler.py
index e3153b0..54f2d4e 100644
--- a/src/view/tabbinghandler.py
+++ b/src/view/tabbinghandler.py
@@ -15,6 +15,7 @@
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
import logging
+import os
import gtk
import gobject
@@ -59,7 +60,8 @@ class TabbingHandler(object):
else:
shell = view.Shell.get_instance()
-self._frame.show(self._frame.MODE_NON_INTERACTIVE)
+if not os.path.exists('/home/olpc/no-frame-on-tabbing'):
+self._frame.show(self._frame.MODE_NON_INTERACTIVE)
def __timeout_cb(self):
self._activate_current()
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
On Wed, Sep 24, 2008 at 11:25:51AM -0400, Eben Eliason wrote: On Wed, Sep 24, 2008 at 10:52 AM, Erik Garrison [EMAIL PROTECTED] 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? I disagree that showing the Frame is a bad idea. It emphasizes the purpose of the top edge of the Frame, and provides context while tabbing so that it's easy to see where you want to get to. Do we have observations of how users (students) navigate? Are they using the frame to do all navigation (e.g. by pressing the frame button to reveal it or mousing to a corner)? Or are they alt+tabbing everywhere? Drawing the frame animation during tabbing robs us of processor right when we need it, slowing the perceived transition time between windows. Drawing the Frame does take a little effort, it's true. Compositing support should later speed this up a good deal. The current reveal/retraction rate of the Frame is at least 2x as slow as I'd like it to be, in practice. Additionally, there *is* a lag on switching windows, and this is, actually, part of the reason that I think the Frame should be shown. Without the Frame, we are forced to expose each window in the tabbing process, which injects delays into each tabbing event. With the Frame shown, we delay the actual window switch slightly so that it's possible to tab quickly past a few activities you're not interested in, pausing only at those that you want to see in more detail. I have a system with compositing enabled. I am using xcompmgr to test. You can do so by yum-installing xcompmgr, then running it from a terminal in Sugar via xcompmgr -d :0.0. Generally, with compositing managed via xcompmgr, switching is fast enough that it seems you can tab through several windows in the same time that it takes to draw the frame onto the screen. So perhaps the utility of showing the frame will decrease in such an arrangement, as users can figure out where they are by hopping around just as quickly as they could by showing the frame. It is true that when using composition the frame animation is smoother. But, as I noted initially, the frame display performance is directly related to the CPU load on our single processor. Thus even with composition enabled the frame animation stutters as other processes compete for resources. You just don't get the ugly grey 'undrawn' blocks on the window which is revealed below. Furthermore, as the XO only has one processor the frame animation (which requires available processor to run smoothly) will skip a lot of frames if the processor is loaded. As we're auto-saving and re-rendering the windows of every window we pass during tabbing, the processor is Saving and re-rendering...could you elaborate? As I mentioned, the point of using the Frame is to *minimize* the number of context switches that need to happen. By saving I mean that changes in activity state trigger Activity.save(). This hits jffs2 and the NAND. By re-rendering I mean that, because we are not compositing each window is unmapped when we navigate away from it and consequently the each program has to re-draw its window when we visit it again. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
On Wed, Sep 24, 2008 at 06:08:47PM +0200, Tomeu Vizoso wrote:
On Wed, Sep 24, 2008 at 5:25 PM, Eben Eliason [EMAIL PROTECTED] wrote:
On Wed, Sep 24, 2008 at 10:52 AM, Erik Garrison [EMAIL PROTECTED] 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?
I disagree that showing the Frame is a bad idea. It emphasizes the
purpose of the top edge of the Frame, and provides context while
tabbing so that it's easy to see where you want to get to.
Drawing the frame animation during tabbing robs us of processor right
when we need it, slowing the perceived transition time between windows.
Drawing the Frame does take a little effort, it's true. Compositing
support should later speed this up a good deal.
We also shouldn't be autosaving when the activity is not dirty (most
of the time when alt-tabbing).
May be easier to actually enable composition and disable autosaving
(by editing activity.py) than speculating here about cutting
functionality.
My observations are partly coming from testing on composition and no
autosave... You're right that others should give it a whirl.
Who could give this a try?
I have patches to enable composition in Sugar's main.py. We'll have to
push xcompmgr into the builds as well.
I also have a patch to disable autosaving (again with a flag in home,
/home/olpc/no-auto-save).
For what it's worth I'm attaching them here. Perhaps we should start a
new thread to discuss these?
Erik
diff --git a/src/main.py b/src/main.py
index 355565b..749e530 100644
--- a/src/main.py
+++ b/src/main.py
@@ -15,6 +15,7 @@
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
import os
+import subprocess
import gettext
import pygtk
@@ -45,6 +46,9 @@ def _start_matchbox():
gobject.spawn_async(cmd, flags=gobject.SPAWN_SEARCH_PATH)
+def _start_xcompmgr():
+subprocess.Popen(['xcompmgr', '-d', ':0.0'])
+
def _setup_translations():
locale_path = os.path.join(config.prefix, 'share', 'locale')
domain = 'sugar'
@@ -88,6 +92,7 @@ def main():
logger.start('shell')
+_start_xcompmgr()
_start_matchbox()
_setup_translations()
diff --git a/src/sugar/activity/activity.py b/src/sugar/activity/activity.py
index b55a09d..97abbc7 100644
--- a/src/sugar/activity/activity.py
+++ b/src/sugar/activity/activity.py
@@ -575,7 +575,8 @@ class Activity(Window, gtk.Container):
if self._active != active:
self._active = active
if not self._active and self._jobject:
-self.save()
+if not os.path.exists('/home/olpc/no-auto-save'):
+self.save()
active = gobject.property(
type=bool, default=False, getter=get_active, setter=set_active)
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
On Wed, Sep 24, 2008 at 12:25:43PM -0400, Eben Eliason wrote: On Wed, Sep 24, 2008 at 12:18 PM, Erik Garrison [EMAIL PROTECTED] wrote: On Wed, Sep 24, 2008 at 11:25:51AM -0400, Eben Eliason wrote: On Wed, Sep 24, 2008 at 10:52 AM, Erik Garrison [EMAIL PROTECTED] wrote: By saving I mean that changes in activity state trigger Activity.save(). This hits jffs2 and the NAND. Sure, as Tomeu says, we could add a dirty bit. Of course, it seems that the Frame-based solution should actually be preventing this (given a long enough delay on revealing the activity window, or not revealing until releasing alt-tab), since the activities don't even get focused at all immediately. Only those you pause or stop on should be doing any saving of state, and even then only if needed. How long of a pause or stop triggers auto-save? We could also save on user idle. Say, when the user is idle for more than 5 seconds and we haven't saved in the last 2 minutes. Or we could just auto-save every N minutes. Both of these options would decouple CPU-intensive actions from user intervention, with the effect of improved system responsiveness. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] composite memory usage [was Re: frame auto-visibility configuration]
On Wed, Sep 24, 2008 at 07:51:30PM +0200, Tomeu Vizoso wrote:
On Wed, Sep 24, 2008 at 7:25 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote:
Wow, just tried Erik's instructions for using xcompmgr, and it's
amazing how swift the frame slides, and how I don't see any screen
redraws. The experience is totally more fluid. Does it degrade overall
performance? If not much, and if that performance degradation could be
recovered in another area in Sugar (general performanfe improvements),
I'd vote for this to exist in joyride and even part of future stable
builds.
AFAIK, the only tradeback (and the reason why it hasn't been activated
yet) is that we must pay composition with increased memory usage.
Composition basically saves us unnecessary redraws by keeping in
memory copies of the windows contents.
Martin Dengler did back in March an excellent job quantifying this tradeback:
http://lists.laptop.org/pipermail/sugar/2008-March/004718.html
Using similar methods (ps_mem.py), I get roughly the same results.
I run ps_mem.py at five places, before and after enabling composite with
0 to 4 activites running (Chat, Paint, Write, and Browse). (I get ten
files named {before,after}_*_activity, and then grep them to make
comparitive claims.)
We can see that Activities use about the same amount of memory before
and after the change:
e.g. Paint:
before_1_activity: 9.3 MiB + 4.2 MiB = 13.5 MiB Paint 65be2c3b
before_2_activity: 9.2 MiB + 3.1 MiB = 12.3 MiB Paint 65be2c3b
before_3_activity: 9.4 MiB + 2.5 MiB = 11.9 MiB Paint 65be2c3b
before_4_activity: 9.4 MiB + 2.1 MiB = 11.5 MiB Paint 65be2c3b
after_1_activity: 9.3 MiB + 4.2 MiB = 13.5 MiB Paint eb84d7a4
after_2_activity: 9.3 MiB + 3.1 MiB = 12.4 MiB Paint eb84d7a4
after_3_activity: 9.2 MiB + 2.5 MiB = 11.7 MiB Paint eb84d7a4
after_4_activity: 9.2 MiB + 2.1 MiB = 11.3 MiB Paint eb84d7a4
e.g. Write:
before_3_activity: 19.4 MiB + 2.8 MiB = 22.2 MiB Write d2756bab
before_4_activity: 19.4 MiB + 2.4 MiB = 21.8 MiB Write d2756bab
after_3_activity: 19.4 MiB + 2.8 MiB = 22.2 MiB Write d863e164
after_4_activity: 19.4 MiB + 2.4 MiB = 21.8 MiB Write d863e164
However, there is an obvious memory difference between the two
situations:
[ total memory usage ]
before_0_activity- 86.4 MiB
before_1_activity- 98.0 MiB
before_2_activity-126.6 MiB
before_3_activity-146.2 MiB
before_4_activity-154.9 MiB
after_0_activity- 88.5 MiB
after_1_activity-109.8 MiB
after_2_activity-138.0 MiB
after_3_activity-162.7 MiB
after_4_activity-173.2 MiB
When composition is enabled, we used 18.3 MiB more to run the same 4
activities.
Following Martin Dengler's lead, we discover that this memory is mostly
used by the X server:
bash-3.2# grep Xorg before*
before_0_activity: 3.1 MiB + 390.5 KiB = 3.5 MiB Xorg
before_1_activity: 3.2 MiB + 430.0 KiB = 3.6 MiB Xorg
before_2_activity: 3.4 MiB + 420.0 KiB = 3.9 MiB Xorg
before_3_activity: 3.7 MiB + 509.5 KiB = 4.2 MiB Xorg
before_4_activity: 3.7 MiB + 507.5 KiB = 4.2 MiB Xorg
bash-3.2# grep Xorg after*
after_0_activity: 3.0 MiB + 342.5 KiB = 3.3 MiB Xorg
after_1_activity: 10.9 MiB + 445.0 KiB = 11.4 MiB Xorg
after_2_activity: 13.1 MiB + 425.5 KiB = 13.5 MiB Xorg
after_3_activity: 18.0 MiB + 506.0 KiB = 18.5 MiB Xorg
after_4_activity: 19.9 MiB + 504.0 KiB = 20.4 MiB Xorg
A little under 15 MiB of increase.
I'd vote for activating composition ASAP once we have a 9.1 joyride
branch and see how we can find the sweetest spot between speed and
memory usage.
I agree.
There also may be bugs which we need to shake out. If this is a feature
we know we want for 9.1, the sooner we start testing the better.
Erik
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] composite memory usage [was Re: frame auto-visibility configuration]
On Thu, Sep 25, 2008 at 12:43:02AM +0530, Sayamindu Dasgupta wrote: FWIW, sometime back, I did some benchmarks with a composite enabled Metacity - results at http://www.mail-archive.com/sugar@lists.laptop.org/msg03613.html Jim had suggested some memory saving tricks at http://www.mail-archive.com/sugar@lists.laptop.org/msg03647.html Thanks. I'm going to try out Jim's suggestion: On Thu, 05 Jun 2008 08:38:59 -0700, Jim Gettys wrote: For composition to not eat memory (a full frame buffer's worth/activity), the buried windows need to be unmapped in X parlance. When a window is unmapped, X can free the contents of the window even when composite is running (IIRC). We have gtk.Window.unmap() to play with. The difficult question is how to signal the activities to unmap themselves. I suppose we could follow the pattern currently used to trigger auto-saves. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] alt-tabbing to the Journal
A thought which has come up a few times in my exploration of activity switching performance, and a few times in conversations on the sugar list, is that the Journal shouldn't be included in the set of activities which can be alt+tab'ed to. The most compelling rationale is that there is already a dedicated button on the keyboard for it (F1). Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Wed, Sep 24, 2008 at 04:16:17PM -0400, Walter Bender wrote: We all agree that the datastore needs serious attention, although it doesn't directly impact the running of legacy activities. Rainbow is an issue. And moving data back and forth between Sugar and legacy apps is an issue. But I'll argue the WM is a relatively minor issue in these respects. What legacy applications and activities are you referring to? Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
Well. It's off-topic. I guess it came to mind because the Journal and datastore are a point of incompatibility between Sugar and the rest of the Linux desktop world. Erik On Tue, Sep 23, 2008 at 08:16:25AM -0400, Walter Bender wrote: Could you please elaborate on what the behavior of the Journal has to do with this thread? -walter On Mon, Sep 22, 2008 at 2:52 PM, Erik Garrison [EMAIL PROTECTED] wrote: On Sun, Sep 21, 2008 at 05:01:41PM -0400, Michael Stone wrote: My impression, based on historical conversations with the parties involved is that there are a bunch of hackers who feel that we did ourselves a disservice by dropping _so much_ backwards compatibility, specifically with Unix filesystems and desktops, in exchange for cool ideas. The feeling is that had we traded compatibility for features less aggressively then there would be many more hackers available to help write the features since there would be many more hackers who felt it was possible to live within Sugar. This is just an impression, however. For what it's worth, it is also my impression. I have heard similarly from virtually all technically-oriented parties involved. I have heard echos of this from less technical users (e.g. teachers who are confused by the behavior of the journal). Erik -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
Well. It's off-topic. I guess it came to mind because the Journal and datastore are a point of incompatibility between Sugar and the rest of the Linux desktop world. Erik On Tue, Sep 23, 2008 at 08:16:25AM -0400, Walter Bender wrote: Could you please elaborate on what the behavior of the Journal has to do with this thread? -walter On Mon, Sep 22, 2008 at 2:52 PM, Erik Garrison [EMAIL PROTECTED] wrote: On Sun, Sep 21, 2008 at 05:01:41PM -0400, Michael Stone wrote: My impression, based on historical conversations with the parties involved is that there are a bunch of hackers who feel that we did ourselves a disservice by dropping _so much_ backwards compatibility, specifically with Unix filesystems and desktops, in exchange for cool ideas. The feeling is that had we traded compatibility for features less aggressively then there would be many more hackers available to help write the features since there would be many more hackers who felt it was possible to live within Sugar. This is just an impression, however. For what it's worth, it is also my impression. I have heard similarly from virtually all technically-oriented parties involved. I have heard echos of this from less technical users (e.g. teachers who are confused by the behavior of the journal). Erik -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame gets in the way when alt-tabbing
On Mon, Sep 22, 2008 at 03:28:33PM -0400, Eben Eliason wrote: On Mon, Sep 22, 2008 at 3:14 PM, Erik Garrison [EMAIL PROTECTED] wrote: ... So perhaps the best thing to do is to add a configuration option to allow the user to enable or disable this behavior? Would it be better if the frame was quickly displayed instead of sliding into view? Maybe generally we need a configuration option to turn on and off fancy animations to improve system responsiveness? Perhaps in the short term a boolean (exposed or not...I'd lean toward not) would suit. The big isue is lack of composition support. The Frame currently slides in about 1/2 as fast as I'd like it to, and choppily at that. With composition we could get smooth motion and also speed it up significantly. (The only reason it's so slow now, I believe, is because without composition we can't draw frames fast enough to convey the motion unless we increase the length of the reveal.) Both Joyride and 8.2 streams have composition enabled by default. You can test composition by running xcompmgr -d :0.0 in the terminal. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame gets in the way when alt-tabbing
On Tue, Sep 23, 2008 at 03:21:04PM +0100, Gary C Martin wrote: On 23 Sep 2008, at 15:08, Bert Freudenberg wrote: Am 23.09.2008 um 06:21 schrieb Erik Garrison: Both Joyride and 8.2 streams have composition enabled by default. You can test composition by running xcompmgr -d :0.0 in the terminal. It is available, but the window manager does not use it, afaik. - Bert - Not that I could find the xcompmgr command anyway, but if you run matchbox-window-manager -? it lists its compile time options, and there is a definite composite support no line in there. Oops! First you have to yum install xcompmgr Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] screenshots hurt
Further revisions to the patches to cleanup the screenshot behavior in
Sugar. Effects are as stated previously:
On Fri, Sep 05, 2008 at 01:31:54AM -0300, Erik Garrison wrote:
before, screenshots taken on these events:
- frame visibility
- tabbing start
- activity next tab
- activity previous tab
- zoom into activity view
- activity close (twice)
after, screenshots taken on these events:
- activity close (once)
- activity keep / save
... but I have resolved an issue noted by Eben:
I still think this is going to be doing the wrong thing about half
the time, as long as there is no check to be sure that the activity is
visible at the time the screenshot is taken. (There also seems to be no
avoiding the fact that the Frame will be in many of them...) I'd rather
have no preview than an incorrect one. (quoted by C. Scott @
http://dev.laptop.org/ticket/8432)
I resolved this issue by adding functionality to the Activity class
defined in activity.py which processes visibility-notify-events from X
and sets a flag Activity._visibible to True when the window is in any
state but fully obscured. This state is publicly accessible via
Activity.is_visible().
NB. I wanted to use the gtk.gdk.VISIBILITY_UNOBSCURED to trigger this,
as it would guarantee that the frame is not in the way of the window
when the screenshot is taken, but found that this inhibited taking the
screenshot if there was a palette of any kind drawn over top of the root
Activity window.
Comments? Please test. This is an 8.2 target (Greg has tagged it
'polish').
Erik
diff --git a/src/view/Shell.py b/src/view/Shell.py
index bfaa72e..30ccd5c 100644
--- a/src/view/Shell.py
+++ b/src/view/Shell.py
@@ -191,8 +191,6 @@ class Shell(gobject.GObject):
if level == self._model.get_zoom_level():
return
-self.take_activity_screenshot()
-
if level == shellmodel.ShellModel.ZOOM_ACTIVITY:
host = self.get_current_activity()
if host is not None:
@@ -209,7 +207,6 @@ class Shell(gobject.GObject):
home_model = self._model.get_home()
previous_activity = home_model.get_previous_activity()
if previous_activity:
-self.take_activity_screenshot()
previous_activity.get_window().activate(
gtk.get_current_event_time())
@@ -217,7 +214,6 @@ class Shell(gobject.GObject):
home_model = self._model.get_home()
next_activity = home_model.get_next_activity()
if next_activity:
-self.take_activity_screenshot()
next_activity.get_window().activate(gtk.get_current_event_time())
def close_current_activity(self):
@@ -229,7 +225,6 @@ class Shell(gobject.GObject):
if active_activity.is_journal():
return
-self.take_activity_screenshot()
self.get_current_activity().close()
def get_current_activity(self):
diff --git a/src/view/frame/frame.py b/src/view/frame/frame.py
index 6009e7f..c3f0de9 100644
--- a/src/view/frame/frame.py
+++ b/src/view/frame/frame.py
@@ -146,8 +146,6 @@ class Frame(object):
if self._animator:
self._animator.stop()
-view.Shell.get_instance().take_activity_screenshot()
-
self.mode = mode
self._animator = animator.Animator(0.5)
diff --git a/src/view/tabbinghandler.py b/src/view/tabbinghandler.py
index 03ce275..e3153b0 100644
--- a/src/view/tabbinghandler.py
+++ b/src/view/tabbinghandler.py
@@ -58,7 +58,6 @@ class TabbingHandler(object):
self._tabbing = False
else:
shell = view.Shell.get_instance()
-shell.take_activity_screenshot()
self._frame.show(self._frame.MODE_NON_INTERACTIVE)
diff --git a/src/sugar/activity/activity.py b/src/sugar/activity/activity.py
index f34553d..a2bcea0 100644
--- a/src/sugar/activity/activity.py
+++ b/src/sugar/activity/activity.py
@@ -174,7 +174,6 @@ class ActivityToolbar(gtk.Toolbar):
self._activity.copy()
def __stop_clicked_cb(self, button):
-self._activity.take_screenshot()
self._activity.close()
def __jobject_updated_cb(self, jobject):
@@ -467,6 +466,12 @@ class Activity(Window, gtk.Container):
self.connect('realize', self.__realize_cb)
self.connect('delete-event', self.__delete_event_cb)
+# watch visibility-notify-events to know when we can safely
+# take a screenshot of the activity
+self.add_events(gtk.gdk.VISIBILITY_NOTIFY_MASK)
+self.connect('visibility-notify-event', self.__visibility_notify_event_cb)
+self._visible = False
+
self._active = False
self._activity_id = handle.activity_id
self._pservice = presenceservice.get_instance()
@@ -575,6 +580,12 @@ class Activity(Window, gtk.Container):
active = gobject.property(
type=bool, default=False, getter=get_active, setter
Re: [sugar] [PATCH] screenshots hurt
On Fri, Sep 12, 2008 at 06:21:41PM -0400, Erik Garrison wrote: Further revisions to the patches to cleanup the screenshot behavior in Sugar. Effects are as stated previously: On Fri, Sep 05, 2008 at 01:31:54AM -0300, Erik Garrison wrote: before, screenshots taken on these events: - frame visibility - tabbing start - activity next tab - activity previous tab - zoom into activity view - activity close (twice) after, screenshots taken on these events: - activity close (once) - activity keep / save ... but I have resolved an issue noted by Eben: And, additionally, incorporated a patch by benzea which resolves a related performance issue with screenshots, in which each screenshot pixbuf was written to a file in /tmp. http://benjamin.sipsolutions.net/tmp/sugar-pixbuf-callback.patch Thanks benzea! Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] REVISED screenshots hurt
I have revised and tested the patches. The effects are as follows:
On Fri, Sep 05, 2008 at 01:31:54AM -0300, Erik Garrison wrote:
before, screenshots taken on these events:
- frame visibility
- tabbing start
- activity next tab
- activity previous tab
- zoom into activity view
- activity close (twice)
after, screenshots taken on these events:
- activity close (once)
- activity keep / save
I dropped the screenshot acquisition code into Activity.copy() and
Activity.close() so that both user-initated 'keep' (==copy) and 'close'
events (both keyboard initiated and frame-click initiated) will take
screenshots for use in the journal.
The patches are attached to this email. Should I make a new track
ticket for this issue to log the introduction?
Any objections or thoughts?
Erik
diff --git a/src/view/Shell.py b/src/view/Shell.py
index bfaa72e..30ccd5c 100644
--- a/src/view/Shell.py
+++ b/src/view/Shell.py
@@ -191,8 +191,6 @@ class Shell(gobject.GObject):
if level == self._model.get_zoom_level():
return
-self.take_activity_screenshot()
-
if level == shellmodel.ShellModel.ZOOM_ACTIVITY:
host = self.get_current_activity()
if host is not None:
@@ -209,7 +207,6 @@ class Shell(gobject.GObject):
home_model = self._model.get_home()
previous_activity = home_model.get_previous_activity()
if previous_activity:
-self.take_activity_screenshot()
previous_activity.get_window().activate(
gtk.get_current_event_time())
@@ -217,7 +214,6 @@ class Shell(gobject.GObject):
home_model = self._model.get_home()
next_activity = home_model.get_next_activity()
if next_activity:
-self.take_activity_screenshot()
next_activity.get_window().activate(gtk.get_current_event_time())
def close_current_activity(self):
@@ -229,7 +225,6 @@ class Shell(gobject.GObject):
if active_activity.is_journal():
return
-self.take_activity_screenshot()
self.get_current_activity().close()
def get_current_activity(self):
diff --git a/src/view/frame/frame.py b/src/view/frame/frame.py
index 6009e7f..c3f0de9 100644
--- a/src/view/frame/frame.py
+++ b/src/view/frame/frame.py
@@ -146,8 +146,6 @@ class Frame(object):
if self._animator:
self._animator.stop()
-view.Shell.get_instance().take_activity_screenshot()
-
self.mode = mode
self._animator = animator.Animator(0.5)
diff --git a/src/view/tabbinghandler.py b/src/view/tabbinghandler.py
index 03ce275..e3153b0 100644
--- a/src/view/tabbinghandler.py
+++ b/src/view/tabbinghandler.py
@@ -58,7 +58,6 @@ class TabbingHandler(object):
self._tabbing = False
else:
shell = view.Shell.get_instance()
-shell.take_activity_screenshot()
self._frame.show(self._frame.MODE_NON_INTERACTIVE)
diff --git a/src/sugar/activity/activity.py b/src/sugar/activity/activity.py
index f34553d..dcfeb1f 100644
--- a/src/sugar/activity/activity.py
+++ b/src/sugar/activity/activity.py
@@ -174,7 +174,6 @@ class ActivityToolbar(gtk.Toolbar):
self._activity.copy()
def __stop_clicked_cb(self, button):
-self._activity.take_screenshot()
self._activity.close()
def __jobject_updated_cb(self, jobject):
@@ -813,6 +812,7 @@ class Activity(Window, gtk.Container):
copy work that needs to be done in write_file()
logging.debug('Activity.copy: %r' % self._jobject.object_id)
+self.take_screenshot()
self.save()
self._jobject.object_id = None
@@ -968,6 +968,7 @@ class Activity(Window, gtk.Container):
write_file() to do any state saving instead. If the application wants
to control wether it can close, it should override can_close().
+self.take_screenshot()
if not self.can_close():
return
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] REVISED screenshots hurt
On Thu, Sep 11, 2008 at 01:01:31PM -0400, C. Scott Ananian wrote: On Thu, Sep 11, 2008 at 12:39 PM, Erik Garrison [EMAIL PROTECTED] wrote: The patches are attached to this email. Should I make a new track ticket for this issue to log the introduction? Please file a trac ticket, attach the patches there, and request review using the standard sugar process. Mention the trac ticket here on sugar@, and those interested in further discussion can cc themselves on the trac ticket. http://dev.laptop.org/ticket/8432 Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity testing on current 8.2 build 759
On Mon, Sep 08, 2008 at 03:18:29AM +0100, Gary C Martin wrote: == Paint-20 Could start? Yes Could stop? Yes Sound: N/A Activity resume: Useful state is restored Note: Very laggy when you try to draw, perhaps 1 to 2 seconds behind mouse movement! Currently quite unusable on XO hardware. == I've noticed this on 2263. Perhaps it's a result of mouse driver changes? Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] screenshots hurt
On Fri, Sep 05, 2008 at 03:48:54PM +0200, Marco Pesenti Gritti wrote: On Thu, Sep 4, 2008 at 6:44 PM, Erik Garrison [EMAIL PROTECTED] wrote: I do not understand this as a temporary measure as it is completely unclear why we are taking screenshots at every window manager navigation event. What problem are we trying to solve in doing so? The resultant screenshots are barely even legible when they appear in the joural. I was trying to say that I am unclear of the motivation for having screenshots at a heavy cost to windowmanager navigation performance. Why is this feature more important than user comfort? By problem I was referring to the issue that the screenshots are used to resolve. I now am clear that the problem is that users can't figure out what's what in their journal without screenshots. The current patchset attempts to resolve this issue in a way that doesn't affect the performance of window change events in Sugar. Because with the current approach we can only take these screenshots while the window is visible on the screen, and taking them on window navigation events is the only way to ensure they are always updated. If the activity is still running, then why does an updated screeshot have to appear in the journal? The user can easily reach the activity by the same navigational system that takes them to the journal. I understand that it is important to have these screenshots to resume saved work. The current patchset guarantees that they will exist provided the user intentionally saves their work, or properly closes the activity. There are a couple of ways we can take them only when saving the document: 1 Use gtk offscreen rendering (should be available in F10) 2 Use a composite manager (which has several side effects...) Can these be implemented and tested quickly? If not perhaps we should implement this patch and reintroduce the current functionality when these features are complete. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] REVISED v.2 screenshots hurt
Devs,
The previous patches were incomplete, as they only screenshot saving via
the close and keep click callbacks. If the user initated a close or
save via the keyboard, the screenshots would not be saved. The attached
patches should resolve this issue. The modified patch is to activity.py
in sugar-toolkit.
Erik
diff --git a/src/view/Shell.py b/src/view/Shell.py
index a53ee93..b6ffbfe 100644
--- a/src/view/Shell.py
+++ b/src/view/Shell.py
@@ -190,8 +190,6 @@ class Shell(gobject.GObject):
if level == self._model.get_zoom_level():
return
-self.take_activity_screenshot()
-
if level == shellmodel.ShellModel.ZOOM_ACTIVITY:
host = self.get_current_activity()
if host is not None:
@@ -208,7 +206,6 @@ class Shell(gobject.GObject):
home_model = self._model.get_home()
previous_activity = home_model.get_previous_activity()
if previous_activity:
-self.take_activity_screenshot()
previous_activity.get_window().activate(
gtk.get_current_event_time())
@@ -216,7 +213,6 @@ class Shell(gobject.GObject):
home_model = self._model.get_home()
next_activity = home_model.get_next_activity()
if next_activity:
-self.take_activity_screenshot()
next_activity.get_window().activate(gtk.get_current_event_time())
def close_current_activity(self):
@@ -228,7 +224,6 @@ class Shell(gobject.GObject):
if active_activity.is_journal():
return
-self.take_activity_screenshot()
self.get_current_activity().close()
def get_current_activity(self):
diff --git a/src/view/frame/frame.py b/src/view/frame/frame.py
index 6009e7f..c3f0de9 100644
--- a/src/view/frame/frame.py
+++ b/src/view/frame/frame.py
@@ -146,8 +146,6 @@ class Frame(object):
if self._animator:
self._animator.stop()
-view.Shell.get_instance().take_activity_screenshot()
-
self.mode = mode
self._animator = animator.Animator(0.5)
diff --git a/src/view/tabbinghandler.py b/src/view/tabbinghandler.py
index 03ce275..e3153b0 100644
--- a/src/view/tabbinghandler.py
+++ b/src/view/tabbinghandler.py
@@ -58,7 +58,6 @@ class TabbingHandler(object):
self._tabbing = False
else:
shell = view.Shell.get_instance()
-shell.take_activity_screenshot()
self._frame.show(self._frame.MODE_NON_INTERACTIVE)
diff --git a/src/sugar/activity/activity.py b/src/sugar/activity/activity.py
index 73eeea7..0746135 100644
--- a/src/sugar/activity/activity.py
+++ b/src/sugar/activity/activity.py
@@ -174,7 +174,6 @@ class ActivityToolbar(gtk.Toolbar):
self._activity.copy()
def __stop_clicked_cb(self, button):
-self._activity.take_screenshot()
self._activity.close()
def __jobject_updated_cb(self, jobject):
@@ -812,6 +811,7 @@ class Activity(Window, gtk.Container):
Activities should not override this method. Instead, like save() do any
copy work that needs to be done in write_file()
+self._activity.take_screenshot()
logging.debug('Activity.copy: %r' % self._jobject.object_id)
self.save()
self._jobject.object_id = None
@@ -969,6 +969,8 @@ class Activity(Window, gtk.Container):
to control wether it can close, it should override can_close().
+self._activity.take_screenshot()
+
if not self.can_close():
return
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] screenshots hurt
On Fri, Sep 05, 2008 at 06:20:17PM +0200, Marco Pesenti Gritti wrote: On Fri, Sep 5, 2008 at 4:47 PM, Erik Garrison [EMAIL PROTECTED] wrote: By problem I was referring to the issue that the screenshots are used to resolve. I now am clear that the problem is that users can't figure out what's what in their journal without screenshots. The current patchset attempts to resolve this issue in a way that doesn't affect the performance of window change events in Sugar. I can think of a couple of limitation with your approach (aside from the implementation issue we discussed in irc, which can be easily fixed): 1 If you close the an activity while the frame is up, you will get a screenshot with some black areas. 2 If you close a non-active activity from the frame (icon palette) you would get a completely black screenshot. I'm somewhat bothered by the completely black screenshot but see no immediate way to alleviate it. Another issue with the current patchset is that if the activity is closed by a signal from the window manager (e.g. when the user selects the 'shutdown' option from the system palette in the home view) then the screenshots are not taken, as activity.Activity.close() is not hit. Thanks to Andrés for pointing this out. Is this signal implemented? Should we move the screenshot event into activity.Activity.prepare_close() instead. It appears this is hit every time we close by any method. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] screenshots hurt
On Fri, Sep 05, 2008 at 08:11:53PM +0200, Marco Pesenti Gritti wrote: On Fri, Sep 5, 2008 at 7:29 PM, Erik Garrison [EMAIL PROTECTED] wrote: I'm somewhat bothered by the completely black screenshot but see no immediate way to alleviate it. Another issue with the current patchset is that if the activity is closed by a signal from the window manager (e.g. when the user selects the 'shutdown' option from the system palette in the home view) then the screenshots are not taken, as activity.Activity.close() is not hit. Are you sure? wm close should cause a delete-event, which is implemented as: def __delete_event_cb(self, widget, event): self.close() return True Ok. Thanks for this information. When is this callback hit?: http://dev.laptop.org/git?p=sugar-toolkit;a=blob;f=src/sugar/activity/activity.py;h=73eeea7499dcd4dcd28cea5c55648b8f414654e9;hb=HEAD#l487 Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] screenshots hurt
On Thu, Sep 04, 2008 at 10:42:32AM +0200, Tomeu Vizoso wrote: On Thu, Sep 4, 2008 at 7:29 AM, Erik Garrison [EMAIL PROTECTED] wrote: The attached patch to Sugar (most recent git head, 48dd24c6e) does simply that. Andrés Ambrois and I have tested the changes in question on a machine running 656 and on a machine running 2263 (the most recent joyride I have available-- code in question is identical to the current sugar git head). We noted a considerable improvement in the speed and consistency of activity switching performance. These qualitative results are consistent with prior user interface profiling tests by Riccardo Lucchese, which have established that screenshot functionality occupies just shy of 50% of CPU time during activity switching [1]. ... The patch looks good in that it does what intends and doesn't seem to have any unintended effect. About the convenience of totally deactivating screenshots in the next release, I think it's a decision that needs to be taken on non-technical grounds. Are we going to better serve our users' interests by doing so? Is the improvement of perceived performance worth the lost functionality? Greg, can you help on this? I agree that this is not a technical issue in that the effects are purely important from a user-experiential point of view, and there is no specific system failure which the patch addresses. Removing the screenshots and the nondeterministic latencies which their creation brings to window manager navigation is the most immediate and effective measure that I have identified to improve the performance of Sugar. I'm really only interested in the responsiveness (in speed and consistency) of the system. When people say that Sugar or the XO is 'slow', they are not talking about in-activity performance. They are expressing that the process of navigating the user interface, moving between screens, and starting and stopping activities is inconvenient because it is so slow and inconsistent. With the screenshots turned off, it becomes very clear that the general minimalism of most activities gives the system a huge performance boost relative to 'heavier' UIs such as Gnome (which I have tested on the XO via debxo). Note that I understand this as a temporary measure, for the next release I think we should properly address this issue. I have just added two tickets on this regard: I do not understand this as a temporary measure as it is completely unclear why we are taking screenshots at every window manager navigation event. What problem are we trying to solve in doing so? The resultant screenshots are barely even legible when they appear in the joural. My opinion is that this should be a 8.2.0 release target. What do we need to do to initate the introduction of this patch? Technically I cannot identify anything holding this change back from distribution with the early G1G1 machines. If need be we can replace the activity screen previews in the journal with activity icons. https://dev.laptop.org/ticket/8303 https://dev.laptop.org/ticket/8304 Thank you for the tickets. Note also http://dev.laptop.org/ticket/4365 That said I am still quite unsure of what motivates this work. On a resource-constrained system such as the XO, why are we willing to sacrifice so much responsiveness for so little feature gain? I am not capable of working on system performance within the current design paradigm until I understand the motivational logic of this tradeoff and can use it to guide further work. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] screenshots hurt
On Thu, Sep 04, 2008 at 06:50:00PM +0200, Tomeu Vizoso wrote: On Thu, Sep 4, 2008 at 6:38 PM, Greg Smith [EMAIL PROTECTED] wrote: Hi Tomeu, Pardon my ignorance but what are screenshots in this context? rtfm links welcome too. These are used in the detailed view in the journal. Explain what is different about what the end user would see on the screen before and after this change. Then I can ask around and get some opinions on whether this is a cost worth bearing for greater performance. The user would stop seeing thumbnails in the journal. The user will additionally notice that alt+tab events occur twice as fast, and the latency in switching between activities is more consistent. Also, does this change improve the speed of every frame appearance? That has been a frustration for me. Users can turn off the frame but there's some important stuff there now (e.g. journal) so I think we need to make it work faster (especially make it go away faster). Would make appear the frame faster, but wouldn't affect when it goes away. For that we would need to use composition (an intended goal for 9.1.0). Right. BTW Its great to see some progress on the performance front. Certainly a concern for our users. Also great to see Andres in the loop. He is one of the best engineers I have seen who can bridge the sur and devel/sugar lists. Agreed! He certainly is! Best, Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] REVISED screenshots hurt
Devs, Attached to this email are both the original patch, which removes automated screenshot acquisition from the sugar shell, and a patch to activity.py in sugar-toolkit which adds screenshot acquisition to the user-directed 'keep' (save) event, so that the screenshot can appear in the journal when the user explicitly selects to save their work. Note that the keep event previously did not acquire a screenshot-- it was apparently assumed that it would have been acquired previously by a tabbing event. Additionally, two screenshots were acquired on every close event (one in the Shell.py code and one in the activity.py code). The effect of these patches is to retain the benefits of screenshots without incurring their costs on every window navigation event. Only user-directed 'close' and 'keep' events now trigger the screenshot. This means that there will always be screenshots after activities properly exit, or when the user elects to save data. Other automated screenshot events are removed so that system responsiveness does not suffer during window manager navigation. before, screenshots taken on these events: - frame visibility - tabbing start - activity next tab - activity previous tab - zoom into activity view - activity close (twice) after, screenshots taken on these events: - activity close (once) - activity keep / save Comments welcome. Please test and report results. Erik diff --git a/src/view/Shell.py b/src/view/Shell.py index a53ee93..b6ffbfe 100644 --- a/src/view/Shell.py +++ b/src/view/Shell.py @@ -190,8 +190,6 @@ class Shell(gobject.GObject): if level == self._model.get_zoom_level(): return -self.take_activity_screenshot() - if level == shellmodel.ShellModel.ZOOM_ACTIVITY: host = self.get_current_activity() if host is not None: @@ -208,7 +206,6 @@ class Shell(gobject.GObject): home_model = self._model.get_home() previous_activity = home_model.get_previous_activity() if previous_activity: -self.take_activity_screenshot() previous_activity.get_window().activate( gtk.get_current_event_time()) @@ -216,7 +213,6 @@ class Shell(gobject.GObject): home_model = self._model.get_home() next_activity = home_model.get_next_activity() if next_activity: -self.take_activity_screenshot() next_activity.get_window().activate(gtk.get_current_event_time()) def close_current_activity(self): @@ -228,7 +224,6 @@ class Shell(gobject.GObject): if active_activity.is_journal(): return -self.take_activity_screenshot() self.get_current_activity().close() def get_current_activity(self): diff --git a/src/view/frame/frame.py b/src/view/frame/frame.py index 6009e7f..c3f0de9 100644 --- a/src/view/frame/frame.py +++ b/src/view/frame/frame.py @@ -146,8 +146,6 @@ class Frame(object): if self._animator: self._animator.stop() -view.Shell.get_instance().take_activity_screenshot() - self.mode = mode self._animator = animator.Animator(0.5) diff --git a/src/view/tabbinghandler.py b/src/view/tabbinghandler.py index 03ce275..e3153b0 100644 --- a/src/view/tabbinghandler.py +++ b/src/view/tabbinghandler.py @@ -58,7 +58,6 @@ class TabbingHandler(object): self._tabbing = False else: shell = view.Shell.get_instance() -shell.take_activity_screenshot() self._frame.show(self._frame.MODE_NON_INTERACTIVE) diff --git a/src/sugar/activity/activity.py b/src/sugar/activity/activity.py index 73eeea7..8bdfa9d 100644 --- a/src/sugar/activity/activity.py +++ b/src/sugar/activity/activity.py @@ -171,6 +171,7 @@ class ActivityToolbar(gtk.Toolbar): self._activity.share() def __keep_clicked_cb(self, button): +self._activity.take_screenshot() self._activity.copy() def __stop_clicked_cb(self, button): ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Attention! Activity authors: spanish title translations
Activity authors, (on devel AND sugar) The following activities (which can be downloaded from http://dev.laptop.org/~erik/activities/Activities_Modif_703-7/) were modified by myself, Wad, and the Peru support team in the process of producing the most recent Peru build (http://dev.laptop.org/~erik/peru/signed-per703-7/). [ ] Analyze-6.xo25-Aug-2008 12:27 23K [ ] Chat-35b.xo 21-Aug-2008 11:54 92K [ ] ClockActivity-4.xo 25-Aug-2008 09:34 8.1K [ ] Connect-22.xo 25-Aug-2008 12:32 108K [ ] Geography-8.xo 25-Aug-2008 09:37 2.7M [ ] Implode-3.xo25-Aug-2008 12:35 28K [ ] JigsawPuzzle-4.xo 25-Aug-2008 12:40 235K [ ] Log-7.xo25-Aug-2008 12:42 12K [ ] Maze-6.xo 25-Aug-2008 12:47 68K [ ] Memorize-27.xo 25-Aug-2008 09:38 741K [ ] Moon-4.xo 25-Aug-2008 09:38 79K [ ] Read-45.xo 21-Aug-2008 11:54 101K [ ] Speak-8.xo 25-Aug-2008 09:38 32K [ ] StarChart-4.xo 25-Aug-2008 12:52 46K [ ] StopWatchActivity-2.xo 25-Aug-2008 17:20 12K [ ] TamTamEdit-48.xo25-Aug-2008 12:53 7.4M [ ] TextosCicloIV-V-14.xol 21-Aug-2008 11:55 2.8M [ ] Watch Listen-10.xo21-Aug-2008 11:55 6.3M [ ] Words-3.xo 25-Aug-2008 09:38 210K [ ] chess_computer-8.xo 25-Aug-2008 09:39 1.6M [ ] manual-2.xol21-Aug-2008 11:58 12M [ ] poesia-a-5.xol 21-Aug-2008 11:58 6.3M [ ] scalesboard-8.xo27-Aug-2008 11:20 1.7M [ ] tangram-8.xo25-Aug-2008 12:55 1.6M In all cases locale/es/activity.linfo files were added to translate the activity name that appears in the home view. In all cases the activity/activity.info version number was bumped, and in cases where the activity bundle filename didn't match convention, that number was added to the activity bundle name. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] screenshots hurt
Sugar Developers, In the field and amongst our own developers there have been numerous complaints about the performance of Sugar. One simple thing we can do to improve user experience is to stop taking screenshots on every tabbing event, every activity focus change event, and every frame appearance event. The attached patch to Sugar (most recent git head, 48dd24c6e) does simply that. Andrés Ambrois and I have tested the changes in question on a machine running 656 and on a machine running 2263 (the most recent joyride I have available-- code in question is identical to the current sugar git head). We noted a considerable improvement in the speed and consistency of activity switching performance. These qualitative results are consistent with prior user interface profiling tests by Riccardo Lucchese, which have established that screenshot functionality occupies just shy of 50% of CPU time during activity switching [1]. Please apply the patch and test on a *REAL* machine. Please comment on the effects. Note that on recent joyride builds the appearance of the frame on every tabbing event makes it more difficult to notice the performance change. Erik [1] http://lists.laptop.org/pipermail/devel/2008-July/016722.html The lines removed by the attached patch were part of the following commits: commit f36b76ed905e52fb5b5848e09bf34a91216e Author: Marco Pesenti Gritti [EMAIL PROTECTED] Date: Tue Oct 23 15:19:17 2007 +0200 commit 0f565484a95c083d89c6f40b0d390d4109b5c46f Author: Benjamin Berg [EMAIL PROTECTED] Date: Fri Jun 20 16:49:38 2008 +0200 commit 14f1ca9b8491dee343305066facf8e7ae24e381f Author: Tomeu Vizoso [EMAIL PROTECTED] Date: Wed Apr 2 14:53:52 2008 +0200 diff --git a/src/view/Shell.py b/src/view/Shell.py index a53ee93..b6ffbfe 100644 --- a/src/view/Shell.py +++ b/src/view/Shell.py @@ -190,8 +190,6 @@ class Shell(gobject.GObject): if level == self._model.get_zoom_level(): return -self.take_activity_screenshot() - if level == shellmodel.ShellModel.ZOOM_ACTIVITY: host = self.get_current_activity() if host is not None: @@ -208,7 +206,6 @@ class Shell(gobject.GObject): home_model = self._model.get_home() previous_activity = home_model.get_previous_activity() if previous_activity: -self.take_activity_screenshot() previous_activity.get_window().activate( gtk.get_current_event_time()) @@ -216,7 +213,6 @@ class Shell(gobject.GObject): home_model = self._model.get_home() next_activity = home_model.get_next_activity() if next_activity: -self.take_activity_screenshot() next_activity.get_window().activate(gtk.get_current_event_time()) def close_current_activity(self): @@ -228,7 +224,6 @@ class Shell(gobject.GObject): if active_activity.is_journal(): return -self.take_activity_screenshot() self.get_current_activity().close() def get_current_activity(self): diff --git a/src/view/frame/frame.py b/src/view/frame/frame.py index 6009e7f..c3f0de9 100644 --- a/src/view/frame/frame.py +++ b/src/view/frame/frame.py @@ -146,8 +146,6 @@ class Frame(object): if self._animator: self._animator.stop() -view.Shell.get_instance().take_activity_screenshot() - self.mode = mode self._animator = animator.Animator(0.5) diff --git a/src/view/tabbinghandler.py b/src/view/tabbinghandler.py index 03ce275..e3153b0 100644 --- a/src/view/tabbinghandler.py +++ b/src/view/tabbinghandler.py @@ -58,7 +58,6 @@ class TabbingHandler(object): self._tabbing = False else: shell = view.Shell.get_instance() -shell.take_activity_screenshot() self._frame.show(self._frame.MODE_NON_INTERACTIVE) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Trac #7480: Need to 'reset' the network configurations - short term fix
On Tue, Aug 12, 2008 at 12:02:41AM -0400, Michael Stone wrote:
On Mon, Aug 11, 2008 at 09:31:26PM -0400, Erik Garrison wrote:
Attached is a patch which adds a 'reset network configuration' button to
the network tab of the sugar control panel.
Thanks very much for the patch, and for the thoughtful design.
+n = 1 + max(map(lambda x: int(x.replace('networks.cfg.bak.', '')),
+network_cfgs))
This expression, while cute, is unsafe and will result in failure if you
ever encounter a file with a name like 'networks.cfg.bak.hi'.
The solution is to guarantee that inputs are of the correct form
(networks.cfg.bak.\d+$). As follows, two lines previously should be:
network_cfgs = [file
for file in os.listdir('/home/olpc/.sugar/default/nm')
if re.match('networks.cfg.bak.\d+$', file)]
Please write total code or handle exceptions appropriately.
I don't understand what you mean by 'total' code. You do not need to
ask me to write bug-free code. That is what I'm trying to do. Pleaese
just say 'I found a problem' and update the patch.
(Incidentally, does anything bad happen if your code does happen to
generate exceptions?)
I have no idea and I don't expect I will have time to test it prior to
my departure.
Sorry.
Erik
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Trac #7480: Need to 'reset' the network configurations - short term fix
On Thu, Aug 14, 2008 at 11:34:58AM -0400, Michael Stone wrote:
On Thu, Aug 14, 2008 at 11:12:09AM -0400, Erik Garrison wrote:
On Tue, Aug 12, 2008 at 12:02:41AM -0400, Michael Stone wrote:
On Mon, Aug 11, 2008 at 09:31:26PM -0400, Erik Garrison wrote:
Attached is a patch which adds a 'reset network configuration' button to
the network tab of the sugar control panel.
Thanks very much for the patch, and for the thoughtful design.
+n = 1 + max(map(lambda x: int(x.replace('networks.cfg.bak.', '')),
+network_cfgs))
This expression, while cute, is unsafe and will result in failure if you
ever encounter a file with a name like 'networks.cfg.bak.hi'.
The solution is to guarantee that inputs are of the correct form
(networks.cfg.bak.\d+$). As follows, two lines previously should be:
network_cfgs = [file
for file in os.listdir('/home/olpc/.sugar/default/nm')
if re.match('networks.cfg.bak.\d+$', file)]
Please write total code or handle exceptions appropriately.
I don't understand what you mean by 'total' code.
Total (as opposed to partial) functions, programs, expressions, etc. are
defined for every possible input rather than for only some of their
inputs. The way you defined network_cfgs was partial in that, in
addition to generating an exception, it also left n undefined (not
even set to None) for some inputs (such as those I described).
You do not need to ask me to write bug-free code.
There are actually lots of people (including myself) who I find I have
to ask to write bug-free code (often concerning race conditions).
However, I'm glad to hear that you care deeply about it as well.
Please just say 'I found a problem' and update the patch.
As you prefer.
Michael,
Sorry to be so testy, it was completely unecessary to nitpick your
comments! I obviously am rushing to get this done and perhaps it is
better to ask me to be careful as I do so than not.
I'm worried that I won't have time to update this patch and get the work
done for Perú today and tomorrow. We need to figure out what to do with
this ticket going forward. There is a lot of discussion of various ways
to implement this hack that I have yet to evaluate. If I don't get this
done by Friday who is going to take the ticket?
Erik
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Trac #7480: Need to 'reset' the network configurations - short term fix
On Thu, Aug 14, 2008 at 11:44:12AM -0400, Erik Garrison wrote:
On Thu, Aug 14, 2008 at 11:34:58AM -0400, Michael Stone wrote:
On Thu, Aug 14, 2008 at 11:12:09AM -0400, Erik Garrison wrote:
On Tue, Aug 12, 2008 at 12:02:41AM -0400, Michael Stone wrote:
On Mon, Aug 11, 2008 at 09:31:26PM -0400, Erik Garrison wrote:
Attached is a patch which adds a 'reset network configuration' button to
the network tab of the sugar control panel.
Thanks very much for the patch, and for the thoughtful design.
+n = 1 + max(map(lambda x: int(x.replace('networks.cfg.bak.',
'')),
+network_cfgs))
This expression, while cute, is unsafe and will result in failure if you
ever encounter a file with a name like 'networks.cfg.bak.hi'.
The solution is to guarantee that inputs are of the correct form
(networks.cfg.bak.\d+$). As follows, two lines previously should be:
network_cfgs = [file
for file in os.listdir('/home/olpc/.sugar/default/nm')
if re.match('networks.cfg.bak.\d+$', file)]
Please write total code or handle exceptions appropriately.
I don't understand what you mean by 'total' code.
Total (as opposed to partial) functions, programs, expressions, etc. are
defined for every possible input rather than for only some of their
inputs. The way you defined network_cfgs was partial in that, in
addition to generating an exception, it also left n undefined (not
even set to None) for some inputs (such as those I described).
You do not need to ask me to write bug-free code.
There are actually lots of people (including myself) who I find I have
to ask to write bug-free code (often concerning race conditions).
However, I'm glad to hear that you care deeply about it as well.
Please just say 'I found a problem' and update the patch.
As you prefer.
Michael,
Sorry to be so testy, it was completely unecessary to nitpick your
comments! I obviously am rushing to get this done and perhaps it is
better to ask me to be careful as I do so than not.
By which I meant I obviously am rushing to get this done and perhaps it
is better to ask me to be careful than not.
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Trac #7480: Need to 'reset' the network configurations - short term fix
On Tue, Aug 12, 2008 at 10:26:08AM +0200, Morgan Collett wrote: On Tue, Aug 12, 2008 at 03:31, Erik Garrison [EMAIL PROTECTED] wrote: Attached is a patch which adds a 'reset network configuration' button to the network tab of the sugar control panel. Clicking this button simply rotates the config file out of the way, saving it as ~/.sugar/default/nm/networks.cfg.bak.NNN (NNN is the number of previously backed-up configs +1). This is just a short-term fix (hack) to resolve the problem of not having any gui-level method to manipulate the nm network configarion. Eben has noted that we would like to enable config panel level manipulation of the networks.cfg stanzas; but this requires a bit more code than this immediate fix. This needs testing: in some cases NM replaces the config with what was there. I added a different AP to my home network (in parallel with my existing AP). To get the XOs to associate only with the new AP, I thought I'd simply delete networks.cfg and then associate to the new AP. When I rebooted to make sure it did what I wanted, networks.cfg had both the old and the new APs. To end up with only the new AP in networks.cfg, I had to first associate to the new AP, then remove the old one from networks.cfg - then rebooting after that showed only the new one. I did test this and saw that the networks.cfg file was written again. It appeared that NM was rewriting the config whenever it associated with an AP. sjored notes that NM 0.6 behaves this way, but I'm not sure it's an issue we are trying to address here. I think the rationale for the reset button is the following: From the sugar control panel we need to be able to 'reset' or remove the stored network configuration file. This is important to do whenever someone makes a change to their AP settings, changes the password, and it might also help us debug some of the problems we are seeing with intermittent AP connections. ( kimquirk, trac #7480 ) The scope of this fix is pretty small. Just make sure that stored passwords are reset, and clear out cruft from the networks.cfg file. Am I missing anything? I don't think pushing a fix into NM 0.6 is a good use of our time, so I'm not sure what else we can do. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] Trac #7480: Need to 'reset' the network configurations - short term fix
Attached is a patch which adds a 'reset network configuration' button to
the network tab of the sugar control panel. Clicking this button simply
rotates the config file out of the way, saving it as
~/.sugar/default/nm/networks.cfg.bak.NNN (NNN is the number of
previously backed-up configs +1).
This is just a short-term fix (hack) to resolve the problem of not
having any gui-level method to manipulate the nm network configarion.
Eben has noted that we would like to enable config panel level
manipulation of the networks.cfg stanzas; but this requires a bit more
code than this immediate fix.
Erik
diff --git a/src/controlpanel/model/network.py b/src/controlpanel/model/network.py
index d24c986..135aac1 100644
--- a/src/controlpanel/model/network.py
+++ b/src/controlpanel/model/network.py
@@ -20,6 +20,9 @@ from gettext import gettext as _
from sugar import profile
+import os
+import re
+
NM_SERVICE_NAME = 'org.freedesktop.NetworkManager'
NM_SERVICE_PATH = '/org/freedesktop/NetworkManager'
NM_SERVICE_IFACE = 'org.freedesktop.NetworkManager'
@@ -83,3 +86,22 @@ def set_radio(state):
raise ValueError(_(Error in specified radio argument use on/off.))
return 0
+
+
+def clear_networks_config_file():
+Rotate the networks configuration file into networks.cfg.bak.
+network_cfg = '/home/olpc/.sugar/default/nm/networks.cfg'
+# find the config files
+network_cfgs = [file
+for file in os.listdir('/home/olpc/.sugar/default/nm')
+if re.match('networks.cfg.bak.', file)
+]
+# establish the largest config file number
+if network_cfgs:
+n = 1 + max(map(lambda x: int(x.replace('networks.cfg.bak.', '')),
+network_cfgs))
+else:
+n = 1
+# move the existing config file out of the way
+if os.path.exists(network_cfg):
+os.rename(network_cfg, '%s.bak.%i' % (network_cfg, n))
diff --git a/src/controlpanel/view/network.py b/src/controlpanel/view/network.py
index af64a1a..a59c54c 100644
--- a/src/controlpanel/view/network.py
+++ b/src/controlpanel/view/network.py
@@ -38,6 +38,7 @@ class Network(SectionView):
self._radio_valid = True
self._jabber_change_handler = None
self._radio_change_handler = None
+self._network_configuation_reset_handler = None
self.set_border_width(style.DEFAULT_SPACING * 2)
self.set_spacing(style.DEFAULT_SPACING)
@@ -57,6 +58,7 @@ class Network(SectionView):
box_wireless = gtk.VBox()
box_wireless.set_border_width(style.DEFAULT_SPACING * 2)
box_wireless.set_spacing(style.DEFAULT_SPACING)
+
box_radio = gtk.HBox(spacing=style.DEFAULT_SPACING)
label_radio = gtk.Label(_('Radio:'))
label_radio.set_alignment(1, 0.5)
@@ -65,6 +67,7 @@ class Network(SectionView):
box_radio.pack_start(label_radio, expand=False)
group.add_widget(label_radio)
label_radio.show()
+
self._button = gtk.CheckButton()
self._button.set_alignment(0, 0)
box_radio.pack_start(self._button, expand=False)
@@ -72,6 +75,22 @@ class Network(SectionView):
box_wireless.pack_start(box_radio, expand=False)
box_radio.show()
+box_reset_config = gtk.HBox(spacing=style.DEFAULT_SPACING)
+label_reset_config = gtk.Label(_('Clear preferred networks:'))
+label_reset_config.set_alignment(1, 0.5)
+label_reset_config.modify_fg(gtk.STATE_NORMAL,
+ style.COLOR_SELECTION_GREY.get_gdk_color())
+box_reset_config.pack_start(label_reset_config, expand=False)
+group.add_widget(label_reset_config)
+label_reset_config.show()
+
+self._reset_config_button = gtk.Button(stock=gtk.STOCK_CLEAR)
+self._reset_config_button.set_alignment(0, 0)
+box_reset_config.pack_start(self._reset_config_button, expand=False)
+self._reset_config_button.show()
+box_wireless.pack_end(box_reset_config, expand=False)
+box_reset_config.show()
+
self._radio_alert = InlineAlert()
label_radio_error = gtk.Label()
group.add_widget(label_radio_error)
@@ -153,6 +172,9 @@ class Network(SectionView):
'toggled', self.__radio_toggled_cb)
self._jabber_change_handler = self._entry.connect( \
'changed', self.__jabber_changed_cb)
+self._network_configuation_reset_handler = \
+self._reset_config_button.connect( \
+'clicked', self.__network_configuation_reset_cb)
def undo(self):
self._button.disconnect(self._radio_change_handler)
@@ -207,3 +229,6 @@ class Network(SectionView):
self._jabber_alert.show()
return False
+
+def __network_configuation_reset_cb(self, widget):
+self._model.clear_networks_config_file()
___
Re: [sugar] specifying what services Activities may use
On Thu, Jul 31, 2008 at 12:40:39AM +0200, Bastien wrote: It's not that important anyway. It just occurred to me that the dependancies management challenge could be somehow dealt with by delivering a set of default activities. I'm not aware of any software distribution drawing such a strong line between the core system and the applications/activities. We have been managing the dependency issue by ensuring that the 'core' activities required for a given build all work on the system-level software packages we include. To my knowledge this verification has been done manually. We could better share our efforts by working to make sure that a given activity simply lists the correct set of dependencies, pushing this data to a package repository, and supporting deployments as they cherry-pick their requirements from it to construct new images and push their products back into it. The separation between system and application-level software is a core roadblock in our integration of more intelligent package management policies. How can an isolated user-level package management application be allowed to modify system-level, shared, code that will affect other applications from which it is supposed to be isolated? A unification of system and application-level software package management thus violates our security model. The user-level application isolation required by this security model serves to enable easier code sharing between children. It also makes it easier for sysadmins to accept the use of relatively untested software packages on the XO. We can probably all agree that the separation between system and application software is useful for security and the execution of untrusted code. Can we reasonably work around this distinction to allow the management of both sets of software as one whole? Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Performance
On Thu, Jul 24, 2008 at 06:16:33AM -0400, Greg Smith wrote: Hi All, I just got word from a decision maker in Uruguay that they are very concerned about performance. They say that Sugar is slow. I'm probing to get more details but I want to evaluate the options in parallel. Focus is on improving this in 8.2.0. Here are the areas I can think of: - Activity launch time I know we had some threads on this but I don't know where we stand. Can I get an update and an evaluation of what it will take to greatly improve this? - File/activity open Can we improve this? A piece of the latency here may be due to a large Journal being much slower. Can we chunk journal reads or otherwise improve the speed of opening files? Can we speed up journal access in its own GUI too? - File save What is the bottle neck on save? Let's create a test case for this. - Task switching I've seen some threads on this. Can someone summarize it and give me a hard number to show how we have improved? - Hardware Can anyone evaluate how much faster it would be with twice the RAM? Is the NAND slowing us down? My impression is that all of the above areas of user experience are bound by filesystem io performance and can be greatly affected by changing the compression scheme which we use on the jffs2 filesystem. Tests by NoiseEHC (and to a less rigorous extent by myself) suggest that moving to LZO compression would greatly speed up read and write to the data store (by at least several times). The problem with such improvements is that often they require changes in low-level system compononents. In the case of LZO compression we would have to reformat the root filesystem and modify the kernel configuration. The simplest way to execute this is via a reflash of an existing system. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] SMS messaging
On Thu, Jul 17, 2008 at 03:44:45PM -0400, Ankur Verma wrote: Hello, I am able to receive SMS text messages through a mobile phone intended to be attached to school server. I need to forward this message to a specific XO connected on the jabber server. At this moment, I have the message in the format XO_name:SMS_Message. My plan is: 1. Get information (Unfriendly Jabber ID? or Nick?) about all the XOs connected. 2. Compare against the XO_name in message. 3. Send SMS_message to it in the form of XMPP message. - message received by sms service (for local addressing) - service uses message header (characters prior to ':') to do local routing - message is sent to that xo So this is sms - jabber - xo. Do you also wish to implement xo - jabber - sms? Kindly tell me how should I proceed? I will appreciate any pointers/alternative approaches from your side. You should investigate: http://www.ejabberd.im/mod_sms http://www.dp.uz.gov.ua/o.palij/mod_sms/ I am reading this very loosely and quickly, but it appears that this ejabberd module can integrate ejabber with an sms-smtp transport service located at (e.g.) sms.exampligratia.net in order to provide sms functionality. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] SMS messaging
Ah, I understand. It is probably best to discuss this with people working on the presence service.. On Sat, Jul 19, 2008 at 11:53:49AM -0400, Ankur Verma wrote: Hi Erik, Thanks for your help. However, I wish to implement jabber-xo part in sms-jabber-xo for which I will need the list of XOs on server to do local routing to specific XO. Thanks Ankur Verma On Sat, Jul 19, 2008 at 11:19 AM, Erik Garrison [EMAIL PROTECTED] wrote: On Thu, Jul 17, 2008 at 03:44:45PM -0400, Ankur Verma wrote: Hello, I am able to receive SMS text messages through a mobile phone intended to be attached to school server. I need to forward this message to a specific XO connected on the jabber server. At this moment, I have the message in the format XO_name:SMS_Message. My plan is: 1. Get information (Unfriendly Jabber ID? or Nick?) about all the XOs connected. 2. Compare against the XO_name in message. 3. Send SMS_message to it in the form of XMPP message. - message received by sms service (for local addressing) - service uses message header (characters prior to ':') to do local routing - message is sent to that xo So this is sms - jabber - xo. Do you also wish to implement xo - jabber - sms? Kindly tell me how should I proceed? I will appreciate any pointers/alternative approaches from your side. You should investigate: http://www.ejabberd.im/mod_sms http://www.dp.uz.gov.ua/o.palij/mod_sms/ I am reading this very loosely and quickly, but it appears that this ejabberd module can integrate ejabber with an sms-smtp transport service located at (e.g.) sms.exampligratia.net in order to provide sms functionality. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Write needs your help (was Re: Programming environments on the XO)
On Thu, Jul 17, 2008 at 10:16:07AM +0200, Tomeu Vizoso wrote: If we cannot bring all the abiword potential to Sugar's Write, we risk someone will start asking for running unsugarized OpenOffice or Abiword on the XO, just as happened with Browse :/ Given the quantity of free software available for Linux distributions relative to the quantity of available sugarized applications, I believe that repeats of this pattern will be inevitable. As I understand, there are a variety of problems with the use of unsugarized applications: - UI issues because of high screen dpi and small size. - Journal integration. - Resource utilization. - Bitfröst and security concerns. - Collaboration. I expect there are others and would be happy to know them so that I better understand this problem. --- By simplifying Journal integration and collaboration, the following steps might improve our ability to support unsugarized apps without sacrificing much in the way of user experience. To simplify Journal/datastore integration: *) Remove the Bitfröst application isolation scheme or modify it such that Activities could write to arbitrary locations in which the olpc user has write permissions. This would allow unsugarized activities to write to places they (as Linux apps) expect to be able to write, such as /home/olpc/ (e.g. for configuration settings and saving user files). *) Make the Journal a watcher and indexer instead of a gatekeeper to the user's data so that applications no longer need to be ported to write data and metadata via the datastore API. We could use inotify(7) to add a watch to the user's home directory. The watching application (Journal) could hold a table of typically used files - Activities / applications. We would still require work to establish which frequently changed files (configuration files, caches) we should be ignoring, and to set default save directories. If a kid writes a file to a very strange place, inotify handlers will allow the journal to keep track of it. Existing code (used for similar indexing applications on Linux desktop systems) could be used to glean file metadata. After modified files are located and metadata gleaned, the Journal would be free to play the same role as it currently does. To provide a fallback, base-level collaboration system: *) Offer a collaboration directory in the user's /home/olpc/, such that simple filesharing can take place. This directory could be managed similarly (reactively to user-driven events) using inotify and a collaboration daemon which manages the broadcast and sharing of files. I'm imagining a network-shared directory such as those found in systems such as NFS, sshfs, samba, etc. --- These are just shiny ideas. I thought I would posit them publicly for eventual comment. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Write needs your help (was Re: Programming environments on the XO)
These are suggestions with a longterm focus. On Thu, Jul 17, 2008 at 01:02:04PM -0400, Erik Garrison wrote: On Thu, Jul 17, 2008 at 10:16:07AM +0200, Tomeu Vizoso wrote: If we cannot bring all the abiword potential to Sugar's Write, we risk someone will start asking for running unsugarized OpenOffice or Abiword on the XO, just as happened with Browse :/ Given the quantity of free software available for Linux distributions relative to the quantity of available sugarized applications, I believe that repeats of this pattern will be inevitable. As I understand, there are a variety of problems with the use of unsugarized applications: - UI issues because of high screen dpi and small size. - Journal integration. - Resource utilization. - Bitfröst and security concerns. - Collaboration. I expect there are others and would be happy to know them so that I better understand this problem. --- By simplifying Journal integration and collaboration, the following steps might improve our ability to support unsugarized apps without sacrificing much in the way of user experience. To simplify Journal/datastore integration: *) Remove the Bitfröst application isolation scheme or modify it such that Activities could write to arbitrary locations in which the olpc user has write permissions. This would allow unsugarized activities to write to places they (as Linux apps) expect to be able to write, such as /home/olpc/ (e.g. for configuration settings and saving user files). *) Make the Journal a watcher and indexer instead of a gatekeeper to the user's data so that applications no longer need to be ported to write data and metadata via the datastore API. We could use inotify(7) to add a watch to the user's home directory. The watching application (Journal) could hold a table of typically used files - Activities / applications. We would still require work to establish which frequently changed files (configuration files, caches) we should be ignoring, and to set default save directories. If a kid writes a file to a very strange place, inotify handlers will allow the journal to keep track of it. Existing code (used for similar indexing applications on Linux desktop systems) could be used to glean file metadata. After modified files are located and metadata gleaned, the Journal would be free to play the same role as it currently does. To provide a fallback, base-level collaboration system: *) Offer a collaboration directory in the user's /home/olpc/, such that simple filesharing can take place. This directory could be managed similarly (reactively to user-driven events) using inotify and a collaboration daemon which manages the broadcast and sharing of files. I'm imagining a network-shared directory such as those found in systems such as NFS, sshfs, samba, etc. --- These are just shiny ideas. I thought I would posit them publicly for eventual comment. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] #447: grab/scroll key
On Mon, Jul 14, 2008 at 05:36:44AM -0400, Brian Jordan wrote: On Mon, Jul 14, 2008 at 12:06 AM, Erik Garrison [EMAIL PROTECTED] wrote: I like Brian's idea but felt similarly about the difficulty in deciding which hand button executes which function. SHIFT-HAND is a good solution, and relatively easy to implement. Agreed, SHIFT-HAND +1 UI wise, will there be a way to distinguish between SHIFT-HAND and a regular click? For example, in Physics, I can imagine having SHIFT-HAND move objects around even if a non-grab tool is selected. I think it would be possible at the price of a degree of software complexity. We would probably have to modify the keyhandler to issue some kind of signal about the grab state. Your application would have to listen for that signal. I suspect there is a way to manage this at your client application's level. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] #447: grab/scroll key
Sugar devs:
This is a copy of my bug report for #447. I have completed a first pass
of the grab key implementation.
-Erik
Summary:
I used the grab keys to convert the touchpad into a virtual
mouse scrollwheel. Holding down the grab key and moving the mouse a
small number pixels causes a fake mouse button 4/5/6/7 press, depending
on the direction of motion. This approach works in all applications
which support mouse scroll buttons.
Patches:
The attached patch to sugar-toolkit adds glib/C-side hooks to grab an
ungrab the mouse, and pass motion-notify events to the python side of
the Sugar shell. I have packaged this patch in an rpm which should be
installable on an XO running a recent joyride (tested on joyride-2123).
(RPMS: tested but slightly older git snapshot:
http://dev.laptop.org/~erik/rpms/sugar-toolkit-debuginfo-0.81.5-4.20080705gitab8c054dfb.fc9.i386.rpm
or, untested but slightly newer git snapshot:
http://dev.laptop.org/~erik/rpms/sugar-toolkit-0.81.6-1.fc9.i386.rpm)
The attached patch to sugar (specifically keyhandler.py) adds the
python-side hooks required to enable the grab/scroll button
functionality.
The patches work in the following manner:
When the left or right grab buttons are pressed, XGrabPointer is
called. Subsequently, we capture all of the motion-notify events
which occur when the user moves the mouse, and each event hits
KeyHandler._motion_notify_cb() with the coordinates of the mouse.
After we move N pixels (currently 10) we issue a fake mouse scroll
button press corresponding to the direction of motion of the mouse
(4/5/6/7). To issue the fake button press I have found it is
necessary to ungrab the mouse, issue the press, and then re-grab.
Known issues:
In some cases key-releases are not registered. This is problematic
because without the release signal the mouse grabbing does not
stop and Sugar becomes entirely unusable. I have not been able to
establish why, but have noticed that hitting the journal view key
after Sugar startup before any of the other special keys
(registered in keyhandler.py) tends to resolve the issue for the
Super_L and Super_R keys (the grab buttons).
The mouse still scrolls around the screen, and the cursor is
visible during the grab. Solution: Hide the mouse; When a grab key
press is registered, hide the mouse by setting the cursor pixmap
to a blank map (and set it back when the grab key release is
registered).
Eventually, after scrolling in one direction, the mouse can move
out of or to the edge of the scrolling window and the scrolling
stops. Solution: Every time we issue a fake button press, warp the
mouse back to the position it was at when we first pressed the
grab key.
From 9fd6e08513d7829c9919b109d49a554588d63c71 Mon Sep 17 00:00:00 2001
From: Erik Garrison [EMAIL PROTECTED]
Date: Wed, 9 Jul 2008 18:48:33 -0400
Subject: [PATCH] #447: Enable grab/scroll button functionality.
---
src/view/keyhandler.py | 46 ++
1 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/src/view/keyhandler.py b/src/view/keyhandler.py
index 44ea759..d1140be 100644
--- a/src/view/keyhandler.py
+++ b/src/view/keyhandler.py
@@ -62,6 +62,8 @@ _actions_table = {
'altshifto' : 'open_search',
'altshiftr' : 'rotate',
'altshifts' : 'say_text',
+'Super_L': 'grab_button_pressed',
+'Super_R': 'grab_button_pressed',
}
J_DBUS_SERVICE = 'org.laptop.Journal'
@@ -78,6 +80,8 @@ class KeyHandler(object):
self._key_pressed = None
self._keycode_pressed = 0
self._keystate_pressed = 0
+self._mouse_xy = [None, None]
+self._grab_key_mouse_delta = 10
self._speech_proxy = None
self._key_grabber = KeyGrabber()
@@ -85,6 +89,8 @@ class KeyHandler(object):
self._key_pressed_cb)
self._key_grabber.connect('key-released',
self._key_released_cb)
+self._key_grabber.connect('motion-notify',
+ self._motion_notify_cb)
self._tabbing_handler = TabbingHandler(_TABBING_MODIFIER)
@@ -137,6 +143,13 @@ class KeyHandler(object):
self._get_speech_proxy().SayText(text, reply_handler=lambda: None, \
error_handler=self._on_speech_err)
+def handle_grab_button_pressed(self):
+self._key_grabber.grab_pointer()
+
+def handle_grab_button_released(self):
+self._key_grabber.ungrab_pointer()
+self._mouse_xy = [None, None]
+
def handle_say_text(self):
clipboard = gtk.clipboard_get(selection=PRIMARY)
clipboard.request_text(self._primary_selection_cb)
@@ -278,6 +291,10 @@ class KeyHandler(object):
return False
def _key_released_cb(self, grabber, keycode, state):
+logging.debug('_key_released_cb: %i %i
[sugar] [EMAIL PROTECTED]: Re: the OLPC XO grab button (triggering mouse scrolling using a keypress)]
Advice about how to implement the grab button functionality from the xorg dev list. - Forwarded message from Peter Hutterer [EMAIL PROTECTED] - Date: Tue, 1 Jul 2008 15:52:09 +0930 From: Peter Hutterer [EMAIL PROTECTED] To: Erik Garrison [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: the OLPC XO grab button (triggering mouse scrolling using a keypress) On Mon, Jun 30, 2008 at 07:35:16PM -0400, Erik Garrison wrote: The keyboard has two buttons which are marked with a hand. The interested may see a schematic at http://wiki.laptop.org/go/OLPC_Keyboard_layouts. It was intended at design time that pressing either of these buttons (Super_L and Super_R) and simultaneously moving the mouse would trigger x and y scrolling in X11 applications. I'm curious if anyone knows of ways in which similar functionality has been implemented elsewhere. In general I'd like some advice about the best place to implement this feature. Just put a passive grab on the keys to receive the key press event and then, depending on what you mean by scrolling: - mouse wheel emulation put a (sync) grab on the mouse and use XTestFakeButtonEvent on buttons 4/5/6/7 for to scroll. you'll need to mess around a bit with XAllowEvents, but it should work. - viewport scrolling XWarpPointer seems the only way, I don't see any other callers for xf86SetViewport that could be used directly. Cheers, Peter - End forwarded message - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [SURVEY] builders, how do you build? what do you build?
Developers, specifically those running build systems, Many of us are confused about the software flows inherent in the daily build processes which are occuring at OLPC. I would like to conduct a simple survey of all people building software for OLPC so that all of us can better understand the sources of the software running on the XO and XS without individually hassling the responsible parties every time we have generic questions about their build processes. Builders, please describe your local build network: 0) Who are you and who do you directly work for? 1) What do you build? 2) Where does it come from? / Who directly provides you with source code? 3) Where does the output of your build process go? / Who handles the immediate output of your builds? 4) Where specifically is it built? (I want server names and/or descriptions, where security is a concern please share them with me privately.) 5) What build systems do you use to build software? Please briefly describe their operation or provide a link to documentation or source code which does. In your responses please focus on the usual, simplest-case situation. The goal of this survey is to ascertain the everyday manner in which your builds progress. Feel free to include additional notes about the local network of developers you interact with--- it's fine and helpful to explain what you think happens one or two steps up or down the chain. Where possible please cc the olpc-devel list. I will take the results of this survey and produce an overview of the software flows which lead to our daily builds. As much as possible I will do this in graphical form so the results can be quickly understood by all of us. I will provide this report by email to olpc-devel as soon as possible. Thanks in advance, Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] to Browse activity; trac #6250
The following patch resolves trac #6250 (and #6999). I have tested and pushed the patch into the web-activity git repo. From 9e3c4d01dc2b368ef0636cce598dd655446fb883 Mon Sep 17 00:00:00 2001 From: Erik Garrison [EMAIL PROTECTED] Date: Tue, 10 Jun 2008 14:29:17 -0400 Subject: [PATCH] To resolve trac 6250, we disable browser detection of offline mode using xpcom. --- browser.py |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/browser.py b/browser.py index f57bafa..208ff93 100644 --- a/browser.py +++ b/browser.py @@ -83,6 +83,11 @@ class Browser(WebView): @mozilla.org/network/io-service;1] io_service = io_service_class.getService(interfaces.nsIIOService) +# Use xpcom to turn off offline mode detection, which disables +# access to localhost for no good reason. (Trac #6250.) +io_service2 = io_service_class.getService(interfaces.nsIIOService2) +io_service2.manageOfflineStatus = False + cls = components.classes['@mozilla.org/content/style-sheet-service;1'] style_sheet_service = cls.getService(interfaces.nsIStyleSheetService) -- 1.5.4.3 From 9e3c4d01dc2b368ef0636cce598dd655446fb883 Mon Sep 17 00:00:00 2001 From: Erik Garrison [EMAIL PROTECTED] Date: Tue, 10 Jun 2008 14:29:17 -0400 Subject: [PATCH] To resolve trac 6250, we disable browser detection of offline mode using xpcom. --- browser.py |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/browser.py b/browser.py index f57bafa..208ff93 100644 --- a/browser.py +++ b/browser.py @@ -83,6 +83,11 @@ class Browser(WebView): @mozilla.org/network/io-service;1] io_service = io_service_class.getService(interfaces.nsIIOService) +# Use xpcom to turn off offline mode detection, which disables +# access to localhost for no good reason. (Trac #6250.) +io_service2 = io_service_class.getService(interfaces.nsIIOService2) +io_service2.manageOfflineStatus = False + cls = components.classes['@mozilla.org/content/style-sheet-service;1'] style_sheet_service = cls.getService(interfaces.nsIStyleSheetService) -- 1.5.4.3 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] python imports and performance (was Re: #5549 ...)
On Mon, Jun 09, 2008 at 12:35:56PM -0400, C. Scott Ananian wrote: p.s. I suspect part of the larger startup issue may be that we are rendering SVGs on demand for the toolbar, etc. We can either defer that rendering, allowing us to open the activity quickly and then later fill in the icons (as the gnome panel does), or maintain a persistent cache of SVG renderings. If this is the case I will work on it immediately. Load-time rendered SVGs should be cached. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Wed, Jun 04, 2008 at 10:28:25AM +0200, Tomeu Vizoso wrote: On Tue, Jun 3, 2008 at 7:19 PM, Erik Garrison [EMAIL PROTECTED] wrote: On Tue, Jun 03, 2008 at 01:53:37PM +0200, Tomeu Vizoso wrote: On Tue, Jun 3, 2008 at 1:50 PM, Walter Bender [EMAIL PROTECTED] wrote: Alas, two more open bugs that should be considered by someone: (1) Record has been broken in Joyride for quite some time: ever since the introduction of compositing? (#6850) I am looking into this. Awesome. I currently believe that I've narrowed the bug down to something involving the colorspace conversion filter used in gstreamer (ffmpegcolorspace). See the ticket (http://dev.laptop.org/ticket/6850) for more details. Joyride has no composite enabled, so this seems to be something different. According to xdpyinfo the Composite extension is enabled on joyride 1998. So if this is different it is different in a way that xdpyinfo does not know. xdpyinfo reports that the composite extension is present, and I think that this has been like this since always. The difference between joyride and faster is that in the latter the window manager includes a composition manager that creates offscreen pixmaps for every window. Look for XCompositeRedirectSubwindows for more details in: http://ktown.kde.org/~fredrik/composite_howto.html http://svn.o-hand.com/view/matchbox/trunk/matchbox-window-manager/src/composite-engine.c?rev=1084view=markup Thanks. This makes sense to me. On 1998 I get the following messages to the virtual terminal (I assume they are delivered via printk): cafe1000-ccic :00:0c.2: Frame overrun on 1, frames lost ... 59 printk messages suppressed ... No idea about this :/ What it means is that userspace software isn't processing buffers from the cafe chip fast enough. So they get thrown away. Does not appear to be a problem with the cafe1000-ccic driver. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 03, 2008 at 11:03:44AM +0200, Marco Pesenti Gritti wrote: The feature (and strings) freeze is approaching very quickly. We have 17 days left. Can we make a quick list of things that we need to get in by the 20 June? This is a feature freeze, not a bugfix/patch freeze, correct? Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Preparing for the feature freeze
On Tue, Jun 03, 2008 at 01:53:37PM +0200, Tomeu Vizoso wrote: On Tue, Jun 3, 2008 at 1:50 PM, Walter Bender [EMAIL PROTECTED] wrote: Alas, two more open bugs that should be considered by someone: (1) Record has been broken in Joyride for quite some time: ever since the introduction of compositing? (#6850) I am looking into this. Joyride has no composite enabled, so this seems to be something different. According to xdpyinfo the Composite extension is enabled on joyride 1998. So if this is different it is different in a way that xdpyinfo does not know. On 1998 I get the following messages to the virtual terminal (I assume they are delivered via printk): cafe1000-ccic :00:0c.2: Frame overrun on 1, frames lost ... 59 printk messages suppressed ... Any ideas? Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] patch to sync display orientation and d-pad orientation
Sugar devs,
I have provided a candidate patch to resolve trac ticket #5549
(http://dev.laptop.org/ticket/5549): In rotated mode, game keys retain
original orientation. Please refer to the ticket for more details.
I have additionally attached the patch to this email.
-Erik
From ac3a34a911c3b11824981f9202a53cff6465f227 Mon Sep 17 00:00:00 2001
From: Erik Garrison [EMAIL PROTECTED]
Date: Wed, 28 May 2008 20:41:19 -0400
Subject: Modified sugar.view.keyhandler.handle_rotate() to rotate d-pad keys in concert with rotation of the display. Because of its explicit use of keycodes from an MP machine, this patch may be MP-specific.
---
src/view/keyhandler.py | 31 ---
1 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/src/view/keyhandler.py b/src/view/keyhandler.py
index 306bb21..2a2d539 100644
--- a/src/view/keyhandler.py
+++ b/src/view/keyhandler.py
@@ -186,14 +186,39 @@ class KeyHandler(object):
def handle_frame(self):
view.Shell.get_instance().get_frame().notify_key_press()
+
def handle_rotate(self):
+
+Handles rotation of the display (using xrandr) and of the d-pad.
+
+Notes: default mappings for keypad on MP
+KP_Up 80
+KP_Right 85
+KP_Down 88
+KP_Left 83
+
+
states = [ 'normal', 'left', 'inverted', 'right']
+keycodes = (80, 85, 88, 83, 80, 85, 88, 83)
+keysyms = (KP_Up, KP_Right, KP_Down, KP_Left)
self._screen_rotation += 1
-if self._screen_rotation == len(states):
-self._screen_rotation = 0
+self._screen_rotation %= 4
+
+actual_keycodes = keycodes[self._screen_rotation:self._screen_rotation+4]
+code_pairs = zip(actual_keycodes, keysyms)
+argv = ['xmodmap']
+for arg in [('-e', 'keycode %i = %s' % p) for p in code_pairs]:
+argv.extend(arg)
+
+ try:
+subprocess.check_call(argv)
+subprocess.check_call(['xrandr', '-o', states[self._screen_rotation]])
+except OSError, e:
+import errno
+if e.errno != errno.EINTR:
+raise
-subprocess.Popen(['xrandr', '-o', states[self._screen_rotation]])
def handle_quit_emulator(self):
if os.environ.has_key('SUGAR_EMULATOR_PID'):
--
1.5.4.3
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
