Re: [sugar] jumpy cursor problem and sugar issue
hey guys, thanks to all who have replied to my issue w/ the jumpy cursor. I haven't been able to test out the responses I have gotten because I have been sick in bed for the last couple days. Will reply once I am coherent enough to read the e-mails. On Mon, 2008-04-28 at 11:39 +0200, Bernie Innocenti wrote: > Tomeu Vizoso wrote: > > > We plan to work on this soon. The plan is to have a delay since the > > mouse enters in the corner and before the frame is brought up. This > > delay will be configurable with an slide in the control panel. > > That seems like a great idea to improve usability. > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Status of Sugar in Ubuntu 8.04
Hello, while some important activities are missing, Sugar can be installed and used in Ubuntu 8.04 out of the official Universe repositories. It is a very easy way of trying it out. The packages to install are sugar-emulator and sugar-activities. The latter is a metapackage depending on sugar-calculate-activity sugar-chat-activity sugar-connect-activity sugar-logviewer-activity sugar-memorize-activity sugar-pippy-activity sugar-terminal-activity sugar-turtleart-activity sugar-web-activity It can be started from the command prompt as sugar-emulator or from the application menu item of the same description. There's also a GDM login option for Sugar which will run it natively instead of in Xephyr. The latter option I have not tested as much as the emulator. Abiword 2.6 did not make it in Ubuntu 8.04 but if you add the Sugar repo for Hardy as described at https://launchpad.net/~sugar/+archive/ you can also install python-abiword and then sugar-write-activity, sugar-jigsawpuzzle-activity and sugar-sliderpuzzle-activity from Universe will work as well. Squeak in Ubuntu is not new enough and does not include the Etoys image so that activity is missing too. The read activity does not work either - hopefully the Sugar specific changes to Evince will be pushed upstream in this 2.23 GNOME cycle. Penguintv and TamTam are also notably missing, neither included license texts in the tarballs at the time of packaging, and that prevents uploading to Ubuntu - or any distro for that matter AFAIK. Paint and Record contain i386 specific shared objects so I wanted to take the time and see how those are best installed without breaking either Sugar's "one directory pe activity" or Debian's packaging policy. It looks like plenty of things are missing, but it's ok for getting started in learning or developing for Sugar and for interacting with other Sugar installations on the Internet. Jani ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] xomail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joshua N Pritikin wrote: | On Mon, Apr 28, 2008 at 07:39:13PM -0500, Dennis Gilmore wrote: |> On Monday 28 April 2008, Joshua N Pritikin wrote: |>> Do we really want to encourage HTML email? :-P |> We should add the option, but i would prefer plaintext as the default. | | I wasn't really serious about plain text email. I mean, do you want to | try to explain to a 7 year old why he shouldn't email a photo to a | friend? Supporting attachments (and rendering them appropriately) is entirely separate from automatically generating HTML for the body text. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIFpLrUJT6e6HFtqQRAgh2AJ9iecDSWeH9V8h/XH1lVdtZupvL3wCfb+kE wPSKMDJS5tbvmTcv31HpK+w= =n7+Z -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] xomail
On Mon, Apr 28, 2008 at 07:39:13PM -0500, Dennis Gilmore wrote: > On Monday 28 April 2008, Joshua N Pritikin wrote: > > Do we really want to encourage HTML email? :-P > > We should add the option, but i would prefer plaintext as the default. I wasn't really serious about plain text email. I mean, do you want to try to explain to a 7 year old why he shouldn't email a photo to a friend? I think a better angle on the problem is to be more aggressive about blocking email. Can we GPG sign email by default? ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] xomail
On Monday 28 April 2008, Joshua N Pritikin wrote: > On Tue, Apr 29, 2008 at 09:32:45AM +1000, Martin Edmund Sevior wrote: > > You can immediately reuse the AbiWidget from libabiword for > > your rich text HTML editor. libabiword has a very capable > > export content to HTML feature. You can copy and paste the > > relevant parts from the Write program to have the same > > interface as Write if you wish. > > Do we really want to encourage HTML email? :-P We should add the option, but i would prefer plaintext as the default. Dennis signature.asc Description: This is a digitally signed message part. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] xomail
Martin Edmund Sevior wrote: > > Hi Shikar, > You can immediately reuse the AbiWidget from libabiword for > your rich text HTML editor. libabiword has a very capable export > content to HTML feature. You can copy and paste the relevant parts > from the Write program to have the same interface as Write if you wish. > > Cheers > > Martin > That's great! It makes support for the feature feasible during the summer :-) Shikhar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] xomail
On Mon, Apr 28, 2008 at 04:39:23PM -0700, Joshua N Pritikin wrote: > Do we really want to encourage HTML email? +1 to plain text email. It seems one relevant concern is security. Wikipedia's page is pretty good background reading http://en.wikipedia.org/wiki/HTML_e-mail ...and one pro-HTML mail view: http://ukwebfocus.wordpress.com/2007/03/26/html-email-views-from-the-grizzled-techies-and-evil-marketeers/ Martin pgpjmVebNZsdG.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] xomail
On Tue, Apr 29, 2008 at 09:32:45AM +1000, Martin Edmund Sevior wrote: > You can immediately reuse the AbiWidget from libabiword for > your rich text HTML editor. libabiword has a very capable > export content to HTML feature. You can copy and paste the > relevant parts from the Write program to have the same > interface as Write if you wish. Do we really want to encourage HTML email? :-P ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add speaker device and icon by default
On Mon, Apr 28, 2008 at 06:12:31PM -0400, Michael Stone wrote:
> On Mon, Apr 28, 2008 at 10:26:21PM +0100, Martin Dengler wrote:
> > On Mon, Apr 28, 2008 at 01:08:04PM -0400, Michael Stone wrote:
> > > Can calls to self._mixer or self._master fail even when these attributes
> > > are not None?
> >
> > It doesn't appear a concern from the existing hardwaremanager.py code,
> > and not in practice: I've tested checking/changing the volume in a few
> > activities.
>
> I seem to recall having encountered situations where sugar startup would
> fail (in early versions of the QEMU image, before sound began working)
> as a result of unchecked use of sound hardware. I fixed the problem by
> commenting out volume control in the sugar shell. It was a particularly
> annoying problem because it was persistent, which meant that X entered
> an infinite reboot loop.
Yes, that problem exists and my patch is no worse in this respect - I
meant to make both points very explicit later in the email to which
you replied. Given the clear implication that we should do better,
I'll change my patch.
If you, or marco, or anyone has an opinion about where the best place
to introduce the real paranoia, please let me know. OTTOMH, given we
obviously want to make Sugar not crash and (secondarily) minimize
spamming of 'try:...except's, hardwaremanager.py's where I would
introduce the bulk of the changes (rather than make speaker.py,
randomactivity.py,
presence-palette-that-wants-to-make-a-dinging-noise.py, etc. do this).
If anyone thinks that's controversial let me know.
> > The original author of the hardwaremanager.py trusted the gst classes
> > just as much as I am... also keep in mind that I actually saw and
> > worked around two failures (#6933, #6934) of exactly these
> > attributes/implementations,
>
> In your opinion, did the original author of hardwaremanager.py (or
> authors of the clients of hardwaremanager.py?) exercise the degree of
> caution necessary to deliver a solid, reliable Sugar experience to our
> present audience? (I say "present" audience because I think that our
> audience has changed from one which consisted primarily of developers to
> one which consists primarily of semi-literate children.)
As a rhetorical question I think I understand the point. As a
non-rhetorical question, I'll decline to answer due to lack of
context/familiarity with the conditions.
> > > Also, what happens if an exception is thrown by, say, Device.__init__()?
> >
> > Given the current state of error checking, sugar (the shell) will fail
> > to start and matchbox will exit (I saw this during testing, and just
> > now tried 'raise Exception("we love m_stone")' to confirm.)
>
> Is the exception properly recorded?
I'm sorry, I will have to research the proper way to record such an
exception. I don't know.
> Is it possible (easy?) to send the traceback upstream to us?
Very interesting idea. Is there a plan for aggregating such data?
cscott's FISL presenation had some (http-sourced?) usage graphs...is
there a "Send Microsoft a Report"- (or "We Share Your Pain" :)) like
server to which our code could send such reports? Do you want
automated/staged trac submissions? The design/architecture/maintenance
solution space is well beyond my time to explore. Lacking any leads
therein I'm going to answer to your question as "I know not this
'upstream', would be happy to use one, but have no resources to build
one".
> > Device.__init__() is four lines of code, and depends on
> > util.unique_id() and gobject.GObject.__init__().
>
> Device.__init__() sounds like the sort of thing that I expect will be
> overridden by subclasses in interesting ways and it sounds like the sort
> of thing that will break when people try to run Sugar on platforms we
> haven't tested pre-qualified.
I think you're encouraging me to make Device.__init__() a bit safer,
or add some comments, or something similar, rather than changing
speaker.py's __init__(). It's going to get a bit hairy if we can't
trust our superclass(es)'s constructor(s). Or perhaps you'd have me
consider patching devices.py, to survive any of its devices' not
initializing.
If you / anyone has a preference for either approach, or how I
structure the changes into one or more patches (this is part of the
culture that I haven't picked up yet), please let me know.
Otherwise I will go forward with what you've said on the principle
that you/others would rather slap my code back/down than micromanage
me forward.
> > and no other similar bit of code... does any more checking than this.
>
> Is this good? In particular, is it good that an exception that bubbles
> up through Device.__init__() causes X to enter an infinite restart loop?
ibid.
> > And please excuse me if I've missed a howler of a bug that you're
> > socraticly/patiently trying to make me realize - just feel free to say
> > outright what sucks and I'll fix it!
>
> You seem to be telling me that Sugar will crash if any of its d
Re: [sugar] xomail
Hi Shikar, You can immediately reuse the AbiWidget from libabiword for your rich text HTML editor. libabiword has a very capable export content to HTML feature. You can copy and paste the relevant parts from the Write program to have the same interface as Write if you wish. Cheers Martin -Original Message- From: [EMAIL PROTECTED] on behalf of Shikhar Sent: Tue 4/29/2008 8:19 AM To: J.M. Maurer Cc: ValS; sugar@lists.laptop.org Subject: [sugar] xomail J.M. Maurer wrote: > On Mon, 2008-04-28 at 09:26 -0700, ValS wrote: > >> Thanks for this wonderful program! Speaking as an XO user, I am >> requesting a feature that I imagine would benefit any users that have >> internet access. I would like to be able to use the Write function, >> and then send what I have written in an email as an attachment. That >> way, I can send it to others, send it to a computer with a printer, >> and use the written material in various ways, even as a book. So is >> there a chance of compatibility between the Write (and other) >> functions and the Browse (where we can access email)? >> > > If there is any service on the XO that can send email, then this would > be trivial to add to Write. Isn't there a Google SoC application this > year to create an an email thing based on tinymail for the XO ? > > Marc > While not an accepted application, I will be working on an email client for the XO during June-August regardless. Support for attachments and mailto: URI's is planned. The wiki page http://wiki.laptop.org/go/Email_Activity details my ideas and I would appreciate any suggestions. Shikhar ___ 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] fix #6753 Activities should be able to specify "mime_types = */*"
On Mon, Apr 28, 2008 at 06:31:00PM -0400, Michael Stone wrote: > Well, what would happen if people installed lots of activities > supporting '*/*'? ... > * Would our Palettes scroll, or scale, or run off screen, or ...? I think the UI is probably going to lag behind gracefully handling this case, not in the least because I just blatted my patch out in 15 minutes without mentioning it to any UI people. I don't know of many activities that really need this feature. The first thing that comes to mind is that there is no way for an activity to request it be the top of the list given no other hints, which could be useful. The second thing that comes to mind is that on IRC, when discussed ages ago, IIRC, the list of activities that should be suggested was to be ordered most recently used first. > Please keep submitting patches. You're doing a good job. I'm just using > your work to try to provoke discussion about how well our designs cope > with corner cases. Perhaps this patch got more attention than it needed, given the questions you raised. Besides the one to which I responded, I don't know the answers. I suspect that now might not be the optimal time to answer them. I'm quite happy for this tiny patch to languish / be discarded - the advantage of such a small patch is that it costs little to generate / discard, but if it gets in it's cheap. > Michael Martin pgp4TWgSxHsTn.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Pen Tablet support and a usability study
On 13.04.2008, at 02:56, Patrick Dubroy wrote: > For the last couple months, I've been working on the higher-level > support for the XO Pen Tablet (for more information, see here: > http://wiki.laptop.org/go/Pen_Tablet_Support). > > If anyone's interested, I've got a couple of activities available > which will let you play with the tablet on an XO: > > - TabletAreaTest > (http://wiki.laptop.org/go/Pen_Tablet_Support/GTK_Widget#Sample_Activity > ) > demonstrates a GTK widget that is mapped to tablet input > - tabletui (http://wiki.laptop.org/go/Pen_Tablet_UI#Prototype) > explores some user interface prototypes for the unconstrained drawing > case (http://wiki.laptop.org/go/Pen_Tablet_UI#Unconstrained_drawing) > > These activities have been developed for build 656, meaning they don't > require any special driver support (other than /dev/input/event). > I'd love to see people give these a go and let me know what they > think. > > I also just completed a user study on some of my prototype user > interfaces. I've summarized the results here: > http://wiki.laptop.org/go/Pen_Tablet_UI/User_Study > > Feedback is welcome -- either directly, or on the appropriate Talk > page. I hope you got a lot more feedback privately than I saw on the list ... Anyway, I finally found time to try your TabletUI activity. Thank you very much for that! It works well to test out tablet usage. One problem I found when using your "dynamic" mapping mode is that I had intended the input window to stay fixed until the cursor is moved. That is, it should not be moved whenever you lower the pen, but only when the pen is not used but the finger moves the cursor somewhere else. Otherwise (as it is currently) it is rather awkward to use since the window jumps around like mad and each stroke starts at the same spot (where you left the cursor). Also, I think the cursor should be turned off while drawing with the pen - that is, while the pen window is showing. Moving the cursor by finger should show the cursor and hide the pen window. The other issue looks like a hardware/ec/driver one: I have to press *very* hard to even get tablet events. Using this as a writing pad is next to impossible. Also, I get a lot of erratic events, its jumping all over the place at times. Unless this can be fixed I have no great hopes for using the tablet as intended. Do you know the state of development in this area? - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] xomail
On Tue, 2008-04-29 at 00:19 +0200, Shikhar wrote: > J.M. Maurer wrote: > > On Mon, 2008-04-28 at 09:26 -0700, ValS wrote: > > > >> Thanks for this wonderful program! Speaking as an XO user, I am > >> requesting a feature that I imagine would benefit any users that have > >> internet access. I would like to be able to use the Write function, > >> and then send what I have written in an email as an attachment. That > >> way, I can send it to others, send it to a computer with a printer, > >> and use the written material in various ways, even as a book. So is > >> there a chance of compatibility between the Write (and other) > >> functions and the Browse (where we can access email)? > >> > > > > If there is any service on the XO that can send email, then this would > > be trivial to add to Write. Isn't there a Google SoC application this > > year to create an an email thing based on tinymail for the XO ? > > > > Marc > > > While not an accepted application, I will be working on an email client > for the XO during June-August regardless. Support for attachments and > mailto: URI's is planned. The wiki page > http://wiki.laptop.org/go/Email_Activity details my ideas and I would > appreciate any suggestions. Thanks, I'll keep an eye on it! :) Marc ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] fix #6753 Activities should be able to specify "mime_types = */*"
On Mon, Apr 28, 2008 at 10:32:48PM +0100, Martin Dengler wrote: > On Mon, Apr 28, 2008 at 01:11:47PM -0400, Michael Stone wrote: > > What sort of activity can handle */*? > > Distribute. The journal ;). Possibly others; I don't know. I'm not > really the best person to justify #6753. Distribute is an excellent example; thanks. > > Can you think of any nasty things that activities might be able to > > do by advertising suppport for '*/*'? > Besides social-engineering/tricking kids into sending their data to > someone maliciously? Well, what would happen if people installed lots of activities supporting '*/*'? * What happens if those are funky hidden activities like Read? * Would our Palettes scroll, or scale, or run off screen, or ...? * Would the Journal be okay if all entries can be opened by, say, ten activities? * Does the Journal/DS's "default activity for this mime-type" selection mechanism function correctly with "*/*", "*", "*/foo", "foo/*", etc. mimetypes? > [other comments] Please keep submitting patches. You're doing a good job. I'm just using your work to try to provoke discussion about how well our designs cope with corner cases. Best, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] xomail
J.M. Maurer wrote: > On Mon, 2008-04-28 at 09:26 -0700, ValS wrote: > >> Thanks for this wonderful program! Speaking as an XO user, I am >> requesting a feature that I imagine would benefit any users that have >> internet access. I would like to be able to use the Write function, >> and then send what I have written in an email as an attachment. That >> way, I can send it to others, send it to a computer with a printer, >> and use the written material in various ways, even as a book. So is >> there a chance of compatibility between the Write (and other) >> functions and the Browse (where we can access email)? >> > > If there is any service on the XO that can send email, then this would > be trivial to add to Write. Isn't there a Google SoC application this > year to create an an email thing based on tinymail for the XO ? > > Marc > While not an accepted application, I will be working on an email client for the XO during June-August regardless. Support for attachments and mailto: URI's is planned. The wiki page http://wiki.laptop.org/go/Email_Activity details my ideas and I would appreciate any suggestions. Shikhar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add speaker device and icon by default
On Mon, Apr 28, 2008 at 10:26:21PM +0100, Martin Dengler wrote:
> On Mon, Apr 28, 2008 at 01:08:04PM -0400, Michael Stone wrote:
> > Can calls to self._mixer or self._master fail even when these attributes
> > are not None?
>
> It doesn't appear a concern from the existing hardwaremanager.py code,
> and not in practice: I've tested checking/changing the volume in a few
> activities.
I seem to recall having encountered situations where sugar startup would
fail (in early versions of the QEMU image, before sound began working)
as a result of unchecked use of sound hardware. I fixed the problem by
commenting out volume control in the sugar shell. It was a particularly
annoying problem because it was persistent, which meant that X entered
an infinite reboot loop.
> The original author of the hardwaremanager.py trusted the gst classes
> just as much as I am... also keep in mind that I actually saw and
> worked around two failures (#6933, #6934) of exactly these
> attributes/implementations,
In your opinion, did the original author of hardwaremanager.py (or
authors of the clients of hardwaremanager.py?) exercise the degree of
caution necessary to deliver a solid, reliable Sugar experience to our
present audience? (I say "present" audience because I think that our
audience has changed from one which consisted primarily of developers to
one which consists primarily of semi-literate children.)
> > Also, what happens if an exception is thrown by, say, Device.__init__()?
>
> Given the current state of error checking, sugar (the shell) will fail
> to start and matchbox will exit (I saw this during testing, and just
> now tried 'raise Exception("we love m_stone")' to confirm.)
Is the exception properly recorded? Is it possible (easy?) to send the
traceback upstream to us?
> Device.__init__() is four lines of code, and depends on
> util.unique_id() and gobject.GObject.__init__().
Device.__init__() sounds like the sort of thing that I expect will be
overridden by subclasses in interesting ways and it sounds like the sort
of thing that will break when people try to run Sugar on platforms we
haven't tested pre-qualified.
> and no other similar bit of code... does any more checking than this.
Is this good? In particular, is it good that an exception that bubbles
up through Device.__init__() causes X to enter an infinite restart loop?
> And please excuse me if I've missed a howler of a bug that you're
> socraticly/patiently trying to make me realize - just feel free to say
> outright what sucks and I'll fix it!
You seem to be telling me that Sugar will crash if any of its device
abstractions fails to initialize. That seems like a howler of a bug to
me (though perhaps not one in your code). Is this desirable behavior? Is
it intentional?
Thanks for putting up me,
Michael
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
I'm neither a child nor a teacher, so this opinion is personal : What you want to avoid is having the user decide "my intent has been ignored", when in fact it is something "under the covers" that is delaying the completion of his intent. The best way I can think of to avoid the user making a wrong decision is to give him "feedback" whenever the XO enters a condition perceived as "as yet, nothing seems to be happening". You are probably asking about situations where responsiveness is expected in seconds (let educators determine how long a wait needs to be to cross the threshold into "too long"). What I believe is needed is showing "Yes, something *is* happening". Many operating systems use the cursor appearance to tell the user "working on it". [Eye candy might distract the user during unavoidable waits.] If confirmation takes "too long", the user might end up confused. For example, I restarted an Activity from the Journal (no longer remember which one); nothing seemed to be happening, so I used alt-tab to switch to an existing Activity; a while later, while I was viewing its screen, the XO suddenly transferred the display to showing the screen of the new Activity, which had finally started. [A change to supply an unmistakable confirmation of "Activity starting" has been described -- I wish it were available now.] Harder to endure are the situations where it can take minutes to do something. I am (and I expect others will be, as well) too impatient to sit still and wait for these to complete - I'll switch my attention to something else, and will need to be informed of what became of the thing I was waiting for. [For example, I believe that if connectivity to a server is lost -- recovery might be soon, but also it might take more than five minutes.] I believe there should be an ongoing indication (e.g., slow blinking of a front panel light) that unambiguously shows the user "I'm slowly working on this", with a specific how-it-concluded indication when this "working" activity ends (e.g., light goes off for "connection given up for good", or light goes steady for "connection properly established"). [Shutdown is an example of where I feel the XO is a "drag" - it takes me 40+ seconds. I don't know if "closing the lid" while the screen is still lit will cause problems, or if before packing up the XO I have to just sit and wait until the screen goes dark.] mikus (running G1G1, not emulator) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] fix #6753 Activities should be able to specify "mime_types = */*"
On Mon, Apr 28, 2008 at 01:11:47PM -0400, Michael Stone wrote: > What sort of activity can handle */*? Distribute. The journal ;). Possibly others; I don't know. I'm not really the best person to justify #6753. > Can you think of any nasty things that activities might be able to > do by advertising suppport for '*/*'? Besides social-engineering/tricking kids into sending their data to someone maliciously? I've nowhere near the familiarity as (IMHO) yourself and others have to the problem space, so don't pretend to be able to opine on this, and have no use case for it. Please definitely consider my patch as a straw man to delay/engender discussion rather than an educated attempt to solve a current problem. I figure as others might have a use case, and you/others have the experience with what works and what doesn't, I'd provide a possibly useful shortcut to the minimum # of lines of code that could be changed to satisfy the use case to save others/you that small amount of time. If it's an interesting problem to consider right now, given everything else that we could be talking about on sugar@ ;). > Michael pgpBcNMuSSTqb.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add speaker device and icon by default
On Mon, Apr 28, 2008 at 01:08:04PM -0400, Michael Stone wrote:
> Can calls to self._mixer or self._master fail even when these attributes
> are not None?
It doesn't appear a concern from the existing hardwaremanager.py code,
and not in practice: I've tested checking/changing the volume in a few
activities.
The original author of the hardwaremanager.py trusted the gst classes
just as much as I am, though I wouldn't want to hide behind that; if
you're concerned I haven't done enough research about these APIs (I
love abusing abstraction and limited documentation in a language
without checked exceptions to write code fast:)), well, that's
understandable (though I have done some research on GstElement[1,2],
GstState[3], and the anemic state of python-gst documentation (could
be a sign of great code :))[4,5] and I think it's OK enough for me).
Also keep in mind that I actually saw and worked around two failures
(#6933, #6934) of exactly these attributes/implementations, so if your
concern is that they'll DoS/make Sugar more fragile, I'm happy to add
a bit more paranoia to hardwaremanager.py - so far I just have the
existing code to guide me as to what level of paranoia is justified,
but as you're the one paid to be paranoid :) I of course would not
object to being corrected / directed differently.
Can you explain a bit more about your concern(s) so I can address them
better?
> Also, what happens if an exception is thrown by, say, Device.__init__()?
Given the current state of error checking, sugar (the shell) will fail
to start and matchbox will exit (I saw this during testing, and just
now tried 'raise Exception("we love m_stone")' to confirm.)
Device.__init__() is four lines of code, and depends on
util.unique_id() and gobject.GObject.__init__(). I'm no expert on
those two, but that seems trivial/robust enough to not wrap in a
try/except, and no other similar bit of code (battery.py,
network/*.py) that depends on Device.__init__() and has the same
exposure to its behavior does any more checking than this.
Again, can you explain a bit more about your concern(s) - e.g., would
you prefer a try/except in speaker.py, or device.py, or something
else? Or were you just curious as to the likelihood of
failure/complexity of Device.__init__()?
And please excuse me if I've missed a howler of a bug that you're
socraticly/patiently trying to make me realize - just feel free to say
outright what sucks and I'll fix it!
> Thanks,
>
> Michael
Martin
1.
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstElementFactory.html#gst-element-factory-make
2.
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstElement.html
3.
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstElement.html#GstState
4. The example for interacting with the mixer:
http://webcvs.freedesktop.org/gstreamer/gst-python/examples/mixer.py?revision=1.2&view=markup
. Of course it's an example and it's got about 4 PEP 008 style
violations that smacked me on the head, but the last commit is an
attempt to make it not grossly fail under some normal error condition
so it's at least a minimum bar of how to interact with the mixer,
which it seems hardwaremanager.py vaults easily, before and after my
patch :).
5. http://www.jonobacon.org/?p=750 <-- this is the author of
python-gst, it seems, complaining about the lack of documentation but
doing a really good job of starting to rectify the situation :)
pgpUOuaQUKeKt.pgp
Description: PGP signature
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] 15 computer science collegians looking for a project
Any interest in the themes/topics Tomeu outlined in his email about Sugar performance? Lots of interesting things to explore that would be of real value to the project. -walter On Mon, Apr 28, 2008 at 1:38 PM, Patrick Jahenr <[EMAIL PROTECTED]> wrote: > Hi there, > > We are a group of 15 collegians, studying 'Applied Computer Science' > at the University of Applied Sciences in Iserlohn (Germany) and we > are looking for a project for the OLPC within the scope of our subject > "Computer-Networks". Our professor (Prof. Martin Hühne) let us choose > our own topic, leading us directly to our first problem: What can > we do? > > We have to find a project fitting to this demand. We read the wiki > and realised, that most of our ideas we thought we could implement > are either finished software projects or simply not good enough to > keep on thinking about them, because they do not fit to the OLPC- > ideas. The wiki pages for Project ideas are nice, but you do not > know exactly whether there is already someone working on one of the > projects, or not. The Pages for Current Projects are quite nice too, > but there you do not know if the people working on it actually do > need help. > > That is why we post this little request to the readers of this mailing > list. > > We are looking for either a project we can take part on, or a not- > yet-implemented idea. It should not bee too big for us in order to > be finished within time; it should not be too small to have something > to do for 15 students. (Anyway, don't forget we need to sleep) > It would be nice, but not all necessary if the project could involve > some of the networking technologies of the XO, I mean, the subject > is "Computer-Networks" > > Furthermore, there is a time limit: We will have to end the project > until end of June, whereas there will be the same subject for another > group of students after our free period, which will have the same, > or a similar task. Probably, they will go on, on our project, if > its not finished. > > Our Knowledge Base: > We have good basic knowledge in C/C++, Java, some basic knowledge > in scripting languages (Perl, PHP and bash) and some of us have good > knowledge of Linux. A further subject called "Software-Engineering" > came along with us for one and a half year. > We started reading and working in Python and GTK, and saw, we can > cope that. > > We are open for all your suggestions, you can email me directly if > you have a project we can take part on, but you could also just answer > here, if you have a good idea which of the project ideas we could > implement. > > Thank you in advance, > > > Patrick > > > P.S. Please forgive me my English skills > > > > > > > > > ___ > 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] Sugar Digest, Vol 22, Issue 98
On Mon, 2008-04-28 at 09:26 -0700, ValS wrote: > Thanks for this wonderful program! Speaking as an XO user, I am > requesting a feature that I imagine would benefit any users that have > internet access. I would like to be able to use the Write function, > and then send what I have written in an email as an attachment. That > way, I can send it to others, send it to a computer with a printer, > and use the written material in various ways, even as a book. So is > there a chance of compatibility between the Write (and other) > functions and the Browse (where we can access email)? If there is any service on the XO that can send email, then this would be trivial to add to Write. Isn't there a Google SoC application this year to create an an email thing based on tinymail for the XO ? Marc ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] On improving Sugar performance
First, thanks Tomeu (and others involved), that's a fab list that may be coming down the pipe. I'd followed some of those items through joyride, but others were silent runners for me. Great to hear about them! On 28 Apr 2008, at 17:09, Tomeu Vizoso wrote: >> Anyone is of course welcome to join us with questions, answers and >> proposals. To keep the discussion relaxed, we do not require backing >> each and every idea with benchmark results, which in some cases are >> hard to obtain. Nevertheless, measuring is a useful tool, especially >> when there there's disagreement on how effective each solution >> might be. > > Sure, but rather than a useful tool, I would call measuring as the > only possible base on which decide actual work that needs to be done. > We could be refactoring and recoding for years and don't get any > noticeable improvement, if we don't measure. Not that I want to start a CS grad war here, but with more than one foot in the UI camp, I just wanted to request that more than just 'clock watching' is done when selecting/implementing optomisations – though 'clock watching' is a very good place to start. http://www.codinghorror.com/blog/archives/001058.html Catering for subjective human response is tricky, but once you've passed some minimum threshold for utility** you can often win more hearts and minds going for the subjective. A concrete example I'd point to is smooth animation; activity switching with no nasty redraw flicker; pulsing icons with no visible strobe; and frame/notification transitions that glide smoothly onto the display giving the illusion of effortlessness. **how many hours must I have spent as a kid, excitedly waiting for some software to load up off a magnetic tape, only to have it fail a fair portion of the time and have to start the tape over again... and some folks here moan about a ~6sec launch time for an activity. Though it's true to argue that those old machines did have instant on, even if you were left to ponder a BASIC prompt and spend the next 5min trying to tune your TV in to get a clear signal :-) - Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Adjust system activities path
And the actual patch... Marco On Mon, Apr 28, 2008 at 9:12 PM, Marco Pesenti Gritti <[EMAIL PROTECTED]> wrote: > The new paths are: > > '@prefix@/share/sugar/activities:' \ > '@prefix@/lib64/sugar/activities:' \ > '@prefix@/lib/sugar/activities' > > This provides an home for arch specific activities. Also using > "activities" for something sugar specific was a bad idea, so it's now > "sugar/activities". > > Marco > patch Description: Binary data ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] Adjust system activities path
The new paths are: '@prefix@/share/sugar/activities:' \ '@prefix@/lib64/sugar/activities:' \ '@prefix@/lib/sugar/activities' This provides an home for arch specific activities. Also using "activities" for something sugar specific was a bad idea, so it's now "sugar/activities". Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar\Windows won't ship
Incidentally, this whole topic of "getting Sugar to play nicely with Linux" was the *exact* topic of my talk at FISL this year. The slides can be downloaded from http://download.laptop.org/content/conf/20080417-fisl08/cscott/ ; I'm under impression that the actual video will be available at some point from http://fisl.softwarelivre.org/9.0/www/ but my Portuguese is not at a sufficient level for me to know if this has been done yet, and if not when it might be available. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] fix #6753 Activities should be able to specify "mime_types = */*"
What sort of activity can handle */*? Can you think of any nasty things that activities might be able to do by advertising suppport for '*/*'? Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add speaker device and icon by default
Can calls to self._mixer or self._master fail even when these attributes are not None? Also, what happens if an exception is thrown by, say, Device.__init__()? Thanks, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar Digest, Vol 22, Issue 98
Thanks for this wonderful program! Speaking as an XO user, I am requesting a feature that I imagine would benefit any users that have internet access. I would like to be able to use the Write function, and then send what I have written in an email as an attachment. That way, I can send it to others, send it to a computer with a printer, and use the written material in various ways, even as a book. So is there a chance of compatibility between the Write (and other) functions and the Browse (where we can access email)? Valerie Stansfield Los Angeles ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] On improving Sugar performance
On Mon, Apr 28, 2008 at 3:17 PM, Bernie Innocenti <[EMAIL PROTECTED]> wrote: > Hello, > > me, tomeu and Marco engaged in a discussion about Sugar performance > off-list, but at some point we thought it would be better material > for a public discussion. > > Each one of us has been interested in performance for a long time, > working in different areas and with different perspectives. To my > knowledge, Michael, Chris and Scott have also been measuring and > contributing in the past. > > We have of course different ideas and proposals, with Tomeu being > in a better position to give us hard numbers and informed opinions > because of the truly aggressive performance work he has been doing > lately. > > When we say generically "performance", we aggregate several > related issues: > > - time to perform specific actions (such as refreshing the screen) > - memory footprint of the Sugar shell and associated services > - overhead common to all activities (the "hello world" memory usage) > - memory footprint of specific activities (such as the browser) > - startup time of activities > - boot time of the OS > > To simplify the discussion, I'd like to set aside, for now these > other areas: > > - filesystem (datastore) performance and scalability > - networking performance and scalability > > I'd like to introduce our discussion in the form of a platonic > dialog with Tomeu: Fine ;) > - What have you been doing so far? - Profiled Shell startup. - Profiled Activity startup https://dev.laptop.org/ticket/5228 - Profiled Activity switching. - Profiled DataStore general performance and measured scalability. - Measured how often the UI elements were refreshed and how much time that took. > - What are the benefits you obtained so far? - J5 (if I remember well) took out some bottlenecks from activity and shell startup, long ago. - Python modules use to do early initialization, and as python activities are given support from the sugar API for several high-level functionality items (presence, UI, datastore, etc) lots of modules need to be initialized before nothing is drawn in the screen during activity launch. Using a python launcher process that reuses a pre-initialized python shell solved this and also brought considerable memory savings from page sharing between processes. In joyride builds now. - Experimented with redirecting the activity windows to an off-screen pixmap (using composition). This prevented many redraws and improved substantially UI feedback (activity switching, frame slide-in/out and palettes and menus popdown). There are some issues to solve yet before this can be considered deployable. This approach increases memory usage by 4MB per activity, but could be minimized to a total of 4MB with occasional 8MB peaks by using a smart composition manager. In 'faster' builds now. - The DataStore was brought to "good enough" performance and scalability by improving how metadata is stored and indexed. We can still improve considerably here without switching to a different full-text engine. - Much work was done in the Journal in order to cache data from the DS and make scrolling quick enough. The results are not yet satisfactory and a new UI design is planned that will make this issue much easier to solve. > - Which are the areas where we could gain the most? - Python activity startup in joyride is much faster, but still can be improved greatly. The next bottleneck is believed to be reading from the DS or creating the initial entry when launching. - Currently, all files that get into the filesystem are compressed on-the-fly by the jffs2 driver. This can result in a big amount of work being performed inside the kernel, slowing considerably other simultaneous operations (activity startup, switching and stopping, for example). I think that we have now support in the driver for honoring a flag for not doing this compression. Most files saved by activities are already compressed formats (png, odt, pdf, xo, etc) so don't benefit from this on-the-fly compression. We should start using it. > - Do you see low-hanging fruit we could pick in the short term? Don't know currently of other areas other than the ones described above. In my opinion, what we should do now is: - consolidate the benefits we have already implemented by testing, fixing any issues and putting into images that can be tested - get feedback about other parts of Sugar that need performance love - profile, measure, etc Having some kind of automated tests for detecting regressions would be very important, in my opinion. > - How much further can we improve by dropping specific unnecessary > or redundant work and similar pessimizations? Lots ;) That's the best path for the time being, and I'm confident we'll be able to get excellent performance just by doing that. > - How much further can we improve by refactoring subsystems and > APIs to do less work? I consider this the same as above, isn't it? > - How m
Re: [sugar] Sugar\Windows won't ship
On Mon, Apr 28, 2008 at 4:55 PM, Jim Gettys <[EMAIL PROTECTED]> wrote: > Note that this work (should be) the same, no matter what window manager > we end up using. Window managers have been pretty interchangeable > throughout X's history. That's what the ICCCM/EWMH's documents are all > about. If there is something missing we need, we can/should/will work > with the freedesktop mailing list to catch the oversights. As far as I know the current Sugar implementation should run decently under any ICCCM/EWMH compliant window manager, with just a couple of modifications. The main shell glitch I know about is the way we implement the frame panels (we couldn't do it the right because of matchbox limitations), but that should be really easy to fix, matter of using the right hint. And then there is obviously the fact that activities should be fullscreen. One way to fix that would be just to use the fullscreen hint for activities. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar\Windows won't ship
On Mon, Apr 28, 2008 at 4:55 PM, Jim Gettys <[EMAIL PROTECTED]> wrote: > I suspect we're using dbus in some places where we should just be using > the normal ICCCM/EWMH conventions. Activities/applications can run fine without DBus right now. The main problem are a couple of non standard X properties. It should not be too difficult to stop requiring those. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
We should be careful as we make this analysis that we don't overly bias the discussion towards the perception of developers rather than the children and teachers. Perhaps Carla can chime in based on her experiences in NIgeria, India, Peru, and Mexico. -walter On Mon, Apr 28, 2008 at 11:10 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > On Mon, Apr 28, 2008 at 3:58 PM, Mikus Grinbergs <[EMAIL PROTECTED]> wrote: > > One thing I observe is that it takes considerable time from when I > > click on 'Shutdown' in the Main view, until the XO actually stops. > > Thank you, I'd like to ask the people with actual machines to write to > this list with their opinions about which parts of the UI are worst > affected by slow performance. > > This particular issue about shutdown seems to me to be more related to > non-Sugar elements. > > Thanks, > > Tomeu > > > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
On Mon, Apr 28, 2008 at 3:58 PM, Mikus Grinbergs <[EMAIL PROTECTED]> wrote: > One thing I observe is that it takes considerable time from when I > click on 'Shutdown' in the Main view, until the XO actually stops. Thank you, I'd like to ask the people with actual machines to write to this list with their opinions about which parts of the UI are worst affected by slow performance. This particular issue about shutdown seems to me to be more related to non-Sugar elements. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar\Windows won't ship
On Mon, 2008-04-28 at 16:47 +0200, Marco Pesenti Gritti wrote: > On Mon, Apr 28, 2008 at 4:32 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > > If someone would like to go ahead and try replacing matchbox with > > metacity, would be great ;) > > And I'd be happy to help out whoever attempts it both on the Sugar and > on the wm/X side... :) Note that this work (should be) the same, no matter what window manager we end up using. Window managers have been pretty interchangeable throughout X's history. That's what the ICCCM/EWMH's documents are all about. If there is something missing we need, we can/should/will work with the freedesktop mailing list to catch the oversights. I suspect we're using dbus in some places where we should just be using the normal ICCCM/EWMH conventions. - Jim -- Jim Gettys One Laptop Per Child ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] perceived sugar performance
One thing I observe is that it takes considerable time from when I click on 'Shutdown' in the Main view, until the XO actually stops. Happened to see the Linux shutdown messages (Is there a way to ask for these instead of the "don't do these" screen?) and it seemed to several times attempt to do something with a .security directory (which I don't have) -- each time timing out. I believe that if accessing a missing .security directory were not repeated, considerable time would be saved in the duration of shutdown. mikus p.s. What my XO display shows me for a specific situation is not 100% consistent. An example is shutdown -- about 1 in 40 times, instead of the "don't do these" screen I've seen the Linux shutdown messages, or I've seen out-of-sync garbage. Likewise, about 1 in 30 times, when during booting the 'circle of dots' gets near 8 o'clock the screen goes a uniform dark gray, and stays that way until the Main view cursor shows. [I've seen other questionable display contents -- but the above ones occur frequently enough for me to remember.] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar\Windows won't ship
Note I understand that metacity can be configured to use a dbus/gconf version, rather than bringing in the dread CORBA/bonobo dependencies we've worked so hard to avoid. So don't let ldd mislead you that it isn't worth a try; it is. So Metacity is clearly one of the contenders. This wasn't an option when Sugar was started, though with 20-20 hindsight, we probably should have used something other than matchbox from the beginning. - Jim On Mon, 2008-04-28 at 16:32 +0200, Tomeu Vizoso wrote: > On Mon, Apr 28, 2008 at 4:25 PM, Jim Gettys <[EMAIL PROTECTED]> wrote: > > > > On Mon, 2008-04-28 at 10:06 -0400, Walter Bender wrote: > > > I must have missed the post you refer to. It has never been the > > > position of the core Sugar team--that I am aware of--to preclude the > > > running of standard Linux apps. We even went so far as to hire a > > > contractor to look at various ways to facilitate the running of > > > standard X apps last summer---although that work was never completed > > > or brought into the main branch. > > > > > > > Matthew Allum thinks we're best off not trying to force-fit this into > > matchbox (the window manager we're currently using), having done the > > experiment last summer. He's not only the "contractor", but also the > > original author of matchbox; so I think we should respect his opinion in > > this matter. > > > > We'll investigate alternative window managers, rather than flogging this > > horse, which is clearly dead for our purposes. Many of the modern ones > > honor full screen hints, and I've never seen Sugar's UI do much that > > isn't supported one way or the other by the ICCCM/EWMH's. It may take a > > bit of sugar work, but I'd be surprised it will be difficult. > > If someone would like to go ahead and try replacing matchbox with > metacity, would be great ;) > > Thanks, > > Tomeu -- Jim Gettys One Laptop Per Child ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar\Windows won't ship
On Mon, Apr 28, 2008 at 4:32 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > If someone would like to go ahead and try replacing matchbox with > metacity, would be great ;) And I'd be happy to help out whoever attempts it both on the Sugar and on the wm/X side... :) Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar\Windows won't ship
On Mon, Apr 28, 2008 at 4:25 PM, Jim Gettys <[EMAIL PROTECTED]> wrote: > > On Mon, 2008-04-28 at 10:06 -0400, Walter Bender wrote: > > I must have missed the post you refer to. It has never been the > > position of the core Sugar team--that I am aware of--to preclude the > > running of standard Linux apps. We even went so far as to hire a > > contractor to look at various ways to facilitate the running of > > standard X apps last summer---although that work was never completed > > or brought into the main branch. > > > > Matthew Allum thinks we're best off not trying to force-fit this into > matchbox (the window manager we're currently using), having done the > experiment last summer. He's not only the "contractor", but also the > original author of matchbox; so I think we should respect his opinion in > this matter. > > We'll investigate alternative window managers, rather than flogging this > horse, which is clearly dead for our purposes. Many of the modern ones > honor full screen hints, and I've never seen Sugar's UI do much that > isn't supported one way or the other by the ICCCM/EWMH's. It may take a > bit of sugar work, but I'd be surprised it will be difficult. If someone would like to go ahead and try replacing matchbox with metacity, would be great ;) Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar\Windows won't ship
On Mon, 2008-04-28 at 10:06 -0400, Walter Bender wrote: > I must have missed the post you refer to. It has never been the > position of the core Sugar team--that I am aware of--to preclude the > running of standard Linux apps. We even went so far as to hire a > contractor to look at various ways to facilitate the running of > standard X apps last summer---although that work was never completed > or brought into the main branch. > Matthew Allum thinks we're best off not trying to force-fit this into matchbox (the window manager we're currently using), having done the experiment last summer. He's not only the "contractor", but also the original author of matchbox; so I think we should respect his opinion in this matter. We'll investigate alternative window managers, rather than flogging this horse, which is clearly dead for our purposes. Many of the modern ones honor full screen hints, and I've never seen Sugar's UI do much that isn't supported one way or the other by the ICCCM/EWMH's. It may take a bit of sugar work, but I'd be surprised it will be difficult. - Jim -- Jim Gettys One Laptop Per Child ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar\Windows won't ship
I must have missed the post you refer to. It has never been the position of the core Sugar team--that I am aware of--to preclude the running of standard Linux apps. We even went so far as to hire a contractor to look at various ways to facilitate the running of standard X apps last summer---although that work was never completed or brought into the main branch. Albert, among others, has shown that in fact it is not difficult to wrap existing apps in a Sugar wrapper, but this is still one step away from where we'd like to be. (Last summer's proposal was to be able to switch back and forth to a non-Sugar desktop within the window manager. Indeed, the discussion about investigating ion or awesome as alternative window managers are in part intended to address this issue.) That said, as John points out, there are some other high-priority tasks, such as rewriting the Datastore--something Ivan had been working on before he left--and working on improved performance, as per Bernie's recent post. So, let's see if we can do a better job for standard Linux apps than Benjamin has recently done for Windows apps--you should try his Wine activity. (Note that he made some deliberate--and probably correct--trade-offs by deciding to minimize any integration with the Datastore, while keeping clipboard compatibility. -walter On Mon, Apr 28, 2008 at 1:39 AM, <[EMAIL PROTECTED]> wrote: > On Sat, 26 Apr 2008, Walter Bender wrote: > > > > > > > Sugar/Linux could easily have compatibility with regular Linux stuff, > > > but this has been denied despite strong demand. > > > > > > > Albert, saying that this has been "denied" is overstated. Was it a > > priority in the beginning? No. Were some decisions made that make it > > more difficult? Yes. But are people working towards this goal? Yes. > > > > I'll say that the impression that I have received as an outsider is that > the people working on Sugar have not at all been interested in compatibility > with normal linux software. > > in fact there was a post within the last week claiming that it would be a > bad idea to make sugar able to use unmodified linux software becouse that > would mean that the educational software and activities being written for > sugar could then be used on any linux box without sugar and this would mean > the death of sugar. a couple of us responded that if sugar requires that > sort of lock-in it deserved to die, but I don't remember anyone speaking up > to say that the developers of sugar or the software team at OLPC disagreed > with the initial poster. > > I know that in an ideal world you would not have to speak up to deny each > and every crazy statement that's made, but at this point there is so much > uncertinty about what the attitudes really are (not to mention the problem > of knowing who actually speaks with authority on many of these things) the > reality is that everything that's incorrect needs to be responded, if only > so others don't start quoting it incorrectly. > > David Lang > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] Add speaker device and icon by default
Add speaker device and icon by default, as in
http://wiki.laptop.org/go/Designs/Frame#07
---
src/hardware/hardwaremanager.py | 31 +-
src/model/devices/Makefile.am |4 +-
src/model/devices/devicesmodel.py |3 +
src/model/devices/speaker.py | 59 ++
src/view/devices/Makefile.am |4 +-
src/view/devices/speaker.py | 119 +
6 files changed, 215 insertions(+), 5 deletions(-)
create mode 100644 src/model/devices/speaker.py
create mode 100644 src/view/devices/speaker.py
diff --git a/src/hardware/hardwaremanager.py b/src/hardware/hardwaremanager.py
index 29be450..42676e4 100644
--- a/src/hardware/hardwaremanager.py
+++ b/src/hardware/hardwaremanager.py
@@ -50,6 +50,13 @@ class HardwareManager(object):
if track.flags & gst.interfaces.MIXER_TRACK_MASTER:
self._master = track
+def get_mute(self):
+if not self._mixer or not self._master:
+logging.error('Cannot get the mute status')
+return False
+return self._master.flags & gst.interfaces.MIXER_TRACK_MUTE \
+ == gst.interfaces.MIXER_TRACK_MUTE
+
def get_volume(self):
if not self._mixer or not self._master:
logging.error('Cannot get the volume')
@@ -57,9 +64,19 @@ class HardwareManager(object):
max_volume = self._master.max_volume
min_volume = self._master.min_volume
-volume = self._mixer.get_volume(self._master)[0]
-return volume * 100.0 / (max_volume - min_volume) + min_volume
+volumes = self._mixer.get_volume(self._master)
+
+#sometimes we get a spurious zero from one/more channel(s)
+#TODO: consider removing this when trac #6933 is resolved
+nonzero_volumes = [v for v in volumes if v > 0]
+
+if len(nonzero_volumes) > 0:
+#we could just pick the first nonzero volume, but this converges
+volume = sum(nonzero_volumes) / len(nonzero_volumes)
+return volume * 100.0 / (max_volume - min_volume) + min_volume
+else:
+return 0
def set_volume(self, volume):
if not self._mixer or not self._master:
@@ -76,7 +93,15 @@ class HardwareManager(object):
volume = volume * (max_volume - min_volume) / 100.0 + min_volume
volume_list = [ volume ] * self._master.num_channels
-self._mixer.set_volume(self._master, tuple(volume_list))
+#sometimes alsa sets one/more channels' volume to zero instead
+# of what we asked for, so try a few times
+#TODO: consider removing this loop when trac #6934 is resolved
+last_volumes_read = [0]
+read_count = 0
+while (0 in last_volumes_read) and (read_count < 3):
+self._mixer.set_volume(self._master, tuple(volume_list))
+last_volumes_read = self._mixer.get_volume(self._master)
+read_count += 1
def set_mute(self, mute):
if not self._mixer or not self._master:
diff --git a/src/model/devices/Makefile.am b/src/model/devices/Makefile.am
index 5440eeb..3124144 100644
--- a/src/model/devices/Makefile.am
+++ b/src/model/devices/Makefile.am
@@ -5,4 +5,6 @@ sugar_PYTHON = \
__init__.py \
device.py \
devicesmodel.py \
- battery.py
+ battery.py \
+ speaker.py
+
diff --git a/src/model/devices/devicesmodel.py
b/src/model/devices/devicesmodel.py
index 691e19e..32c77da 100644
--- a/src/model/devices/devicesmodel.py
+++ b/src/model/devices/devicesmodel.py
@@ -23,6 +23,7 @@ from model.devices import device
from model.devices.network import wireless
from model.devices.network import mesh
from model.devices import battery
+from model.devices import speaker
from hardware import hardwaremanager
from hardware import nmclient
@@ -54,6 +55,8 @@ class DevicesModel(gobject.GObject):
for udi in hal_manager.FindDeviceByCapability('battery'):
self.add_device(battery.Device(udi))
+self.add_device(speaker.Device())
+
def _observe_network_manager(self):
network_manager = hardwaremanager.get_network_manager()
if not network_manager:
diff --git a/src/model/devices/speaker.py b/src/model/devices/speaker.py
new file mode 100644
index 000..d3b9967
--- /dev/null
+++ b/src/model/devices/speaker.py
@@ -0,0 +1,59 @@
+# Copyright (C) 2008 Martin Dengler
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for
Re: [sugar] [PATCH] Add speaker device and icon by default
On Mon, Apr 28, 2008 at 03:49:12PM +0200, Tomeu Vizoso wrote:
> On Fri, Apr 25, 2008 at 11:50 PM, Martin Dengler
> <[EMAIL PROTECTED]> wrote:
>
> > +self.palette = SpeakerPalette(_('My Speakers'), model=model)
> > +self.set_palette(self.palette)
>
> 'set_palette' is the setter for the 'palette' property, so the second
> line shouldn't be needed.
Thanks, I'll remove. That code was cut & pasted from battery.py, so
I'm guilty of cargo-culting here.
>
> > +model.connect('notify::level', self._speaker_status_changed_cb)
> > +model.connect('notify::muted', self._speaker_status_changed_cb)
> > +self.connect('expose-event', self._expose_event_cb)
>
> Callbacks should start with two underscores in order to avoid name
> clashes.
Thanks -- others have pointed this out as well in other code sections
and I guess I missed those.
> Tomeu
Martin
pgpVzj1mJl35E.pgp
Description: PGP signature
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add speaker device and icon by default
On Fri, Apr 25, 2008 at 11:50 PM, Martin Dengler
<[EMAIL PROTECTED]> wrote:
> +self.palette = SpeakerPalette(_('My Speakers'), model=model)
> +self.set_palette(self.palette)
'set_palette' is the setter for the 'palette' property, so the second
line shouldn't be needed.
> +model.connect('notify::level', self._speaker_status_changed_cb)
> +model.connect('notify::muted', self._speaker_status_changed_cb)
> +self.connect('expose-event', self._expose_event_cb)
Callbacks should start with two underscores in order to avoid name clashes.
The rest looks good to me.
Thanks,
Tomeu
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
[sugar] On improving Sugar performance
Hello, me, tomeu and Marco engaged in a discussion about Sugar performance off-list, but at some point we thought it would be better material for a public discussion. Each one of us has been interested in performance for a long time, working in different areas and with different perspectives. To my knowledge, Michael, Chris and Scott have also been measuring and contributing in the past. We have of course different ideas and proposals, with Tomeu being in a better position to give us hard numbers and informed opinions because of the truly aggressive performance work he has been doing lately. When we say generically "performance", we aggregate several related issues: - time to perform specific actions (such as refreshing the screen) - memory footprint of the Sugar shell and associated services - overhead common to all activities (the "hello world" memory usage) - memory footprint of specific activities (such as the browser) - startup time of activities - boot time of the OS To simplify the discussion, I'd like to set aside, for now these other areas: - filesystem (datastore) performance and scalability - networking performance and scalability I'd like to introduce our discussion in the form of a platonic dialog with Tomeu: - What have you been doing so far? - What are the benefits you obtained so far? - Which are the areas where we could gain the most? - Do you see low-hanging fruit we could pick in the short term? - How much further can we improve by dropping specific unnecessary or redundant work and similar pessimizations? - How much further can we improve by refactoring subsystems and APIs to do less work? - How much further can we improve by rewriting some performance-critical parts in a low-level language? - How much further can we improve by replacing inefficient frameworks and support modules with different implementations available off the shelf? (such as "use - How much further can we improve by compromising on the feature set we are providing? (such as "disable anti-aliasing" or "simplify SVG icons or convert to bitmap") - How much further can we improve by pruning from feature set? (such as "drop rounded edges from the Sugar theme"). Anyone is of course welcome to join us with questions, answers and proposals. To keep the discussion relaxed, we do not require backing each and every idea with benchmark results, which in some cases are hard to obtain. Nevertheless, measuring is a useful tool, especially when there there's disagreement on how effective each solution might be. -- \___/ _| o | Bernie Innocenti - http://www.codewiz.org/ \|_X_| "It's an education project, not a laptop project" ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar\Windows won't ship
On Mon, Apr 28, 2008 at 9:59 AM, John Gilmore <[EMAIL PROTECTED]> wrote: > > I'll say that the impression that I have received as an outsider is that > > the people working on Sugar have not at all been interested in > > compatibility with normal linux software. > > It's more accurate to say that while they are somewhat interested in > that as an abstract idea, they are much more interested in making > their interface whizzier, which is fun We are not working on whatever we personally consider interesting or fun. OLPC has a management, a sales team, a deployment team, whose feedback is essential to determine the priorities. > If someone came along with clean patches to make Sugar work better > with normal Linux/Unix software, I think they'd accept them. (Some > patches to Gnome, KDE, and other window managers are also going to be > needed, at least if Sugar apps want to show their current SVG icons; > no other window manager supports drawing SVG icons.) OLPC is trying to do planning in the open: http://lists.laptop.org/pipermail/devel/2008-April/012659.html You are welcome to participate and push for the compatibility issues to be prioritized very high and targeted for August. Failing that yeah, the alternative is to send patches, like in any other free software project. (As you can see from the sugar archives, reviews are timely and the code most of the times is integrated). Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] jumpy cursor problem and sugar issue
Tomeu Vizoso wrote: > We plan to work on this soon. The plan is to have a delay since the > mouse enters in the corner and before the frame is brought up. This > delay will be configurable with an slide in the control panel. That seems like a great idea to improve usability. -- \___/ _| o | Bernie Innocenti - http://www.codewiz.org/ \|_X_| "It's an education project, not a laptop project" ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar\Windows won't ship
On Mon, Apr 28, 2008 at 9:59 AM, John Gilmore <[EMAIL PROTECTED]> wrote: > Somebody who implemented Sugar in the early days clearly didn't > understand the X11 networked graphics model -- or didn't mind breaking > it for expediency -- but they only broke it in small ways, which are > pretty easily patched up. The fact that it's broken only in small ways is *not* accidental. We understood X11, but we also understood the non-standard UI design we had to implement. The current implementation is one of the possible tradeoffs to be able to express the new UI metaphors by reusing standard X11 semantics. As Walter said compatibility was not considered a very high priority at the time. One year of experience and UI design changes later, I'm confident that we can easily refactor the window management layer to fix the broken compatibility bits. To be really useful though, we will have to solve compatibility issues in rainbow, datastore and activities distribution (.xo). And those are much trickier. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar\Windows won't ship
On Mon, Apr 28, 2008 at 7:39 AM, <[EMAIL PROTECTED]> wrote: > in fact there was a post within the last week claiming that it would be a > bad idea to make sugar able to use unmodified linux software becouse that > would mean that the educational software and activities being written for > sugar could then be used on any linux box without sugar and this would > mean the death of sugar. a couple of us responded that if sugar requires > that sort of lock-in it deserved to die, but I don't remember anyone > speaking up to say that the developers of sugar or the software team at > OLPC disagreed with the initial poster. The lists has been pretty busy in the last few weeks and if we spent time reading and answering every single post, it would not leave us any time to code. That's not the position of the team at all and Walter just told it clearly in this same thread. I'm not sure why you are trying to pretend otherwise. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] jumpy cursor problem and sugar issue
On Sun, Apr 27, 2008 at 4:50 PM, Bryan Berry <[EMAIL PROTECTED]> wrote: > thanks Carol, this instruction for disabling the corner sensitivity is > extremely useful! I may use it in the custom build I roll out, some 3-4 > months from now. We plan to work on this soon. The plan is to have a delay since the mouse enters in the corner and before the frame is brought up. This delay will be configurable with an slide in the control panel. Thanks for the feedback, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar\Windows won't ship
On Mon, Apr 28, 2008 at 9:59 AM, John Gilmore <[EMAIL PROTECTED]> wrote: > > I'll say that the impression that I have received as an outsider is that > > the people working on Sugar have not at all been interested in > > compatibility with normal linux software. > > It's more accurate to say that while they are somewhat interested in > that as an abstract idea, they are much more interested in making > their interface whizzier, which is fun, and in rewriting the most > obviously braindead parts of the Journal/Datastore, which staves off > programmer and end-user insanity. (I'm paraphrasing drastically, from > having watched a bit of their goal-setting for the next release from > afar.) All this sarcasm only makes things even muddier. Please raise your concerns in a clearer way. > If someone came along with clean patches to make Sugar work better > with normal Linux/Unix software, I think they'd accept them. (Some > patches to Gnome, KDE, and other window managers are also going to be > needed, at least if Sugar apps want to show their current SVG icons; > no other window manager supports drawing SVG icons.) Yes. > If the community waited around til the two? three?-person Sugar team > got around to implementing these features itself, they might have to > wait til 2010 or so. Maybe not so long. But please send the patches anyway. [...] > That has been > patched, but just barely; the API still comes with terrible > assumptions like "of course the application will make a copy of every > file it touches". This is plain false. Where did you get that idea? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Fix appearance of activity bundles (in Journal)
r+
On Sat, Apr 26, 2008 at 4:53 PM, Eben Eliason <[EMAIL PROTECTED]> wrote:
> After much ado, here is the resulting patch.
>
> - Eben
>
>
>
>
> On Fri, Apr 25, 2008 at 2:17 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, Apr 23, 2008 at 10:05 PM, Eben Eliason <[EMAIL PROTECTED]> wrote:
> > >
> > > On Wed, Apr 23, 2008 at 3:52 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote:
> > > > On Wed, Apr 23, 2008 at 9:45 PM, Eben Eliason <[EMAIL PROTECTED]>
> wrote:
> > > > > Hmm, you mean:
> > > > >
> > > > >
> > > > > if jobject.metadata.get('title', ''):
> > > > > title_text = jobject.metadata.get('title', '')
> > > > > else
> > > > > title_text = _('Untitled')
> > > > >
> > > > > title.props.text = title_text
> > > > > ...
> > > > >
> > > > > Do I not need to declare title_text outside the scope of the
> condition
> > > > > first? For that matter, is the null string always treated as
> False in
> > > > > conditions, even though it's distinct from None type?
> (Sorry...didn't
> > > > > play in Python much before.)
> > > >
> > > > Sorry, didn't meant that as a literal solution.
> > > >
> > > >
> > > > > I supposed there's also:
> > > > >
> > > > > title_text = _('Untitled')
> > > > >
> > > > > if jobject.metadata.get('title', ''):
> > > > > title_text = jobject.metadata.get('title', '')
> > > > >
> > > > > title.props.text = title_text
> > > >
> > > > This I don't like much, the person that reads needs to make more
> > > > effort to see that you are overriding the var.
> > > >
> > > > This is what I would do:
> > > >
> > > >
> > > > if jobject.metadata.get('title', ''):
> > > >title.props.text = jobject.metadata['title']
> > > > else
> > > >title.props.text = _('Untitled')
> > >
> > >
> > > I'm not sure I like that much either, since I have to set two things
> > > to the values.
> > >
> > >
> > > if jobject.metadata.get('title', ''):
> > > self._title.props.text = jobject.metadata['title']
> > > self._title_entry.props.text = jobject.metadata['title']
> > > else
> > >
> > >
> > > self._title.props.text = _('Untitled')
> > > self._title_entry.props.text = _('Untitled')
> > >
> > > Hence, the reason to use a variable instead. Do you prefer this?
> >
> > Yes, a 'title' variable is better in this case.
> >
> >
> > if jobject.metadata.get('title', ''):
> > title = jobject.metadata['title']
> > else
> > title = _('Untitled')
> > self._title.props.text = title
> > self._title_entry.props.text = title
> >
> > Tomeu
> >
>
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
