Re: [Sugar-devel] [PATCH] add clock to frame
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
[adding sugar-devel to cc] On Sun, May 3, 2009 at 11:32, 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
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
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, 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
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
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 > 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
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
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 > > > 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
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, 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
== 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
-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
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
===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". 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). Another secret is fire: 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. 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 using a small sampling of the SC
Re: [Sugar-devel] [PATCH] add clock to frame
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
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
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
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
-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
-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
> > 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
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 > 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
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 serve
