Re: [Sugar-devel] [PATCH] add clock to frame

2009-05-03 Thread Sascha Silbe

On Sat, May 02, 2009 at 05:39:21PM +0100, Martin Dengler wrote:

[Clock behaviour in suspend]

But I take your point...the answer is: no, it's not easy (with my
simple patch).  I'm not sure what the behavior should be (hide on
idle?!, come out of suspend once a minute?!), really.
With the XO going into suspend automatically, it should at least 
indicate that the clock has stopped as well (and no, the pulsing power 
LED is not enough). Showing an old time is _much_ worse than not showing 
it at all.


CU Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/

signature.asc
Description: Digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Removing the 'Erase' options from activity righ click menu

2009-05-03 Thread Tomeu Vizoso
[adding sugar-devel to cc]

On Sun, May 3, 2009 at 11:32,  nout...@paiwastoon.com.af wrote:
 Greetings all,

 I am new to the whole OLPC thing so please bear with me. We are using the
 standard build to install XOs and then use shell scripts for the
 localization and to make small changes.

 I need to remove the 'Erase' option from the right click menu (when you
 right click on an activity icon). Is there anyway that this can be done
 without modifying the sugar source code and creating a new build?

Hi Basir,

I don't see a way to remove the palette option without changing the
Sugar code, but if you change the file permissions so that the user
'olpc' cannot remove the activity directory, the erasing operation
will fail and the activity will remain installed. Note that this will
cause activity updates to fail, in case that's an issue for you.

sudo chown root.root -R ~/Activities/Write.activity

This command will make that Write is not erasable from the Sugar palette.

Please note that the most appropriate forum to direct these questions
is sugar-devel: http://lists.sugarlabs.org/listinfo/sugar-devel .

HTH,

Tomeu

 Thanks
 Basir

 ___
 Devel mailing list
 de...@lists.laptop.org
 http://lists.laptop.org/listinfo/devel

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH] add clock to frame

2009-05-03 Thread pgf
sascha wrote:
  On Sat, May 02, 2009 at 05:39:21PM +0100, Martin Dengler wrote:
  
  [Clock behaviour in suspend]
   But I take your point...the answer is: no, it's not easy (with my
   simple patch).  I'm not sure what the behavior should be (hide on
   idle?!, come out of suspend once a minute?!), really.
  With the XO going into suspend automatically, it should at least 
  indicate that the clock has stopped as well (and no, the pulsing power 
  LED is not enough). Showing an old time is _much_ worse than not showing 
  it at all.

given martin's point about the battery level, wireless strength,
etc, all becoming stale as well, perhaps the best fix would be to
always hide the frame during idle suspend.  as far as i know,
however, there's currently no mechanism for apps to learn that
idle suspend is imminent.

paul
=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Removing the 'Erase' options from activity righ click menu

2009-05-03 Thread Raúl Gutiérrez Segalés
This is a recurrent problem. Perhaps we should have an option in the
control panel to enable/disable the showing of the Erase option for
activities or make moving the Erase option a few more clicks away (perhaps
inside the control panel, the activity updater widget/code might be
reusable).

Basir: is your motivation based on establishing a policy of having some
activities not erased or because users accidentally remove activities
every once in a while (as we have experienced frequently in our deployment
in Paraguay) ?




On Dom, 3 de Mayo de 2009, 6:01 am, Tomeu Vizoso wrote:
 [adding sugar-devel to cc]

 On Sun, May 3, 2009 at 11:32,  nout...@paiwastoon.com.af wrote:
 Greetings all,

 I am new to the whole OLPC thing so please bear with me. We are using
 the
 standard build to install XOs and then use shell scripts for the
 localization and to make small changes.

 I need to remove the 'Erase' option from the right click menu (when you
 right click on an activity icon). Is there anyway that this can be done
 without modifying the sugar source code and creating a new build?

 Hi Basir,

 I don't see a way to remove the palette option without changing the
 Sugar code, but if you change the file permissions so that the user
 'olpc' cannot remove the activity directory, the erasing operation
 will fail and the activity will remain installed. Note that this will
 cause activity updates to fail, in case that's an issue for you.

 sudo chown root.root -R ~/Activities/Write.activity

 This command will make that Write is not erasable from the Sugar palette.

 Please note that the most appropriate forum to direct these questions
 is sugar-devel: http://lists.sugarlabs.org/listinfo/sugar-devel .

 HTH,

 Tomeu

 Thanks
 Basir

 ___
 Devel mailing list
 de...@lists.laptop.org
 http://lists.laptop.org/listinfo/devel

 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel



---
Raúl Gutiérrez Segalés
  +595 981 231 839

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


[Sugar-devel] The User experience/interface for Printing

2009-05-03 Thread Vamsi Krishna Davuluri
hello,

So, talking to Tomeu, we agreed that for Write and Read using the gtkprint
would be best as both support it as a printing API.

Now, the current plan is:
1) We do journal printing only, albeit, the respective activity opens the
file.

Now here a cross road is presented:

1) Do we use a print dialog inside each activity that can save it as pdf,
print or export a pdf to moodle

2) Do we use separate buttons for each of these operations?

What of the user experience?

The initial plan was to make Read the global printing station, how do you
find this idea?
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH] add clock to frame

2009-05-03 Thread Jameson Quinn
Well, if the frame always auto-hid after 10 seconds, and the delay for
idle-suspend was 15 seconds, then it would work. I personally believe that
the frame should be hidden more agressively - whenever there's a user action
that doesn't address it, and after a longish timeout around 10 seconds. In
my experience with kids, hitting the frame key and then trying to interact
with the activity and being unable to is one of the more common hangups.

(I'm afraid I don't understand the latest on suspend, but it's my
understanding that there are some kind of micro-suspend periods which are
separate from longer-term idle suspend.)

Jameson

2009/5/3 p...@laptop.org

 sascha wrote:
   On Sat, May 02, 2009 at 05:39:21PM +0100, Martin Dengler wrote:
  
   [Clock behaviour in suspend]
But I take your point...the answer is: no, it's not easy (with my
simple patch).  I'm not sure what the behavior should be (hide on
idle?!, come out of suspend once a minute?!), really.
   With the XO going into suspend automatically, it should at least
   indicate that the clock has stopped as well (and no, the pulsing power
   LED is not enough). Showing an old time is _much_ worse than not showing
   it at all.

 given martin's point about the battery level, wireless strength,
 etc, all becoming stale as well, perhaps the best fix would be to
 always hide the frame during idle suspend.  as far as i know,
 however, there's currently no mechanism for apps to learn that
 idle suspend is imminent.

 paul
 =-
  paul fox, p...@laptop.org
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] The User experience/interface for Printing

2009-05-03 Thread Vamsi Krishna Davuluri
The usecases would be as following:

The user, John, creates a document and saves it to his journal one fine day.
The next day john transfers that journal item to his friend's XO the next
day.
His friend, Kennedy, has his XO set up in a moodle environment.  Kennedy
when in school decides to send that file (which is an ODF ) to the teacher
for review and get it printed there. Kennedy then double clicks on the item,
which results in Write opening the file, and selects the print button in the
print toolbar, a dialog pops up (which is understandably similar to gtkprint
dialog), he selects the print destination as moodle, and selects no of pages
as 'all', after sending. (ofcourse there is an internal conversion to PDF
happening, which gtkprint is doing) the teacher checks his print page in
moodle, views the file (either through fancy javascript or a download) and
approves/disapproves for printing. Kennedy then logs into his moodle print
page and checks if the job was success or not, and if he has a comment from
his teacher. But we already know John's doc was excellent. Kennedy goes to
collect the printed document, which he hands over to John the evening.

Use cases to note:
1) transferred docs can be printed
2) A nice graphical dialog that takes care of it all
3) exports only PDFs to moodle
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH] add clock to frame

2009-05-03 Thread pgf
jameson wrote:
  Well, if the frame always auto-hid after 10 seconds, and the delay for
  idle-suspend was 15 seconds, then it would work. I personally believe that
  the frame should be hidden more agressively - whenever there's a user action
  that doesn't address it, and after a longish timeout around 10 seconds. In
  my experience with kids, hitting the frame key and then trying to interact
  with the activity and being unable to is one of the more common hangups.
  
  (I'm afraid I don't understand the latest on suspend, but it's my
  understanding that there are some kind of micro-suspend periods which are
  separate from longer-term idle suspend.)

that's the plan of record, but there's no current implementation.

(and currently the idle suspend timeout is much longer than 15 seconds --
more like 1 or 2 minutes.)

paul

  
  Jameson
  
  2009/5/3 p...@laptop.org
  
   sascha wrote:
 On Sat, May 02, 2009 at 05:39:21PM +0100, Martin Dengler wrote:

 [Clock behaviour in suspend]
  But I take your point...the answer is: no, it's not easy (with my
  simple patch).  I'm not sure what the behavior should be (hide on
  idle?!, come out of suspend once a minute?!), really.
 With the XO going into suspend automatically, it should at least
 indicate that the clock has stopped as well (and no, the pulsing power
 LED is not enough). Showing an old time is _much_ worse than not showing
 it at all.
  
   given martin's point about the battery level, wireless strength,
   etc, all becoming stale as well, perhaps the best fix would be to
   always hide the frame during idle suspend.  as far as i know,
   however, there's currently no mechanism for apps to learn that
   idle suspend is imminent.
  
   paul
   =-
paul fox, p...@laptop.org
   ___
   Sugar-devel mailing list
   Sugar-devel@lists.sugarlabs.org
   http://lists.sugarlabs.org/listinfo/sugar-devel
  

=-
 paul fox, p...@laptop.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Removing the 'Erase' options from activity righ click menu

2009-05-03 Thread Gary C Martin
On 3 May 2009, at 13:59, Raúl Gutiérrez Segalés wrote:

 This is a recurrent problem. Perhaps we should have an option in the
 control panel to enable/disable the showing of the Erase option for
 activities or make moving the Erase option a few more clicks away  
 (perhaps
 inside the control panel, the activity updater widget/code might be
 reusable).

For what it's worth; there has been some Sugar 0.86 design talk about  
moving activity management out of the favourites home view and into  
the Journal with a goal of having all activities installed  and  
available there as bundles for Journal management (and potentially for  
modification and even versioning). The home list view may keep some  
management features, but I doubt it's a good place, as there are  
reports that home list view is too similar to a Journal view and  
activity bundles are being erased accidently there as well.

Regards,
--Gary

 Basir: is your motivation based on establishing a policy of having  
 some
 activities not erased or because users accidentally remove activities
 every once in a while (as we have experienced frequently in our  
 deployment
 in Paraguay) ?




 On Dom, 3 de Mayo de 2009, 6:01 am, Tomeu Vizoso wrote:
 [adding sugar-devel to cc]

 On Sun, May 3, 2009 at 11:32,  nout...@paiwastoon.com.af wrote:
 Greetings all,

 I am new to the whole OLPC thing so please bear with me. We are  
 using
 the
 standard build to install XOs and then use shell scripts for the
 localization and to make small changes.

 I need to remove the 'Erase' option from the right click menu  
 (when you
 right click on an activity icon). Is there anyway that this can be  
 done
 without modifying the sugar source code and creating a new build?

 Hi Basir,

 I don't see a way to remove the palette option without changing the
 Sugar code, but if you change the file permissions so that the user
 'olpc' cannot remove the activity directory, the erasing operation
 will fail and the activity will remain installed. Note that this will
 cause activity updates to fail, in case that's an issue for you.

 sudo chown root.root -R ~/Activities/Write.activity

 This command will make that Write is not erasable from the Sugar  
 palette.

 Please note that the most appropriate forum to direct these questions
 is sugar-devel: http://lists.sugarlabs.org/listinfo/sugar-devel .

 HTH,

 Tomeu

 Thanks
 Basir

 ___
 Devel mailing list
 de...@lists.laptop.org
 http://lists.laptop.org/listinfo/devel

 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel



 ---
 Raúl Gutiérrez Segalés
  +595 981 231 839

 ___
 Devel mailing list
 de...@lists.laptop.org
 http://lists.laptop.org/listinfo/devel

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] The User experience/interface for Printing

2009-05-03 Thread Vamsi Krishna Davuluri
== Use cases ==

1.- John has written an essay in Write about sharks and would like to print
it right now on a printer plugged via USB to his computer.
John does this by hitting the print button in write, and selecting 'usb
printing' as destination in the dialog which pops up. He then selects print
in the dialog. John also leaves the default number of pages as 'all' while
he does this.

2.- John\'s teacher asks the class to deliver their essays in PDF format.
John and his friends open their respective files with the default mime type
activity, hit the print button, and select 'export to moodle' as
destination. The option of course is visible only if John and his friends
aren't using all three of their slots.

3.- John\'s teacher liked his essay and would like to have it printed and
exposed in the classroom. The only available printer in the school is
attached to the school server.
The teacher hits approve in the moodle teacher page over john's assignment.
It is sent for printing, and John recieves back an acknowledgement in his
user page


== Non-functional requirements ==

Printing resources can be very expensive for most schools, so the system
should include a way for students to submit jobs to a queue and for an
administrator to preview and approve or denie them.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


[Sugar-devel] New Activity: ShareTerm-1

2009-05-03 Thread Benjamin M. Schwartz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This e-mail is to announce a new Sugar Activity: ShareTerm.  ShareTerm is
a variant of Terminal designed to enable collaborative work at the command
prompt.

How To Use It:
1. Install the bundle from:
http://dev.laptop.org/~bemasc/ShareTerm-1.xo
2. Install GNU Screen on your system.  MANDATORY.  NOTE: GNU Screen is not
installed by default on many Sugar systems, including OLPC's XO distributions.
3. Make sure you are running with Rainbow enabled!
4. Start ShareTerm from the Sugar UI, and then share it like any
collaborative Activity

How It Works:
ShareTerm works by starting an unprivileged SSH daemon and a GNU Screen
session.  The SSH daemon is tunneled over a Telepathy Stream Tube.  To
avoid the need for passwords, public-key authentication is used.  The
system should support an arbitrary number of participants, though at the
moment the sshd is configured with a maximum of 10.

Why Use It:
I hope that ShareTerm will be useful for teaching UNIX and programming
skills to novices.  For experts, the window management of Screen will be
especially useful.

How To Help:
ShareTerm needs:
Testing!
A better icon?
A better name?
Advice on using Sugarlabs infrastructure!
 - for translations and code
Help with programming!

Warnings:
ShareTerm allows other users to type at your command prompt.  ShareTerm
will never have an arbitrary code execution exploit, because that is a
feature (indeed, the only feature).  Therefore, you should always run
ShareTerm appropriately compartmentalized from your sensitive data.  If
the Rainbow security system is operating, ShareTerm will operate entirely
inside a Rainbow container, providing a significant degree of security.

ShareTerm requires GNU Screen.  A future bundle for ShareTerm could
include a statically linked Screen binary, but for now you must install
screen yourself (e.g. yum install screen) in order for the system to function.

Known Bugs:
ShareTerm is using sshd and screen far outside of their normal operating
parameters, so the system is quite fragile.   Only minimal effort has been
made to handle failure cases gracefully. Although the system appears to be
operating properly, and free of races, the internals are hack after hack
after hack.  I am not very knowledgeable about sshd, screen, sockets, or
related issues, so all assistance is welcome.

The only known bug at this time is that closing a ShareTerm session leaves
behind a unkillable zombie process.  I have no idea why.

- --Ben

P.S. ShareTerm:MPXVNC[1]::Adventure[2]::DOOM

[1] http://blog.printf.net/articles/2009/01/26/multi-pointer-remote-desktop
[2] http://en.wikipedia.org/wiki/Adventure_(computer_game)

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)

iEYEARECAAYFAkn95LoACgkQUJT6e6HFtqST5QCeLnR1REuFiUT2V8dxKdW6gFDI
qxoAnit+ch9qTpVibKLh8GSiNYSrOe0S
=YFP1
-END PGP SIGNATURE-
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [IAEP] The User experience/interface for Printing

2009-05-03 Thread Albert Cahalan
Vamsi Krishna Davuluri writes:

 So, talking to Tomeu, we agreed that for Write and Read using
 the gtkprint would be best as both support it as a printing API.

The focus on Write and Read is short sighted and may lead
to inflexible solutions.

 Now, the current plan is:
 1) We do journal printing only, albeit, the respective
 activity opens the file.

Eh, OK. Provide a script called /usr/bin/lpr which runs ps2pdf
or directly runs gs. This lets normal software, which is already
designed to output standard Postscript to lpr, work just fine.
After conversion, put the PDF into the journal.

Better yet, just toss the file into the journal without conversion.

BTW, this can also be implemented as a filter script that the
normal lpr program invokes for the default printer.

 Now here a cross road is presented:

 1) Do we use a print dialog inside each activity that can save it as pdf,
 print or export a pdf to moodle

 2) Do we use separate buttons for each of these operations?

 What of the user experience?

Separate buttons provides a distinction that will be important
in some environments. Some places will want immediate printing.

For now, the print button can be almost the same as the other,
but with the output PDF marked for near-term deletion.

Make PDF and Print now seem like fine names.

 The initial plan was to make Read the global printing station,
 how do you find this idea?

Starting up Read just to print something is not nice. Read may
even cause an out-of-memory condition. For sure, there is no need
to very slowly render a big document that doesn't even need to be
seen on the screen.

 the teacher checks his print page in moodle, views the file (either
 through fancy javascript or a download) and approves/disapproves
 for printing. Kennedy then logs into his moodle print page and
 checks if the job was success or not, and if he has a comment from
 his teacher.

I can barely imagine that happening in a real classroom. Try this:

The student brings his XO to the teacher's desk, with his work shown
on the screen. The teacher looks at the work, then lets the student
plug his XO into a printer which sits on the teacher's desk.

 Printing resources can be very expensive for most schools, so
 the system should include a way for students to submit jobs to a
 queue and for an administrator to preview and approve or denie them.

Tux Paint can rate limit a student's printing. For example, a setting
of 60 will be once per minute.

Do not forget that this issue is more social than technical. In addition
to any discipline, the teacher can simply turn off the printer. This is
advisable in any case; many printers use excessive power in standby.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


[Sugar-devel] Sugar Digest 2009-05-03

2009-05-03 Thread Walter Bender
===Sugar Digest===

I encourage you to join two threads on the Education List this week:
http://lists.sugarlabs.org/archive/iaep/2009-April/005382.html, which
has boiled down to an instruction vs construction debate; and
http://lists.sugarlabs.org/archive/iaep/2009-April/005342.html, which
has boiled down to a debate of catering to local culture vs the
Enlightenment. I encourage you to join these discussions.

Rather than commenting here, I want to discuss a third, orthogonal
topic: creativity. I hosted a visit to Cambridge this week from Diego
Uribe, a Chilean researcher who is currently a Fulbright scholar at
the International Center for Studies in Creativity in Buffalo, NY.
Diego challenged me with two questions: Can we be more deliberate in
developing children's creativity skills and how can we use Sugar to
better disseminate creativity heuristics?

Diego is of the believe that creativity is a skill that can be taught;
there has been more than 50 years of research into how to teach this
skill; and yet creativity is rarely a deliberate part of mainstream
education.

Diego introduced me to Grace Hopper's formula for creativity that I
had not previously encountered: The probability of creativity is a
function of knowledge, innovation, and experience, modulated by
attitude. (Historical footnote: Hopper is the one who coined the term
debugging when her colleagues found a moth stuck in a relay of the
Mark II computer.) In this formulation, attitude is often the weak
link.

Central to his own vision of teaching creativity as a skill is the
ability to strike the proper balance between divergent and convergent
thinking.

Guidelines for divergent thinking

* defer judgment
* go for quantity
* make connections
* seek novelty


Guidelines for convergent thinking

* apply affirmative judgment
* keep novelty alive
* check your objectives
* stay focused


(I was reminded of David Reed's analogy to water and ice: innovation
occurs in its liquid phase; consolidation in its solid phase.)

Diego was preaching to the choir. When I was director of the Media
Lab, I never told the students or faculty what to work on—their ideas
were always much better than mine—but I did insist on a creative
(learning) process that I described in a paper, The seven secrets of
the Media Lab.

blockquote
The phases of the moon represent the cyclical process of innovation at
the Media Lab. In the 1980s we used to describe the first phase of the
innovation cycle as ‘demo or die’. John Maeda rephrased our mantra in
the late 1990s to be ‘imagine and realize’. Indeed, it is a violation
of our cultural norm to have an idea and not build a prototype — in
large part because of our deeply-held belief that we learn through
expressing. Building a prototype also enables us to advance to the
second phase of the innovation cycle — critique. The Lab, which has
its origins in architecture (the founder of the Media Lab, Nicholas
Negroponte, is an architect) draws upon the tradition of studio design
critique; we have daily visits from our industry partners and other
practitioners with whom we engage in an authentic critical dialogue
about the work. In this exchange, the work is discussed within a
broader context — ideas (and prototypes) are exchanged, improvements
and alternatives suggested. We then advance to the third phase of the
innovation cycle — iterate. Iteration within the Lab means returning
to ‘Step One’ to push our ideas further. Iteration within our
partners’ organizations means taking a prototype towards real-world
application. In both cases, we can learn from our mistakes (and
successes).
/blockquote

Another secret is fire:

blockquote
Fire fuels the Media Lab. We invest in the passion of people, not
their projects. It is the fire that burns in every student and faculty
member that inspires and motivates them — love is a better master than
duty. Innovation at the Lab comes from the bottom up. It is not
regulated by a top-down process, but by continuous feedback from
peers, the faculty, and our external collaborators.
/blockquote

These principles proved affective at MIT in establishing a learning
community that is both collaborative and critical. These same
principles were an influence on the design of Sugar; however, we can
probably do more to embody them directly into Sugar itself.

Diego and I spent the next two hours exploring how we might make the
creative process more explicit in Sugar. He suggested that we consider
two common, approachable heuristics in our deliberations—SCAMPER and
PPCo.

SCAMPER is a technique developed by Alex Osborn, described in his book
Applied Imagination. SCAMPER is an acronym for substitute, combine,
adapt, modify, put to another use, eliminate, reverse. It is used for
encouraging divergent thinking.

PPCo is also an acronym: positives, potentials, concerns, overcoming
concerns. It was developed by Roger Firestien and Diane
Foucar-Szocki; it is used for convergent thinking.

What follows is a brief summary of our 

Re: [Sugar-devel] [PATCH] add clock to frame

2009-05-03 Thread Martin Dengler
On Sun, May 03, 2009 at 09:01:14AM -0400, p...@laptop.org wrote:
 sascha wrote:
   On Sat, May 02, 2009 at 05:39:21PM +0100, Martin Dengler wrote:
   
   [Clock behaviour in suspend]
But I take your point...the answer is: no, it's not easy (with my
simple patch).  I'm not sure what the behavior should be (hide on
idle?!, come out of suspend once a minute?!), really.
   With the XO going into suspend automatically, it should at least 
   indicate that the clock has stopped as well (and no, the pulsing power 
   LED is not enough). Showing an old time is _much_ worse than not showing 
   it at all.
 
 given martin's point about the battery level, wireless strength,
 etc, all becoming stale as well, perhaps the best fix would be to
 always hide the frame during idle suspend.  as far as i know,
 however, there's currently no mechanism for apps to learn that
 idle suspend is imminent.

Given this, and the fact that frame icons don't get any useful
gtk.gdk.{VISIBILITY,EXPOSE} events more than once per Sugar session
(unless one changes VTs away and then back), don't expect an
acceptable clock (redraws when the frame is exposed and only then,
hides before power blanking) anytime soon.

If we want a clock before then, we're going to have to accept
something less than perfect.

 paul

Martin


pgpQ9zuJCu0ld.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


[Sugar-devel] [KARMA] don't need an ide for js

2009-05-03 Thread Bryan Berry
subzero,

i am pretty darn blown away by how useful firebug is

check out this tutorial 
http://www.evotech.net/blog/2007/06/introduction-to-firebug/

and the intro pages here:
http://www.getfirebug.com

i don't see myself using aptana or another special ide. firebug + emacs
are a perfect fit.

-- 
Bryan W. Berry
Technology Director
OLE Nepal, http://www.olenepal.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH] add clock to frame

2009-05-03 Thread Martin Dengler
On Mon, May 04, 2009 at 12:17:05AM +0100, Martin Dengler wrote:
 On Sun, May 03, 2009 at 09:01:14AM -0400, p...@laptop.org wrote:
  given martin's point about the battery level, wireless strength,
  etc, all becoming stale as well, perhaps the best fix would be to
  always hide the frame during idle suspend.  as far as i know,
  however, there's currently no mechanism for apps to learn that
  idle suspend is imminent.
 
 Given this, and the fact that frame icons don't get any useful
 gtk.gdk.{VISIBILITY,EXPOSE} events more than once per Sugar session
 (unless one changes VTs away and then back), don't expect an
 acceptable clock (redraws when the frame is exposed and only then,
 hides before power blanking) anytime soon.

Getting rid of the compositing manager that I forgot I was
running solves the expose event problem.

Anybody have any great ideas about how to solve the problem of what to
do just before power management dims/blanks the screen, and how we
would want to be notified of that?  I'm not so sure we want to hide
the frame (but if we do, great, no more issues for the clock :)).

  paul
 
 Martin

Martin


 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel



pgpJvPJBlelZi.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH] add clock to frame

2009-05-03 Thread Martin Dengler
On Sat, May 02, 2009 at 05:36:12PM +0100, Martin Dengler wrote:
 On Sat, May 02, 2009 at 10:49:05AM -0400, Eben Eliason wrote:
  I think Sugar should only officially support a clock in the devices
  tray.
 
 What FRAME_RELATIVE_POSITION would you like it in?

  [clock should be HH:MM with additional information in the palette]
 
 Sure
 
  I'd also recommend putting the text against a filled background
 
 Will do.

I took a stab at these. Here is a screenshot of the clock, and the
code:

http://www.martindengler.com/tmp/clock_screenshot_04.png
http://www.martindengler.com/tmp/clock.py

Martin


pgpMgxuE2oE57.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH] add clock to frame

2009-05-03 Thread Benjamin M. Schwartz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin Dengler wrote:
 Anybody have any great ideas about how to solve the problem of what to
 do just before power management dims/blanks the screen, and how we
 would want to be notified of that?

IMHO, effort is best spent moving the suspend support into the kernel
(cpuidle) where it belongs.  That way, if the clock is visible, the
machine will wake up once a minute to update it.

Anything else is just hacks on top of hacks.

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkn+Zr8ACgkQUJT6e6HFtqTLPgCeMXNehSJjLWUSb94Ns60austV
49kAn1UUx1cOtXsU2IkAL+9F/Lz1cpXU
=9la1
-END PGP SIGNATURE-
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Removing the 'Erase' options from activity righ click menu

2009-05-03 Thread Benjamin M. Schwartz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

nout...@paiwastoon.com.af wrote:
 After
 our first deployment here in Afghanistan, we had to reinstall a lot of
 laptops because students accidentally deleted most of their activities.

I think this is a great example of why we need to make a no-regressions
XO-1 build with 0.84.  Among its many new features, 0.84 adds direct file
transfer capability, which means that if you delete an activity, you can
easily have a friend send it to you over the network.

It is abundantly clear that OLPC is not going to do this work for us.

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkn+blsACgkQUJT6e6HFtqRWDQCfQP3J5gyNA8KXg3ea2wTb0Ll9
4sQAniO2WPqjD6s3UpyB23h/g0RyHQZQ
=1OXc
-END PGP SIGNATURE-
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH] add clock to frame

2009-05-03 Thread Jameson Quinn

 Anything else is just hacks on top of hacks.


I disagree. Personally, I think auto-hiding the frame after a delay is a
clean solution that's desirable anyway. But I do agree that the decision of
whether to hide the frame or not should not be based on stopped clocks.

Jameson
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [KARMA] don't need an ide for js

2009-05-03 Thread Felipe López Toledo
Hi Bryan

i don't see myself using aptana or another special ide. firebug + emacs
are a perfect fit.
yes, you're right!

my early reason to use aptana was fast coding through the html assistant,
highlight and auto completion tool. one of the *good* things of aptana is
the inclusion (choose) of the javascript library (dojo, jquery, mootols,
etc)..
but, I felt like slow using it..

I just ended using gedit / kate + firebug

here is another tool like firebug (venkman from mozilla)
http://www.mozilla.org/projects/venkman/

currently reading about it at
http://www.mozilla.org/projects/venkman/venkman-walkthrough.html




2009/5/3 Bryan Berry br...@olenepal.org

 subzero,

 i am pretty darn blown away by how useful firebug is

 check out this tutorial
 http://www.evotech.net/blog/2007/06/introduction-to-firebug/

 and the intro pages here:
 http://www.getfirebug.com

 i don't see myself using aptana or another special ide. firebug + emacs
 are a perfect fit.

 --
 Bryan W. Berry
 Technology Director
 OLE Nepal, http://www.olenepal.org


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [IAEP] The User experience/interface for Printing

2009-05-03 Thread Andrés Ambrois
On Sunday 03 May 2009 06:29:26 pm Albert Cahalan wrote:
 Vamsi Krishna Davuluri writes:
  So, talking to Tomeu, we agreed that for Write and Read using
  the gtkprint would be best as both support it as a printing API.

 The focus on Write and Read is short sighted and may lead
 to inflexible solutions.

Read was selected to contain the send to print code because Tomeu expressed 
some concerns about the maintainability of that code in the Journal. Also, we 
agreed that going through read is good for reviewing the pdf output and saving 
paper on badly formatted docs. 

  Now, the current plan is:
  1) We do journal printing only, albeit, the respective
  activity opens the file.

 Eh, OK. Provide a script called /usr/bin/lpr which runs ps2pdf
 or directly runs gs. This lets normal software, which is already
 designed to output standard Postscript to lpr, work just fine.
 After conversion, put the PDF into the journal.

 Better yet, just toss the file into the journal without conversion.

 BTW, this can also be implemented as a filter script that the
 normal lpr program invokes for the default printer.

The priority is on sending the docs to cups-pdf for conversion and then 
talking to Moodle for teacher review. It is a good idea to have the code that 
sends docs for printing (to Moodle, a local printer, or one discovered by 
avahi) in a reusable module that a /usr/bin/lpr script can use. 

  Now here a cross road is presented:
 
  1) Do we use a print dialog inside each activity that can save it as pdf,
  print or export a pdf to moodle

If we are going to keep everything inside Read for now. It'll be best to have 
the print button only in Read. The use case we had discussed was like this: 
open the file in Read, if its not ps/pdf Read converts it using cups-pdf, 
displays it, and then you can use the print button in its toolbar. 

The converted file gets added as a journal entry right after conversion. The 
datastore already contains code to hard link identical files, so disk space 
usage in multiple conversions is kept to a minimum. Read could add a pointer 
to the pdf in the original entry's metadata as well. 

Adding a print dialog to every activity (e.g. Adding some gtkprint support in 
sugar-toolkit) should be optional for GSoC. First we should concentrate on 
getting entries printed, and getting teacher review right. Then we can move 
code around for legacy support and nice print me buttons. 

  2) Do we use separate buttons for each of these operations?
 
  What of the user experience?

 Separate buttons provides a distinction that will be important
 in some environments. Some places will want immediate printing.

 For now, the print button can be almost the same as the other,
 but with the output PDF marked for near-term deletion.

 Make PDF and Print now seem like fine names.


I agree. Just a print button for now. The PDF will be generated on startup 
anyway. We can have the cups-pdf local printer in the printer selection dialog 
when we provide other printing methods. 

  The initial plan was to make Read the global printing station,
  how do you find this idea?

 Starting up Read just to print something is not nice. Read may
 even cause an out-of-memory condition. For sure, there is no need
 to very slowly render a big document that doesn't even need to be
 seen on the screen.

This is to encourage review and to keep the code away from the Journal. The 
code can then be moved to Glucose. Also, distributing a modified Read for 
testing will be considerably easier than patching the Journal. 

  the teacher checks his print page in moodle, views the file (either
  through fancy javascript or a download) and approves/disapproves
  for printing. Kennedy then logs into his moodle print page and
  checks if the job was success or not, and if he has a comment from
  his teacher.

 I can barely imagine that happening in a real classroom. Try this:

 The student brings his XO to the teacher's desk, with his work shown
 on the screen. The teacher looks at the work, then lets the student
 plug his XO into a printer which sits on the teacher's desk.

  Printing resources can be very expensive for most schools, so
  the system should include a way for students to submit jobs to a
  queue and for an administrator to preview and approve or denie them.

 Tux Paint can rate limit a student's printing. For example, a setting
 of 60 will be once per minute.

 Do not forget that this issue is more social than technical. In addition
 to any discipline, the teacher can simply turn off the printer. This is
 advisable in any case; many printers use excessive power in standby.

I dont see a teacher having a printer on her desk. Most schools here in 
Uruguay (and I dare say in Perú) don't even have printers. If there is one, it 
will be where the server/administration is. And possibly locked in a cage 
(like we have the servers now). So that scenario is going to be priority one. 

Next will be of course provide local