Re: [sugar] Finding cursors. Ripples in a puddle?

2008-11-25 Thread Erik Garrison
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]

2008-10-31 Thread Erik Garrison
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] pie menus

2008-10-30 Thread Erik Garrison
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] Data Storage and User-facing System Requirements [was Re: 9.1 Proposal: Files]

2008-10-30 Thread Erik Garrison
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 a

[sugar] 9.1 Proposal: Files

2008-10-27 Thread Erik Garrison
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

2008-10-26 Thread Erik Garrison
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


Re: [sugar] The XO laptop gets a Windows makeover

2008-10-26 Thread Erik Garrison
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


[sugar] 9.1 Proposal: Performance

2008-10-22 Thread Erik Garrison
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

2008-10-20 Thread Erik Garrison
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

2008-10-18 Thread Erik Garrison
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


[sugar] simple hacks to improve the performance of the Sugar UI

2008-10-17 Thread Erik Garrison
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


Re: [sugar] 9.1 Proposal: Legacy compatibility.

2008-10-17 Thread Erik Garrison
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] planning session for a technical conference for OLPC customers and community members

2008-10-16 Thread Erik Garrison
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] [olpc-office-announce] Audio from demo of Scott's next-gen journal ideas, noon, 10/15/2008

2008-10-15 Thread Erik Garrison
On Wed, Oct 15, 2008 at 04:34:01PM -0400, Brian Jordan wrote:
> http://dev.laptop.org/~bjordan/scottfs.mp3 (170 MB)
> http://dev.laptop.org/~bjordan/scottfs.ogg (127 MB)
> 
> http://brianio.com/cscotts-journal-remix-proposal/ (flash player of MP3 file)
> 
> Listen with headphones for the win -- was recorded with in-ear microphones.

Wow.  I gotta say, this is tremendously audible.

> On Wed, Oct 15, 2008 at 4:42 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote:
> > On Tue, Oct 14, 2008 at 11:09 PM, C. Scott Ananian <[EMAIL PROTECTED]> 
> > wrote:
> >> On Wed, Oct 8, 2008 at 2:41 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote:
> >>> I'll be giving a demo of some next-generation journal ideas (and code)
> >>> at noon Wednesday at OLPC's 1cc offices.  I'll make sure to have it
> >>> recorded, and you can expect it posted online shortly afterwards (for
> >>> all those not in the Cambridge area).
> >>>
> >>> A taste to whet your appetite:
> >>>  http://wiki.laptop.org/go/Experiments_with_unordered_paths
> >>>  
> >>> http://dev.laptop.org/git?p=users/cscott/journal2;a=blob_plain;f=research/cscott-journal-proposal.pdf;hb=HEAD
> >>>  http://dev.laptop.org/~cscott/journal-ss.png
> >>>  http://dev.laptop.org/~cscott/journal-ss-2.png
> >>>  http://dev.laptop.org/git/users/cscott/journal2
> >>>
> >>> When I spoke to the GNOME folks yesterday, my talk also touched on
> >>> "tag cd", olpcfs, comparison of desktop search engines, RSS,
> >>> OpenSearch, Ferraris, and application launch protocols.  No promises,
> >>> though.  I don't even promise to have slides.
> >>
> >> I can promise to talk about journal security & bitfrost and evil
> >> linker tricks now.
> >>
> >> I can't yet promise to talk about opensearch and
> >> stupidly-basic-collaboration-we-still-don't-have, but I'm hoping that
> >> a few more hours of hacking will yield sufficient demoware for that.
> >>
> >> I'm hoping to have slides, so that I can recycle them for a talk in
> >> Peru next week.
> >>
> >> Again: this talk is *tomorrow noon* at OLPC's offices, and shortly after 
> >> online.
> >
> > Look forward to the recording. Does your proposal include anything
> > about removable storage devices or that's something expected to live
> > completely outside?
> >
> > Thanks,
> >
> > Tomeu
> > ___
> > Devel mailing list
> > [EMAIL PROTECTED]
> > http://lists.laptop.org/listinfo/devel
> >
> ___
> office-announce mailing list
> [EMAIL PROTECTED]
> http://lists.laptop.org/listinfo/office-announce
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


Re: [sugar] 0.84/9.1 planning.

2008-10-14 Thread Erik Garrison
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] Window manager support for standard applications

2008-10-14 Thread Erik Garrison
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  wrote:
> > On Sun, Oct 12, 2008 at 4:11 AM, Marco Pesenti Gritti  > gmail.com>wrote:
> 
> >>> 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] Slowness (was Re: notes from the field - Mongolia)

2008-10-09 Thread Erik Garrison
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

2008-10-08 Thread Erik Garrison
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] notes from the field - Mongolia

2008-10-08 Thread Erik Garrison
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

2008-10-07 Thread Erik Garrison
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

2008-10-07 Thread Erik Garrison
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] Need guidance from a Pygtk guru

2008-10-07 Thread Erik Garrison
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] alt-tabbing to the Journal

2008-10-07 Thread Erik Garrison
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] alt-tabbing to the Journal

2008-10-07 Thread Erik Garrison
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] notes from the field - Mongolia

2008-10-06 Thread Erik Garrison
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)

2008-09-29 Thread Erik Garrison
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] alt-tabbing to the Journal

2008-09-25 Thread Erik Garrison
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


Re: [sugar] alt-tabbing to the Journal

2008-09-25 Thread Erik Garrison
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] composite memory usage [was Re: frame auto-visibility configuration]

2008-09-25 Thread Erik Garrison
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] Supporting desktop applications, extending the EWMH spec

2008-09-24 Thread Erik Garrison
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


[sugar] alt-tabbing to the Journal

2008-09-24 Thread Erik Garrison
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] composite memory usage [was Re: frame auto-visibility configuration]

2008-09-24 Thread Erik Garrison
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] composite memory usage [was Re: frame auto-visibility configuration]

2008-09-24 Thread Erik Garrison
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  
> 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] frame auto-visibility configuration

2008-09-24 Thread Erik Garrison
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


Re: [sugar] frame auto-visibility configuration

2008-09-24 Thread Erik Garrison
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

2008-09-24 Thread Erik Garrison
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

2008-09-24 Thread Erik Garrison
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


[sugar] frame auto-visibility configuration

2008-09-24 Thread Erik Garrison
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] Tagged Journal Proposal

2008-09-23 Thread Erik Garrison
On Tue, Sep 23, 2008 at 02:05:55PM -0400, C. Scott Ananian wrote:
> A hand-drawn proposal for what a Journal supporting "directory
> traversal" as well as tag space exploration is in the attached PDF.
> Discussion welcome!
> 

I am unable to view this PDF.  It appears blank on this end.  Would you
provide a PNG?

Erik
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


Re: [sugar] frame gets in the way when alt-tabbing

2008-09-23 Thread Erik Garrison
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] frame gets in the way when alt-tabbing

2008-09-23 Thread Erik Garrison
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] Supporting desktop applications, extending the EWMH spec

2008-09-23 Thread Erik Garrison
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

2008-09-23 Thread Erik Garrison
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

2008-09-22 Thread Erik Garrison
On Mon, Sep 15, 2008 at 12:59:52AM -0400, Mikus Grinbergs wrote:
> 760.  Running (on my XO) a ported Linux application which puts up 
> multiple screens.  As far as I could tell. I was able to access all 
> of those screens by using the alt-tab procedure.  But while doing 
> this the Frame was unacceptably intrusive.  For instance, I could 
> not see the titles on the top line, which identified each screen.
> 
> If I rapidly pressed alt-tab and released -- the XO would not bother 
> to switch screens.  If I slowly pressed alt, then tab - the XO would 
> bring up the Frame.  I would need to release and press tab another 
> time to get the XO to switch to the next screen (while still showing 
> the Frame).  I would need to release alt to get the XO to stop 
> overlaying the screen edges with the Frame.  [And it seemed to me 
> that sometimes the Frame would not go away even then - I would have 
> to press and release the Frame key to ensure that it was gone for good.]
> 
> 
> 
> One of the first things I did upon getting my G1G1 was to go into 
> one of the .py files and __NOOP__ the "autoraising" of the Frame. 
> That gave me Sugar screen behavior that was under *my* control.
> 
> Now, Sugar has again started to interfere with what I am doing --
> by raising the Frame when I alt-tab.  I HATE THAT!  I HATE THAT!
> I thought the idea was to have the human in control of the computer, 
> instead of the computer dictating what the human may see.
> 
> I would like the Frame function in the Control Panel to allow me to 
> optionally disable the automatic showing of the Frame upon alt-tab. 
>   [Let *me* decide when I want to see the Frame !]
> 
> In the meantime, I guess I will have to go back to modifying the .py 
> files in Sugar - to reclaim Sugar screen behavior that does not 
> interfere with my use of the computer.
> 

I think the idea is to use the frame to show you which windows you can
alt+tab between, such as is done in Gnome or other WMs.  This is, in my
opinion, quite useful.  However, I am unsure of the utility of clumsily
animating the transition of the frame into view, or the lack of
configurability of this option.

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?

Erik
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


Re: [sugar] Supporting desktop applications, extending the EWMH spec

2008-09-22 Thread Erik Garrison
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
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


Re: [sugar] [PATCH] screenshots hurt

2008-09-12 Thread Erik Garrison
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] screenshots hurt

2008-09-12 Thread Erik Garrison
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, g

Re: [sugar] [PATCH] REVISED screenshots hurt

2008-09-11 Thread Erik Garrison
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] [PATCH] REVISED screenshots hurt

2008-09-11 Thread Erik Garrison
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

2008-09-10 Thread Erik Garrison
On Tue, Sep 09, 2008 at 12:10:41PM +0200, Tomeu Vizoso wrote:
> On Mon, Sep 8, 2008 at 3:44 PM, Eben Eliason <[EMAIL PROTECTED]> wrote:
> >
> > Should we verify that the activity is the active one, and that the
> > desktop is not shown, before taking an invalid screenshot?  Also, when
> > is compositing potentially coming?  Is it necessary to do this for
> > 8.2.1 if we'll have a far better solution which handles all cases in a
> > release or two?
> 
> We have a chance of improving screenshot taking without composition,
> see https://dev.laptop.org/ticket/8303 .

I'm slightly confused about what distinguishes this approach.  You are
moving the screenshot processing to the server side, correct?  If you
have time please clarify.

Have you tested the change on an XO running a 8.2 release candidate?

Erik
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


Re: [sugar] Activity testing on current 8.2 build 759

2008-09-08 Thread Erik Garrison
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] Keep error

2008-09-08 Thread Erik Garrison
On Mon, Sep 08, 2008 at 09:30:40AM +0200, Marco Pesenti Gritti wrote:
> On Sun, Sep 7, 2008 at 7:50 PM, Arjun Sarwal <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > When is a Keep error typically generated by Sugar ?
> 
> When saving to the datastore is, for some reason, going wrong. Do you
> have logs of your activity when this happens?

I have encountered this issue running the Peru activities on joyride
2263.  I couldn't tell if the issue was my 'no-screenshots' patch (which
I was testing) or the system/activity mismatch which is implied by my
setu.  I need to get back to a decent internet connection so I can use
the activity updater and sync everything up.

Erik
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


Re: [sugar] [PATCH] screenshots hurt

2008-09-05 Thread Erik Garrison
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

2008-09-05 Thread Erik Garrison
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] REVISED v.2 screenshots hurt

2008-09-05 Thread Erik Garrison
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

2008-09-05 Thread Erik Garrison
On Fri, Sep 05, 2008 at 11:28:17AM -0400, C. Scott Ananian wrote:
> In informal discussions here at 1cc w/ Chris and Michael, they seemed
> very pro- anything-which-makes 8.2 significantly faster.  I think the
> general antagonistic tenor of the thread here so far has made it hard
> to see what quick fixes we could do to improve performance without
> throwing away journal previews.

I desire to antagonize only so far as is necessary to push this issue to
conclusion.  I am trying to be extremely clear and explicit in my
discussion and questions, but I understand that this may appear negative
and request the understanding of those reading the thread.  My
apologies.

> Here's what *I* would like to see (speaking only for myself):
> 
> * Quantitative measurements.  "Switching performance is down to x ms
> rather than x ms".  This helps us discuss alternatives rationally
> without resorting to "sugar performance *sucks* unless we do X"
> mudslinging.
> 

I think that Riccardo has scripts which could help.  (Riccardo: Could
you please provide a pointer?)

> * Thorough testing.  It is possible to launch an activity and close it
> without a screenshot ever being taken.  What happens in that case?
> Does the journal crash?  Does sugar crash?  We need to have confidence
> the effects of suppressing screenshots are small.
> 

Testing is needed.  I lack resources (time) to do so here (or generally
on my own) and am explicitly requesting help in this via this thread.

> * More moderate solutions.  We're currently taking a lot of
> screenshots.  Can we quantify what the benefits of taking "fewer"
> screenshots without making this into an all-or-nothing discussion?
> What if we took a screenshot when the keep button was pressed, when
> the activity closed *while it was mapped* (there are ways to close
> unmapped activities*, and (say) on window switch and in the background
> but no more frequently than every N minutes.  I bet we can find a
> compromise which removes a lot of the unnecessary screenshots w/o
> removing them completely.
> 

Please note that this is exactly what the revised patch does.

Also note that previously we weren't taking screenshots on 'keep' (only
on close); rather the activity.py code expected there to be a steady
stream of screenshots available.  If the user worked solely within one
activity (never navigating away and triggering screenshots) this would
result in a journal entry without a screenshot--- a bug.

> * Unbiased investigation of other alternatives: are we convinced it is
> not possible to make the screenshot-taking code faster?  Would
> rewriting that code be a lower-risk path to equivalent performance
> improvement?  (Quantitative measurements help here, too.)

I fully support such work.  Please note that my intention with the
current patch is to remove said functionality until it can be well
tested and its effects on user interaction better understood.

> * A UI-centric evaluation.  What if we (say) only took screenshots
> when the user pressed the 'keep' button, and otherwise used the
> activity icon. This is a strawman, because the activity icon is, I
> believe, already present in the 'details' view in the journal, so this
> would add no information.  But maybe someone can think of a lower-cost
> generic preview mechanism, or a simple way for *some* activities to
> improve their performance by providing an "preview data" callback
> which sugar could use in lieu of a screenshot.

See above discussion, and patches at http://dev.laptop.org/~erik/sugar/,
which take screenshots on keep.
 
> From the strawpoll I took, people around the office here are excited
> about the opportunity to improve sugar performance, and willing to
> sneak it in even though it's really far too late in the 8.2 release
> cycle to be mucking about.  But the combative tone seems to have made
> it difficult for this thread to discover a solution acceptable to
> everyone.  (Not that I'm a master of tact myself!)

Great!

Please understand that I'm not trying to be combatative.  I desire more
design-motivational information and am asking very specific questions to
try to better understand the current design.

Erik
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


Re: [sugar] [PATCH] screenshots hurt

2008-09-05 Thread Erik Garrison
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 screenshots hurt

2008-09-04 Thread Erik Garrison
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


Re: [sugar] [PATCH] screenshots hurt

2008-09-04 Thread Erik Garrison
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] screenshots hurt

2008-09-04 Thread Erik Garrison
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


[sugar] [PATCH] screenshots hurt

2008-09-03 Thread Erik Garrison
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


[sugar] Attention! Activity authors: spanish title translations

2008-09-03 Thread Erik Garrison
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


Re: [sugar] [PATCH] Trac #7480: Need to 'reset' the network configurations - short term fix

2008-08-14 Thread Erik Garrison
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

2008-08-14 Thread Erik Garrison
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

2008-08-14 Thread Erik Garrison
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

2008-08-12 Thread Erik Garrison
On Tue, Aug 12, 2008 at 01:23:07PM -0400, C. Scott Ananian wrote:
> I moved discussion back to http://dev.laptop.org/ticket/7480 ,
> including citing Morgan's objections quoted above and proposing a
> solution.
> 
> Does anyone want to implement an email->trac gateway, like debian's
> bug tracker has?  That would help a lot when discussion veers off into
> email.
>  --scott

Thanks for moving it back to the ticket.

A nice gateway would work by filtering emails with some flag in their
subject line, e.g. [TRAC #7480].  Is this how debian's bug tracker does
implements the gateway UI?

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

2008-08-12 Thread Erik Garrison
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

2008-08-11 Thread Erik Garrison
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

2008-08-01 Thread Erik Garrison
On Fri, Aug 01, 2008 at 08:21:34PM +0200, Bastien wrote:
> Erik Garrison <[EMAIL PROTECTED]> writes:
> 
> > 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.  
> 
> What is the set of "core activities"?  how does this depend on a "given
> build"?  
> 

e.g., (for an old build): http://wiki.laptop.org/go/Category:Core

I mean 'core' in the sense that the core activities are those included
on a specific os image by default.  Users can install activities later.
These are not 'core'.

> Maybe what I'm suggesting boils down to integrate this core activities
> in the environment so that people installing Sugar won't have to install
> them separatly.  Just the same way that installing a standard Fedora
> will install Gnome (will install evolution (etc...)).
> 

What I'm suggesting is that this step requires global optimization wrt
which activities are 'core'.  This is difficult, as various deployments
have different usage patterns and require different sets of software.

I have often built debian systems using debootstrap to pull in the most
minimal typically used system components.  On top of such a system
customization is easy.  I am suggesting that we may wish to develop a
similar system so that our downstream developers can have more
flexibility in customizing their systems.  Activites could be Sugar-core
and not XO-system core.

Erik
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


Re: [sugar] specifying what services Activities may use

2008-07-31 Thread Erik Garrison
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

2008-07-24 Thread Erik Garrison
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

2008-07-19 Thread Erik Garrison
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] SMS messaging

2008-07-19 Thread Erik Garrison
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] Design Question

2008-07-19 Thread Erik Garrison
On Fri, Jul 18, 2008 at 04:53:31PM -0400, Greg Smith wrote:
> Hi All,
> 
> Can I get a quick +1/-1 on this question related to
> http://dev.laptop.org/ticket/7331
> 
> The new Home View in 8.2.0 will have three available styles. We need to 
> pick one to default on first upgrade or install.
> 
> Choices are:
> http://wiki.laptop.org/go/Image:Home_Freeform_View8.2.png
> http://wiki.laptop.org/go/Image:Home_Ring_View8.2.png
> http://wiki.laptop.org/go/Image:Home_List_View8.2.png

ring++
___
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)

2008-07-17 Thread Erik Garrison
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] Write needs your help (was Re: Programming environments on the XO)

2008-07-17 Thread Erik Garrison
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] Display warnings in sugar

2008-07-16 Thread Erik Garrison
This is a problem that all XOs face.

Ultimately we should produce a shared solution and push the fix into
Sugar.  I believe there has been some discussion of this?

The problem is getting that fix back out to deployed laptops may not be
easy...

My 2c.  Maybe the XO character in the home view could flash when
something this serious is wrong.

On Wed, Jul 16, 2008 at 04:53:00PM -0300, Emiliano Pastorino wrote:
> Hi, everyone!
> 
> I was wondering if is there a way to open a popup or something like that in
> sugar, we want to use that or something similar to give warnings to the
> user, like "95% of disk space used".
> 
> Thanks!
> 
> -- 
> Emiliano Pastorino
> LATU - Plan Ceibal
> Av. Italia 6201 CP: 11500, Montevideo, Uruguay
> Tel: (598 2) 601 3724 int.: 469

> ___
> Sugar mailing list
> Sugar@lists.laptop.org
> http://lists.laptop.org/listinfo/sugar

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


Re: [sugar] [PATCH] #447: grab/scroll key

2008-07-14 Thread Erik Garrison
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


Re: [sugar] [PATCH] #447: grab/scroll key

2008-07-13 Thread Erik Garrison
On Sun, Jul 13, 2008 at 11:19:46AM -0400, Eben Eliason wrote:
> On Sun, Jul 13, 2008 at 11:03 AM, Brian Jordan <[EMAIL PROTECTED]> wrote:
> > Brilliant work, Erik! I had a chance to play with your first working
> > hand scroll, and it's beyond explanation how fun it is to be able to
> > scroll around using the touchpad without aiming for a gtkScrollBar.
> 
> Great to hear!  I can't wait to give it a try myself...it's been a
> long time in coming.
> 

I'll give you a demo tomorrow.

> > For all to consider: there are two grab buttons. What if one tended to
> > grab + move *objects*, and the other grabs + moves
> > *scenes/backgrounds*? From what I've heard, kids tend to have a hard
> > time left-clicking and dragging with their same hand (as with the
> > touchpad). So, for applications like Browse, both grab buttons could
> > still just scroll up/down. But for graphical editors (e.g., layout
> > programs, Physics, Model, anything with a scene and objects), this UI
> > behavior may be a real time saver and fun to use. This would require
> > giving applications the ability to process events from these two
> > scroll buttons in a way that identifies them separately.
> 
> That's an interesting idea.  However, the reason there are two keys is
> so that interaction works well for both left- and right-handed users,
> without the need for them to cross their arms to scroll around.  What
> we might be able to do, though, is map an SHIFT-HAND shortcut to a
> drag/drop action instead. (I suggest shift because it's the only
> modified which is present on both sides of our keyboard, for the same
> reason as above.)
> 

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.

> To make that work well, I think we'll need to manage the display of
> the cursor appropriately.  perhaps we can use the
> horizontal/vertical/fleur arrows to indicate scrolling options, switch
> to the open hand when shift is pressed to indicate drag mode, and
> switch to a closed hand after a drag has been started.
> 

How is the cursor pixmap currently set?  Is there an existing function
in the sugar codebase to set the cursor pixmap?

Erik
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


[sugar] [PATCH] #447: grab/scroll key

2008-07-09 Thread Erik Garrison
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 = {
 'o'  : 'open_search',
 'r'  : 'rotate',
 's'  : '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):

Re: [sugar] Injecting Code into main Sugar GUI routine

2008-07-07 Thread Erik Garrison
On Sun, Jul 06, 2008 at 05:20:33PM -0500, Zach Riggle wrote:
> I am a student working on a Google Summer of Code project, sugarbot  
> (more information here: http://code.google.com/p/sugarbot/).  I am  
> currently at a stage where I need to be able to hook into the Sugar  
> GUI, to automate the process of launching Activities (e.g. simulate a  
> mouse-click on the activity list, scroll down, click on the Activity  
> name).  The process of automating the GUI is straightforward and  
> should not be a problem, however I do not know where the best location  
> would be to inject my code, or if there would be a way to create a  
> launcher that, in turn, launched the Sugar interface inside of its own  
> process.
> 
> Additionally, if anyone can point me in the direction of any materials  
> related to the Sugar startup procedures/process, it would be greatly  
> appreciated.

Zach,

I assume you will use the X windows XTest extension:
e.g. http://linux.die.net/man/3/xtestfakekeyevent
These functions can be used to completely simulate user input.

There are a variety of methods which could be used to initiate an xtest
test script.  One option which seems interesting is hooking the script
into a keypress chord such as 'F8'.  Then you could cleanly
initiate the test script in a given interface without having to add
significant features to the UI.  This can be done in
sugar/src/view/keyhandler.py.

First define a method on KeyHandler which launches your test script:

  def handle_test_script(self):
# ... here you can put the GUI in a known pre-test state
import subprocess
subprocess.Popen(['/path/to/script', 'arg1', 'arg2'])
# ... alternatively you could import the required XTest functions
# and run the script within this method

The function name should be prefixed with 'handle_'.

Now add an entry to the _actions_table:

  'F8'  :  'test_script',

When the KeyHandler object is instantiated, it grabs all the keypresses
in this table and registers a callback function for keypress and
kerelease events.  When hit, the keypress callback will call
KeyHandler.handle_value for whatever value is recorded in the
_actions_table (e.g. 'test_script').

This is very unsophisticated, but I hope it helps.

I am unsure of how you plan to verify the test without hooks throughout
the Sugar GUI and tested activities.  The most obvious first step is to
visually verify the progress of the test.  Any ideas?

Erik
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


[sugar] [EMAIL PROTECTED]: Re: the OLPC XO grab button (triggering mouse scrolling using a keypress)]

2008-07-02 Thread Erik Garrison
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?

2008-06-27 Thread Erik Garrison
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


Re: [sugar] [PATCH] to Browse activity; trac #6250

2008-06-11 Thread Erik Garrison
This test follows from my discussion with Chris Ball.

On 703:

1) Connect to an AP.
2) Run browse
3) Suspend the laptop (causing NM to go offline).
4) Un-suspend the laptop.
5) Note that the browser is now in offline mode, but there is no way to
access the menu to put it back in online mode.

Apply patch.  Note that offline mode no longer occurs.

Please tell me if this is not reproducible.

Erik


On Wed, Jun 11, 2008 at 01:33:47PM +0200, Simon Schampijer wrote:
> Hi Erik,
>
> thanks for the patch! Can you describe the steps involved to reproduce 
> what the patch is going to fix?
> For me these steps work without the patch applied:  
> http://dev.laptop.org/ticket/6250#comment:5 (accessing local files and 
> online mode when the link is present again)
> Not saying that the patch is not worth it just want to understand.
>
> And please follow the review guidelines  
> http://wiki.sugarlabs.org/go/DevelopmentTeam/CodeReview next time (not 
> push before the review).
>
> Thanks,
>Simon
>
> Erik Garrison wrote:
>> 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)
>>  
>>
>>
>> 
>>
>> ___
>> Sugar mailing list
>> Sugar@lists.laptop.org
>> http://lists.laptop.org/listinfo/sugar
>
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


[sugar] [PATCH] to Browse activity; trac #6250

2008-06-10 Thread Erik Garrison
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 ...)

2008-06-09 Thread Erik Garrison
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

2008-06-04 Thread Erik Garrison
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=1084&view=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

2008-06-03 Thread Erik Garrison
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

2008-06-03 Thread Erik Garrison
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


Re: [sugar] Capturing all mouse events

2008-05-31 Thread Erik Garrison
On Fri, May 30, 2008 at 10:47 PM, Erik Blankinship <[EMAIL PROTECTED]> wrote:
...

>
> This code might benefit from improvements.  Suggestions?
>

Comments and documentation please.  Here and in the rest of the Record source.



>   def resetWidgetFadeTimer( self ):
>   #only show the clutter when the mouse moves
>   self.mx = -1
>   self.my = -1
>
>   self.hideWidgetsTimer = time.time()
>   if (self.hiddenWidgets):
>   self.showWidgets()
>   self.hiddenWidgets = False
>
>   #remove, then add
>   self.doMouseListener( False )
>   if (self.HIDE_WIDGET_TIMEOUT_ID != 0):
>
>   gobject.source_remove( self.HIDE_WIDGET_TIMEOUT_ID )
>
>   self.HIDE_WIDGET_TIMEOUT_ID = gobject.timeout_add( 500,
> self._mouseMightaMovedCb )
>
>
>   def doMouseListener( self, listen ):
>   if (listen):
>   self.resetWidgetFadeTimer()
>
>   else:
>   if (self.HIDE_WIDGET_TIMEOUT_ID != None):
>   if (self.HIDE_WIDGET_TIMEOUT_ID != 0):
>   gobject.source_remove( 
> self.HIDE_WIDGET_TIMEOUT_ID )
>
>   def _mouseMightaMovedCb( self ):
>   x, y = self.ca.get_pointer()
>
>   passedTime = 0
>
>   if (x != self.mx or y != self.my):
>   self.hideWidgetsTimer = time.time()
>   if (self.hiddenWidgets):
>   self.showWidgets()
>   self.hiddenWidgets = False
>
>   else:
>   passedTime = time.time() - self.hideWidgetsTimer
>
>   if (self.ca.m.RECORDING):
>   self.hideWidgetsTimer = time.time()
>   passedTime = 0
>
>   if (passedTime >= 3):
>   if (not self.hiddenWidgets):
>
>   if (self.mouseInWidget(x,y)):
>   self.hideWidgetsTimer = time.time()
>   elif (self.RECD_INFO_ON):
>   self.hideWidgetsTimer = time.time()
>   elif (self.UPDATE_TIMER_ID != 0):
>   self.hideWidgetsTimer = time.time()
>
>   else:
>   self.hideWidgets()
>   self.hiddenWidgets = True
>
>   self.mx = x
>   self.my = y
>   return True
>
>
> On Fri, May 30, 2008 at 9:38 PM, Benjamin M. Schwartz
> <[EMAIL PROTECTED]> wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Does anyone know how to capture all mouse events?  I am trying to get all
>> mouse button up/down events, and maybe even all motion events.  I have
>> tried using gdk to listen to all events on the root window, but it doesn't
>> seem to capture mouse events.
>>
>> It seems like the right way might be to use Xlib, or to hook into the
>> window manager, or the X driver, or just listen to /dev/input/mouse0.  I
>> don't know much about any of these.  What would you do?
>>
>> - --Ben
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v2.0.9 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iEYEARECAAYFAkhArB8ACgkQUJT6e6HFtqSRSQCfatqMr9Ksdn204nEtaH89dV8r
>> kp8AnAxkPIq/bqnUJENnBze/GFMSgkXt
>> =IdMQ
>> -END PGP SIGNATURE-
>> ___
>> Sugar mailing list
>> Sugar@lists.laptop.org
>> http://lists.laptop.org/listinfo/sugar
>
>
> ___
> Sugar mailing list
> Sugar@lists.laptop.org
> http://lists.laptop.org/listinfo/sugar
>
>
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


[sugar] patch to sync display orientation and d-pad orientation

2008-05-28 Thread Erik Garrison
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