[sugar] New etoys release 4.0
* removed/reverted/rewrote all methods not covered by Apache/MIT license * various fixes (#8928, #8929, #8879, #9058, and others) http://dev.laptop.org/pub/sugar/sources/etoys/etoys-4.0.2201.tar.gz http://dev.laptop.org/pub/sugar/sources/etoys-activity/etoys-activity-97.tar.gz - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Grassroots-l] [Localization] OLPC, Chile and Educalibre
On 27.11.2008, at 08:50, Edward Cherlin wrote: > On Thu, Nov 13, 2008 at 2:37 PM, Walter Bender <[EMAIL PROTECTED] > > wrote: >> I suggest you approach Chuck Kane at OLPC directly. If for some >> reason >> he cannot accommodate the request, then we should discuss alternative >> means to deploy Sugar. >> >> -walter >> >> On Thu, Nov 13, 2008 at 5:32 PM, Yamandu Ploskonka <[EMAIL PROTECTED] >> > wrote: >>> (from Werner Westermann, [EMAIL PROTECTED] ) >>> >>> Best regards from Santiago, Chile. >>> >>> In May of this year, we had exciting news where the ICT-Schools >>> program of the >>> Department of Education, Enlaces (http://www.enlaces.cl), asked >>> Educalibre >>> (http://www.educalibre.cl/) to propose a OLPC deployment project. >>> Enlaces previously met >>> with a OLPC and Brightstar representatives asuring a total of 1000 >>> XOs. We went on to >>> develop the proposal and negociate where to deploy the iniciative >>> (Enlaces required us >>> to engage rural areas, outside of the Metropolitan Area, among >>> others): >>> >>> http://wiki.educalibre.cl/index.php/Propuesta_OLPC_Chile >>> >>> Unfortunately, as you can see, the proposal was frustrated, >>> because as Brightstar >>> distributor and partner of the OLPC Foundation, argued that it >>> would not be possible for >>> the Chilean State to purchase only 1,000 XOs, but would consider a >>> minimum of 10,000 XO. >>> Faced with this sudden change of turn and the impossibility of >>> buying that quantity >>> off-budget, Enlaces decided to discard the possibility that the XO >>> came into the hands >>> of our children. > > This is perfectly idiotic. The Give Many page > > http://laptop.org/en/participate/give-many.shtml > > says > > The Give Many program allows donors to bring one laptop per child to > whole classes and schools, and includes Give 100 and Give 1,000 > programs. It offers hundreds of students a new way of learning that is > creative, collaborative and self-empowered. > >* - $219 per laptop to OLPC partner countries and LDCs >* - $259 per laptop to the rest of the world > > > Every donation of 100 or more laptops includes spare parts. Donations > of 1,000 laptops or more are eligible for in-person assistance from > OLPC staff. > > To become a Give Many donor, write to [EMAIL PROTECTED] with your > project timeline, and with details about the receiving school or > group. > > Doesn't anybody at OLPC pay attention to what they tell the public? This version of the give many program is only up for a day or so. It is indeed much nicer than the previous one: == To give 100 or more laptops and direct them to a location you designate, send email to givemany at laptop.org Give 100+ $310 per laptop Give 1000+ $260 per laptop Give 10,000+ $210 per laptop In each case, the donor designates where the laptops are sent. For general information about the many ways you can give laptops through the One Laptop per Child Foundation, please send email to service at laptopgiving.org == - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Sugar-devel] View Source
On 26.11.2008, at 12:07, Tomeu Vizoso wrote: > [cc'ing [EMAIL PROTECTED] because this subject is of importance to > activity authors and I know many haven't yet subscribed to > [EMAIL PROTECTED] Please subscribe!] > > On Tue, Nov 25, 2008 at 5:16 PM, Bert Freudenberg <[EMAIL PROTECTED] > > wrote: >> On 22.11.2008, at 16:35, Simon Schampijer wrote: >> >>> Some great work has been going into this release regarding the 'View >>> source' support. The source of all the activities can be shown, and >>> browse does still support showing the source of the document. >>> >>> === sugar-toolkit === >>> * Add view-source-related methods HandleViewSource and >>> GetDocumentPath >>> >>> === sugar === >>> * Implement a global handler for the view source key >> >> Since I could not find any discussion, let alone documentation about >> this, I (again) got out my rusty Emacs, fed it with some grep'ed >> source files, and reverse-engineered the whole thing. My findings are >> here: > > Sorry, announcing this properly is something that has been in my TODO > for a while, but hadn't managed to get to it yet. > >> http://wiki.laptop.org/go/Low-level_Activity_API#D-Bus_Methods > > All looks good to me. > >> I like the idea so far, but here are the issues I have with the >> current implementation: >> >> 1. HandleViewSource should return a boolean to indicate whether the >> request was handled or not. >> This would also get rid of the Python-specific dbus error handling >> code in viewsource.py because handle_view_source in activity.py could >> simply answer False. > > Hmm, but we still need to handle the case where a non-python activity > hasn't implemented the method, right? Oh certainly, the logic is sound, it's just the "not implemented" Pythonism there that is not necessary. >> 2. GetDocumentPath is a poor name for what it does. >> It should contain "source" because it's not the document that is >> viewed, but its source. How about GetSourcePath()? > > Well, the idea is that, by default, sugar will show the activity's > source. This method is intended for displaying a textual > representation of the sources behind a document, be it html for > browse, logo for turtleart, etc. So perhaps getDocumentSourcePath()? Sure. >> Also, this file is deleted unconditionally when the source view is >> closed. I'd add a boolean "transfer_ownership" flag to indicate that >> it's okay to delete (similar to the datastore API). > > Sounds good, if activity authors think this added complexity is ok, I > can add it. Well, it's more complexity to having to make a copy just so Sugar can delete it ... >> Also, what kinds of source does this support? I noticed the >> Browser's HTML source was highlighted. Is that determined by the file >> name extension? > > The sugar shell tries its best to display a formatted view of the > source code based on the extension and the contents of the file. > Currently, it uses gtksourceview2 for that. If an activity author > would like an improved or new formatter, we should talk to the > upstream maintainers to add it. It's quite configurable and should be > a matter of editing some xml files. Also, the call could additionally answer a mime type which would override the guessing. >> On a more general note, activityservice.py should be annotated with >> the actual DBus signatures. > > True, added it to my TODO at http://sugarlabs.org/go/User:Tomeu :) - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Finding cursors. Ripples in a puddle?
On 25.11.2008, at 02:27, Ken Ritchie wrote: > Does anyone else recall recurring debates about cursor size and the > effect on one's ability to visually discover the location of a > cursor? Yes, there are tradeoffs between simply making cursors > larger (easier to discover location) or making cursors smaller > (easier to place precisely, eclipses fewer pixels)...especially when > the pointing devices are other than by directly touching the display > screen. Such is the case with the present XO laptops. > > To sidestep those debates, I imagine a different way -- one in which > cursors could be of any size, color, shape, etc. -- and yet still > draw my eye quickly to the locus of the current cursor. > > > VISION: Each time my finger tip lands on the touch pad I see a > circular wavefront (on the display, of course) briefly emanating > from the point of the cursor. The wave gently fades as it grows and > dissipates. Thus, it appears as if the screen is overlaid with a > clear puddle and I have lightly touched its surface. The effect > could be simulated with a simple ring; probably a simpler and > cheaper computation than a "wave" effect. A bitblt series would do. > > > Like ripples in a puddle, the visual effect and conceptual metaphor > would seem to draw on nearly universal human experience from early > childhood. Of course, the HCI labs around the world could experiment > with such effects (if not already) to understand the human factors > and optimize the man-machine interface. Meanwhile, it seems worth > trying, pragmatically. > ;-) That is an interesting idea (though I would have to see it first to find out if I like it or not). How would I get an event from the XO touchpad when it is touched? (I wanted to figure this out before replying to your Etoys list msg ...) - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Activity updates in joyride (was Re: TurtleArt-18)
Actually, there currently is *no way* to update the wiki with the latest version of any G1G1 activity *without* affecting the "pegged" version. I repeatedly pinged the OLPC list but everyone seems to busy to fix the wiki (and some of the relevant pages pages are locked). The page that 8.2 laptops are updating from is http://wiki.laptop.org/go/Activities/G1G1/8.2 As you can see this incorrectly points to the *latest* version of each activity in the G1G1 set. It should point to the *8.2* version of each activity. To see the mess, click on the "edit" link of any activity there and then on "what links here". - Bert - On 24.11.2008, at 03:33, Gary C Martin wrote: > Not meaning to pull Walter up on this, but... > > Are the Acitivity wiki pages still not getting version updated (yes I > know it's a complicated undocumented mess of wiki spaghetti that no > one has bothered telling the community about)? There's a whole bunch > of activity releases that have floated by the last ~4 weeks or so with > almost no one tweaking the auto-update pages :-( > > --Gary (much looking forward to a useful auto-update feature) > > P.S. if it is genuinely too much to fight your way through the wiki > cruft, please do privately ping me with your activity v update xo > bundle link + the release it's been tested with. I'll gladly go try > update/create the relevant wiki pages and insert red hot pokers where > necessary (genuine, one time offer)... and I'll even test the change > correctly auto installs on XOs running 767-8.2 (but I can't do joyride > only stuff, having no access to jhbuilds). > > On 23 Nov 2008, at 23:40, Walter Bender wrote: > >> Announcing TurtleArt 18: >> >> .XO: >> http://sugarlabs.org/wiki/images/1/1c/TurtleArt-18.xo >> SOURCE: >> http://dev.laptop.org/pub/sugar/sources/TurtleArt/ >> TurtleArt-16.tar.bz2 >> >> >> Turtle Art has been rebased to use SVG instead of GIF. I made the >> change in order to make it easier to localize. The other changes >> include Finnish language support and improved support for varying >> screen sizes. >> >> Localization teams: please review the translations and report any >> errors or omissions. >> >> -walter >> -- >> Walter Bender >> Sugar Labs >> http://www.sugarlabs.org >> ___ >> Sugar mailing list >> Sugar@lists.laptop.org >> http://lists.laptop.org/listinfo/sugar > > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Presence Service
On 20.11.2008, at 11:52, Morgan Collett wrote: > On Thu, Nov 20, 2008 at 12:24, Bert Freudenberg > <[EMAIL PROTECTED]> wrote: >> On 20.11.2008, at 10:17, Morgan Collett wrote: >>> Collabora have therefore suggested replacing Presence Service with a >>> combination of Mission Control and moving functionality up into >>> sugar-toolkit and the activities themselves, so that everything is >>> talking Telepathy and not some arbitrary abstraction of an >>> abstraction >>> framework. >> >> >> Will the DBus interface to Mission Control be available by then? I >> only saw a year-old proposal for it. If not, it will take a >> considerable amount of boring work to migrate Etoys. > > The plan would have to include providing the same or similar API for > non python activities as the current PS API - without failing to > remove unnecessary indirection and abstraction... Just to clarify: I was specifically referring to a D-Bus API. An activity written in C could easily use the existing C-level API to Mission Control. Not all "non-Python" activities are created equal :) - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Presence Service
On 20.11.2008, at 10:17, Morgan Collett wrote: > Collabora have therefore suggested replacing Presence Service with a > combination of Mission Control and moving functionality up into > sugar-toolkit and the activities themselves, so that everything is > talking Telepathy and not some arbitrary abstraction of an abstraction > framework. Will the DBus interface to Mission Control be available by then? I only saw a year-old proposal for it. If not, it will take a considerable amount of boring work to migrate Etoys. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Error building squeak in jhbuild on Ubuntu 8.10
On 17.11.2008, at 12:11, Morgan Collett wrote: > On Thu, Nov 6, 2008 at 13:01, Morgan Collett > <[EMAIL PROTECTED]> wrote: >> When building jhbuild on Ubuntu 8.10, I get the following error >> building squeak: >> >> cc1: warnings being treated as errors >> In function 'ms_ps2_disable': >> /home/morgan/sugar-jhbuild/source/squeak/platforms/unix/vm-display- >> fbdev/sqUnixFBDevMousePS2.c:144: >> error: ignoring return value of 'write', declared with attribute >> warn_unused_result >> >> This has also been reported by the developer packaging squeak for >> Ubuntu: >> https://bugs.launchpad.net/ubuntu/+source/squeak-vm/+bug/254547 >> >> That bug report suggests building with -D_FORTIFY_SOURCE=0 - or is >> there a better way of fixing this? > > For the record, I did get squeak to build in jhbuild by manually > configuring it with -D_FORTIFY_SOURCE=0. Is this an appropriate fix > suitable for upstream, or can somebody suggest a better approach? I had forwarded your report upstream on Nov. 6 but have not heard back yet. I'll ping him again. In the mean time disabling the fortification seems like a good workaround. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Major differences between releases
On 10.11.2008, at 16:45, Martin Langhoff wrote: > On Fri, Nov 7, 2008 at 9:02 AM, Morgan Collett <[EMAIL PROTECTED] > > wrote: >> I've started http://wiki.laptop.org/go/API_changes to track Sugar and >> system API changes between releases. It's not very comprehensive so >> far - contributions welcome. > > Little nag: how about qualifiying that it's about the XO OS + Sugar > (as opposed to XS :-) ) Little nag: how about adding XS changes, too? ;) - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar on Ubuntu - Summary
On 06.11.2008, at 16:50, David Farning wrote: > > Currently, Squeak Etoys is distributed as an image or snapshot > rather than source code. This is misleading. Etoys comes with full source code, nothing is "held back". > While distributing images is the standard work flow for Squeak > Etoy developers, they are difficult for down stream developers to > work with. This is not true. It is *not* difficult to work with images, it is what every Squeak developer uses. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Sugar on Edubuntu
On 06.11.2008, at 00:12, David Farning wrote: > Do you know who I should talk to about requesting that > http://www.squeak.org/SqueakLicense/ > be update to reflect this information? Squeak (at squeak.org) and Etoys (at vpri.org / squeakland.org) are two different versions that were last merged at Squeak version 3.8. The full relicensing for now only applies to the Etoys version, but the squeak.org version will certainly follow soon. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar on Edubuntu
On 05.11.2008, at 13:55, David Farning wrote: > .One sticking point was the availability of squeak on Ubuntu. If I > remember this issue was beaten to death before I got involved with SL. I only remember discussion of getting it into Debian, not Ubuntu. Basically, even though the license issues are finally resolved, they did not want to have it in because they do not agree with its current development model: http://lists.laptop.org/pipermail/devel/2008-June/015479.html - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Proper D-Bus usage
On 31.10.2008, at 03:30, Tomeu Vizoso wrote:
> On Wed, Oct 29, 2008 at 5:30 PM, Bert Freudenberg <[EMAIL PROTECTED]
> > wrote:
>> On 29.10.2008, at 03:42, Marco Pesenti Gritti wrote:
>>
>>> On Wed, Oct 29, 2008 at 9:45 AM, Tomeu Vizoso
>>> <[EMAIL PROTECTED]>
>>> wrote:
>>>>
>>>> We could easily hack the DS in 0.83 to return D-Bus strings for
>>>> standard properties that are known (or rather, expected) to contain
>>>> textual data, but introducing this inconsistency in the API may
>>>> not be
>>>> such a good idea.
>>
>> I don't see how it would be "inconsistent" that when an activity
>> saves a
>> "title" meta-data property which obviously is a string, and it
>> resumes, to
>> expect it will be returned as a string and not magically converted
>> to a byte
>> array. An activity should not have to care about the DS's internal
>> representation.
>
> I don't see what stops an activity from storing a sequence of bytes
> that doesn't conform to any text encoding. The DS won't be able to
> index it, but should it reject the entry?
>
> How is the DS expected to return this sequence as a D-Bus string?
We are talking only about the mandatory, well-defined meta data
properties. If an activity stores an invalid string, it is buggy, and
bad things are expected to happen.
> What
> will happen to eToys or other activities that expect all titles come
> from the DS as UTF-8 strings?
The activities will break with badly encoded byte arrays too, because
they will try to decode it as if it was a UTF-8 string.
>> For custom properties you could state they must be byte arrays, but
>> for the
>> known properties it certainly is more appropriate to use the actual
>> data
>> type.
>
> What's the "actual data type"? The type that the activity provided
> when the property was first sent to the DS? Or the convention we used
> in the older DS?
No, the type defined by the contract between Sugar and its Activities.
This is something like "the 'title' property is a utf-8 encoded string
specifying the main title to be displayed in the journal list". Am I
the only one who would find mentioning of byte arrays in that spec
ugly and unnecessary?
>> A byte array is not a string. Or vice versa. If you disagree, ask the
>> D-Bus designers why they did put in a string type instead of simply
>> using
>> byte arrays.
>
> This is a matter of naming. In some environments, a string is plainly
> a sequence of bytes. In some others, strings are sequences of bytes
> expected to contain textual data in some specific encoding.
Oh please, it is not just a matter of naming. Think, for example,
about how you would compare two strings, and how you would compare two
byte arrays. Or how you would present a string to a user (developer)
vs. a byte array.
Besides, we use high-level representations to aid reasoning about
what's going on inside the computer. By dumbing down everything to the
lowest possible representation you are removing valuable semantics.
I can't believe I am really the only one on this list who thinks that
Sugar should be explorable all the way down. If we collectively
thought that byte arrays are as fine as higher-level constructs, why
would we even be here?
>> And after all, the meta data is declared to be a{sv} instead of
>> a{say}
>> precisely to accommodate appropriate types for the values.
>
> Can you extend on what you mean by "accommodate appropriate types for
> the values"?
To use the string type for properties that are text strings, to use
the integer type for properties that are numbers, to use the boolean
type for properties that are truth values, etc.
>> I mentioned it before, and I still maintain that this is an abuse
>> of D-Bus.
>> Things that are strings should be transmitted as strings. If
>> nothing else it
>> makes debugging a lot easier - strings will be rendered as strings
>> by the
>> various D-Bus diagnostic tools.
>
> As I explained before, "Things that are strings" means that someone
> needs to decide what is a string and what not. And if that someone
> aren't the leafs, then others need to be communicated of this decision
> and act accordingly. I'm not sure which benefit brings all this
> complexity.
I think you are only seeing the complexity it would add to your
datastore implementation, where I only see the conceptual simplicity.
>> So, pretty please ... with sugar on top ;) deliver the strings as
>> strings.
>
> I personally don
Re: [sugar] Status of Joyride
On 31.10.2008, at 03:02, Peter Robinson wrote: > Can someone poke the announcer scripts that updates the following > URLs. > http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html In the mean time you can still use what the old scripts generate: http://dev.laptop.org/~bert/joyride-pkgs.html - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [RELEASE] etoys-3.0.2160
this version copes with the datastore using byte arrays for strings, thus allowing to resume again http://dev.laptop.org/pub/sugar/sources/etoys/etoys-3.0.2160.tar.gz http://dev.laptop.org/pub/sugar/sources/etoys-activity/etoys-activity-96.tar.gz - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Proper D-Bus usage (was Re: October 29 - Tarballs due for 0.83.1)
On 29.10.2008, at 09:57, Marco Pesenti Gritti wrote:
> On Wed, Oct 29, 2008 at 5:30 PM, Bert Freudenberg <[EMAIL PROTECTED]
> > wrote:
>> On 29.10.2008, at 03:42, Marco Pesenti Gritti wrote:
>> I don't see how it would be "inconsistent" that when an activity
>> saves a
>> "title" meta-data property which obviously is a string, and it
>> resumes, to
>> expect it will be returned as a string and not magically converted
>> to a byte
>> array. An activity should not have to care about the DS's internal
>> representation.
>
> I think Tomeu point is that the DS should know nothing about the type
> of the metadata properties and interpretation of the data blob (the
> array of bytes) should be left entirely to the activities.
It's not a data blob. The mandatory meta-data properties are well
defined. This is (or should be) part of the Sugar specification. Like,
the Journal has to agree with activities that the meta data property
named "title" is actually a Unicode string. It is *not* left to the
activities.
Besides, if you throw away the knowledge that something is a string,
then you lose quite a bit of useful information. Like, full text
search pretty much requires knowing what is a string and what not. You
may want to read about comparing Unicode strings - it certainly is not
as simple as comparing byte arrays. Let alone if we want to do fuzzy
search.
>> And after all, the meta data is declared to be a{sv} instead of
>> a{say}
>> precisely to accommodate appropriate types for the values.
>
> Yeah but the interface was written for a datastore which had a notion
> of metadata property type (although a very bad one). The new one does
> not.
Then change the API signature and do not pretend it did not break.
Any comment on the debugability concerns?
- Bert -
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
[sugar] Proper D-Bus usage (was Re: October 29 - Tarballs due for 0.83.1)
On 29.10.2008, at 03:42, Marco Pesenti Gritti wrote:
> On Wed, Oct 29, 2008 at 9:45 AM, Tomeu Vizoso
> <[EMAIL PROTECTED]> wrote:
>>
>> We could easily hack the DS in 0.83 to return D-Bus strings for
>> standard properties that are known (or rather, expected) to contain
>> textual data, but introducing this inconsistency in the API may not
>> be
>> such a good idea.
I don't see how it would be "inconsistent" that when an activity saves
a "title" meta-data property which obviously is a string, and it
resumes, to expect it will be returned as a string and not magically
converted to a byte array. An activity should not have to care about
the DS's internal representation.
For custom properties you could state they must be byte arrays, but
for the known properties it certainly is more appropriate to use the
actual data type. A byte array is not a string. Or vice versa. If you
disagree, ask the D-Bus designers why they did put in a string type
instead of simply using byte arrays.
And after all, the meta data is declared to be a{sv} instead of a{say}
precisely to accommodate appropriate types for the values.
> After all I think the best solution here is to adapt Etoys.
"Best" in what sense? It indeed is easy enough to make Etoys cope with
byte arrays, but IMHO it adds to the confusion of every future
implementer of a non-Python activity.
> The inconsistency could be really confusing.
I mentioned it before, and I still maintain that this is an abuse of D-
Bus. Things that are strings should be transmitted as strings. If
nothing else it makes debugging a lot easier - strings will be
rendered as strings by the various D-Bus diagnostic tools.
So, pretty please ... with sugar on top ;) deliver the strings as
strings.
- Bert -
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] October 29 - Tarballs due for 0.83.1
On 28.10.2008, at 14:20, Marco Pesenti Gritti wrote:
> On Tue, Oct 28, 2008 at 10:16 PM, Bert Freudenberg <[EMAIL PROTECTED]
> > wrote:
>> Guess I should make Etoys cope with the changed datastore interface
>> then.
>
> Did the interface change? I think tomeu new datastore actually has the
> same dbus interface...
Well, some of the API uses "variable" types, so even if the interface
does not change literally, changing the types involved poses a problem.
E.g., meta-data properties are declared as dictionary with string keys
but arbitrary values ("a{sv}"). In practice, all meta data values are
strings. They used to use the String ("s") D-Bus type, but now Tomeu
changed it to byte arrays ("ay"). This is breaking Etoys resume which
reads the title property and expects a String but gets a ByteArray.
- Bert -
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] October 29 - Tarballs due for 0.83.1
On 28.10.2008, at 10:55, Marco Pesenti Gritti wrote: > On Tue, Oct 28, 2008 at 6:52 PM, Bert Freudenberg <[EMAIL PROTECTED] > > wrote: >> >> On 28.10.2008, at 04:01, Simon Schampijer wrote: >> >>> Marco Pesenti Gritti wrote: >>>> >>>> Dear maintainers, >>>> >>>> the next stable release is the 30th October. >>> >>> Just for the record - it is an unstable release :) >> >> >> Is this basically what's in jhbuild right now? > > Yup. Guess I should make Etoys cope with the changed datastore interface then. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] October 29 - Tarballs due for 0.83.1
On 28.10.2008, at 04:01, Simon Schampijer wrote: > Marco Pesenti Gritti wrote: >> Dear maintainers, >> >> the next stable release is the 30th October. > > Just for the record - it is an unstable release :) Is this basically what's in jhbuild right now? - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 proposal: View source key everywhere
Am 23.10.2008 um 15:33 schrieb [EMAIL PROTECTED]: > bert wrote: >> Am 23.10.2008 um 15:15 schrieb [EMAIL PROTECTED]: >> >>> an addition to activity.info, with sensible defaults, would be the >>> best bet, i think. >> >> This would mean that sometimes the shell and sometimes the activity >> would have to handle that key, which is fragile. I'd opt for the >> shell >> always handling the key, then trying to invoke the activity's view >> source function, and if that fails, handle it itself. >> >> That "not handled by activity" case could of course be customized by >> entries in activity.info. > > sure, that's fine. but i think we need to keep thinking about > how to support of non-, or not-fully-sugarized applications with > every new feature we do (as well as with every revision of old > features). Right. Hence the fallback to the default viewer if the activity does not implement that (or any) DBus method. Or did I misunderstand you? - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 proposal: View source key everywhere
Am 23.10.2008 um 15:15 schrieb [EMAIL PROTECTED]: > an addition to activity.info, with sensible defaults, would be the > best bet, i think. This would mean that sometimes the shell and sometimes the activity would have to handle that key, which is fragile. I'd opt for the shell always handling the key, then trying to invoke the activity's view source function, and if that fails, handle it itself. That "not handled by activity" case could of course be customized by entries in activity.info. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 proposal: View source key everywhere
Am 23.10.2008 um 14:53 schrieb Tomeu Vizoso: > Hi, > > I think that with a small effort, we could implement something much > better than what we have today. > > We have glorious plans for the view source key, but as no resources > have been devoted to them, perhaps we should scale back and make sure > that we provide the best we can today. And let the future deal with > the dreams. > > Have hacked a quick way of displaying the contents of the currently > active activity bundle, along with displaying the source code if the > activity ships its source inside the bundle. > > Screenshot of Implode's source: http://dev.laptop.org/~tomeu/viewsource.png > > The approach I have followed is installing a global keybinding that is > handled in the shell. If you want to try it, it's a matter of dropping > the file in the url below into > ~/sugar-jhbuild/install/share/sugar/extensions/globalkey, if you have > a recent enough sugar-jhbuild. > > http://dev.laptop.org/~tomeu/viewsource.py > > This approach has a good thing that is that works everywhere, but has > a major problem: doesn't let activities override it and handle > themselves the view source key event. This is very bad for activities > like Etoys, the ones produced by Pippy or activities that would prefer > to display the source code for the _content_ loaded in that moment > (Browse). > > Alternative 1: Move it to sugar-toolkit, would be available to all > python activities, and activities would be able to override it easily. > Inconvenient: non-python activities wouldn't benefit from it. > > Alternative 2: Add a mechanism for the shell to know if an activity > wishes to provide its own view source window. It could be done by > adding one more D-Bus method or by adding one more property to > activity.info. Inconvenient: adds complexity to activity development. > > Opinions? This would definitely be an improvement :) I'd add a DBus method to the activity protocol answering a boolean. If the activity answers False (or does not implement the method) the system would do its best to show the source. If it answers True, the activity handled the request on its own. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 Proposal: Persistent activity storage (Bert Freudenberg)
Am 22.10.2008 um 17:58 schrieb C. Scott Ananian: > On Tue, Oct 21, 2008 at 6:58 PM, Michael Stone <[EMAIL PROTECTED]> > wrote: >>> I want to make sure we don't slow down the launch time without a >>> very >>> good reason. >> >> Well, how much risk and how much of Marco's, my, and Tomeu's time >> do you >> think we should squander on supporting hacks to make activities >> launch >> quickly? > > A decent amount of time seems reasonable. Activity startup time is a > big user-visible concern. > > But we've drifted from the subject line. Indeed. Who is putting recipient names in the subject anyways? Please stop that. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] sugar-toolkit bindings
Am 21.10.2008 um 11:19 schrieb Aleksey Lim: > Hello, > > What about activities in not only Python (or thats "not a laptop > project!" > but "not not Python project!":). I started implementing basic API > for Ruby and > realized that it isn't worth to do - the right(and common) way is C > API. > Thats why I've started porting sugar-toolkit package to C. > > The common idea is - using pygtk-codegen's .defs files to generate > binding code > for other langs (not only for Python). I hope I write basic C > code(about 50%) > and thats good idea to know what does sugar community thing about > this (I am not > familiar with sugar). The Sugar developers list is a better place to discuss this: http://lists.laptop.org/listinfo/sugar IMHO it's not worth replicating sugar-toolkit in C (and certainly not *yet*, given the API is still in flux). The D-Bus API is reasonably easy to use and independent of your choice of language. See http://wiki.laptop.org/go/Low-level_Activity_API - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 Proposal: Persistent activity storage
Am 20.10.2008 um 21:35 schrieb Michael Stone: > On Mon, Oct 20, 2008 at 09:25:40PM +0200, Bert Freudenberg wrote: >> >> Am 20.10.2008 um 21:12 schrieb Michael Stone: >> >>> On Mon, Oct 20, 2008 at 01:36:06PM -0500, Yamandu Ploskonka wrote: >>>> It would be way nice it also came back to the same page, if you are >>>> reading a book >>> >>> Yes, that's also a goal, though it will certainly require >>> activity- level >>> changes. >> >> Err - hasn't that been a requirement from the beginning? I thought >> that any activity not storing its full state and thus not resuming >> to the exact same state was violating the system rules. > > Correct. > Michael > > (Perhaps you are suggesting that all current activity implementations > conform to this requirement?) No, but they should :) The conversation above just made it sound like it was a new idea. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 Proposal: Persistent activity storage
Am 20.10.2008 um 21:12 schrieb Michael Stone: > On Mon, Oct 20, 2008 at 01:36:06PM -0500, Yamandu Ploskonka wrote: >> It would be way nice it also came back to the same page, if you are >> reading a book > > Yes, that's also a goal, though it will certainly require activity- > level > changes. Err - hasn't that been a requirement from the beginning? I thought that any activity not storing its full state and thus not resuming to the exact same state was violating the system rules. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Dependencies (was [Activities] Tux Typing on OLPC XO)
See http://wiki.laptop.org/go/Activity_bundles#Bundling_Native_Libraries - Bert - Am 20.10.2008 um 15:20 schrieb Brian Jordan: > How should dependencies like TuxType's be handled? > > (found list at http://sophie.zarb.org/rpm/Momonga,4,x86_64/tuxtype/deps > ) > > Thanks > Brian > > -- Forwarded message -- > From: David Bruce <[EMAIL PROTECTED]> > Date: Mon, Oct 20, 2008 at 7:39 AM > Subject: [Activities] Tux Typing on OLPC XO > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > > > Hello, > > I maintain two of the Tux4Kids apps, Tux Typing and TuxMath. At the > request of the OLPC project, I have been working on getting Tux Typing > to run well on the XO. I have completed the most important changes > needed for Tux Typing itself, and it is now time to address bundling > it as a Sugar activity. Tux Typing is a C program with a number of > library dependencies, not all of which are in the XO base setup. > > Where can I look for info on this topic? > > David Bruce ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (very) Little Proposals for 9.1
Am 13.10.2008 um 15:49 schrieb Marco Pesenti Gritti: > On Mon, Oct 13, 2008 at 3:37 PM, Bert Freudenberg <[EMAIL PROTECTED] > > wrote: > But this power-button UI could be in addition to a regular menu, which > should not be invoked from the home view but from the frame's device > section. > > A computer "device" was already brought up for something else that I > cannot recall at the moment. It seem to make more sense to me, but > than we also have the control panel in the home view palette... That should of course also move to the device frame. The only sensible menu action for the XO icon is to invoke the "about me" section in the control panel. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (very) Little Proposals for 9.1
Am 13.10.2008 um 15:35 schrieb [EMAIL PROTECTED]: > jerome wrote: >> I agree with this. I was with my (almost) 7 year old daughter >> yesterday and she was studying scratch with 767 and after an hour of >> playing around, she told me that she wants to turn it off (the XO) >> but >> she couldn't determine how as there is no obvious way of doing so >> from >> the OS unlike what she can do on XP or Gnome, so the first thing she >> did was press the power button. > > i've always been surprised that the power button doesn't allow > shutdown. i think the button should invoke a menu, which, if left > untouched for 5 or 10 seconds, would allow the laptop to sleep > as it does now. the menu should have entries for "cancel" and > "shutdown". i suppose for completeness there should be one for > "suspend" as well, but "reboot" is unnecessary, imho. > > (if this menu were present, there might be no need for those > entries in the UI itself.) ... except if not running on the XO. But this power-button UI could be in addition to a regular menu, which should not be invoked from the home view but from the frame's device section. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Putting stuff inside the datastore for non-activities
Am 10.10.2008 um 23:24 schrieb Sayamindu Dasgupta: > On Sat, Oct 11, 2008 at 2:24 AM, Marco Pesenti Gritti > <[EMAIL PROTECTED]> wrote: >> On Fri, Oct 10, 2008 at 10:43 PM, Sayamindu Dasgupta >> <[EMAIL PROTECTED]> wrote: >>> Hello, >>> The sugar-almanac has a nice guide on how put stuff inside the >>> datastore programmatically >>> (http://wiki.laptop.org/go/Sugar.datastore.datastore#How_do_I_save_a_simple_text_file_to_the_datastore.3F >>> >>> ) >>> However, it makes the assumption that the method is being called >>> from >>> a sugar activity. (file_path = >>> os.path.join(self.get_activity_root(), >>> 'instance', filename)) >>> Can anyone tell me where to put in a file if I am not calling this >>> from within an activity ? >> >> afaik you can put it wherever you like. copy-to-journal for example >> is >> just writing an existing file to the DS... >> > > Yes - but in my case, I have a file in tmp (created by mozplugger) > which I need to move to the journal. I can't keep the file in tmp (as > in copy-to-journal), since it may get deleted, and I can't write in > random places in /home/olpc (rainbow might not like that). In that > case, what would be the safest place to store the file ? The datastore will make a copy - don't worry, just hand it the file from /tmp. Btw, rainbow only isolates activities, so if your code is not running from an activity you can freely write in the olpc home directory. However, if I understand correctly you are in mozplugger which is running inside the Browse activity so you could use the activity root directory if indeed needed (see http://wiki.laptop.org/go/Low-level_Activity_API#File_Access ). - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Cross Posted] High res screenshots of Sugar
Am 10.10.2008 um 18:02 schrieb Sayamindu Dasgupta: > On Fri, Oct 10, 2008 at 9:24 PM, Bert Freudenberg <[EMAIL PROTECTED] > > wrote: > Yeah - that's what confused me :-S > >> If it's too hard to educate their art department, just make a >> screenshot and >> adjust the dpi in PhotoShop to 300. They won't notice. > > But don't you think the print process will break in that case ? No, why would it? It's just pixels, and this changes a single number in the picture file (if you adjust dpi without resampling). > >> If you *really* wanted to get fancy, run Sugar inside a VNC server >> of say >> 12000x9000 pixels at 2000 dpi. Sugar is designed to be scalable to >> all >> resolutions so in theory this should work. In practice you'll find >> there are >> some things that are not really scaled. >> > > Fonts will probably be messed up in that case. They shouldn't, Sugar uses scalable fonts. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Cross Posted] High res screenshots of Sugar
Am 10.10.2008 um 17:11 schrieb Sayamindu Dasgupta: > Hello, > The Turkish team is trying print sugar manuals and they need high res > (300 dpi ??) screenshots of sugar for that. Any idea on how to do that > ? Can you tell them that's a silly request? A screenshot, by definition, is limited to the screen resolution. If it's too hard to educate their art department, just make a screenshot and adjust the dpi in PhotoShop to 300. They won't notice. Or do what OLPC's PR does, fake the screenshots in illustrator. Eben certainly has a lot of them lying around. If you *really* wanted to get fancy, run Sugar inside a VNC server of say 12000x9000 pixels at 2000 dpi. Sugar is designed to be scalable to all resolutions so in theory this should work. In practice you'll find there are some things that are not really scaled. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] sugar and the digital age (was Re: notes from the field - Mongolia)
Am 09.10.2008 um 19:10 schrieb elana langer: > there is a very common feeling amongst policy makers and teacher that > the XO doesn't really prepare students for the field of IT. There was > a pilot project done in Mongolia that was run by the Japanese gov't > where they introduced Linux to 4 towns. The students went on to study > at the Mongolian IT college and apparently "failed" all their courses. > The outcome was that these students were not prepared for "real IT". > > Personally I feel that this is bogus and that it is the notion of IT, > education and learning that need to be examined at the university > level as well - however - just as I have learned when trying to reform > educational methodologies there is a need to meet the norm half way > (at least) and work from within - it would be nice if the OS could be > designed in a similar gentler manner. > > Teachers, parents, gov't officials and many others are concerned that > the computer doesn't conform to their expectations of a computer. Bear > in mind that there was a lot promised in this computer like > collaboration and mesh and the crank (everyone asks about the damn > crank) that are still in development and all get lumped into the > understanding of the OS. > > Essentially, in the minds of these people, fluency on windows, being > able to do power point presentations and surf the web is what being > prepared means. - I think if we could make some things a little more > straightforward like saving, storing and accessing files (in the way > PC users and Mac users can sort their way out in the opposite OS > pretty intuitively) it would help bridge the gap to traditional > expectations. Well, the XO already goes way more than half-way towards the popular notions of how computers should work. Almost all the software stack is identical to what you find on an arbitrary desktop. Demanding that it should go even more towards what is currently hip in this very immature field of "IT" doesn't sound too compelling if the goal is to empower future generations to use computers as malleable tools for thought, rather than as enslaving magical devices for office work. I'm glad at least some aspects of the system question the current status quo. Kudos to the Sugar developers for not giving in to the crowd's pseudo-wisdom. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Home view
Excellent idea. - Bert - Am 09.10.2008 um 16:13 schrieb Walter Bender: > Maybe the list view belongs as part of the Sugar Control Panel. > > -walter > > On Thu, Oct 9, 2008 at 9:45 AM, Bert Freudenberg > <[EMAIL PROTECTED]> wrote: >> >> Am 09.10.2008 um 14:20 schrieb Mikus Grinbergs: >> >>>> So, how about removing the list view and leaving that task to the >>>> Journal? It's a much more logical place anyway, the list view is >>>> basically a filtered view of the activity bundles in the Journal, >>>> right? So if the Journal allowed a filter to just show activities >>>> we >>>> would not need the list view and remove one point of confusion. >>> >>> When I install Activities I do so through 'sugar-install-bundle', >>> not through the Journal. In this proposal, I would be left without >>> a GUI listing of the Activities installed on my system. [I believe >>> a customization key does not journalize the Activities it installs, >>> either.] >> >> Well, it should. And using the command line should have the same >> result as using the GUI. >> >>> My perception of the list view in Home is "here is an user interface >>> specifically suited for the manipulation of activity bundles". I'd >>> prefer to delete/upgrade/install activities through here, rather >>> than through Journal. [The other views of Home show activity labels >>> only with hovering - I have way too many activities installed for me >>> to try to remember what each icon represents.] >> >> >> Good point. The favorites view should be able to show labels, too. >> But >> the list view gets in the way more often than it is useful for me >> (and >> using activities surely outweighs installing/removing activities by >> far). >> >> - Bert - >> >> >> ___ >> Sugar mailing list >> Sugar@lists.laptop.org >> http://lists.laptop.org/listinfo/sugar >> > > > > -- > Walter Bender > Sugar Labs > http://www.sugarlabs.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Home view
Am 09.10.2008 um 14:20 schrieb Mikus Grinbergs: >> So, how about removing the list view and leaving that task to the >> Journal? It's a much more logical place anyway, the list view is >> basically a filtered view of the activity bundles in the Journal, >> right? So if the Journal allowed a filter to just show activities we >> would not need the list view and remove one point of confusion. > > When I install Activities I do so through 'sugar-install-bundle', > not through the Journal. In this proposal, I would be left without > a GUI listing of the Activities installed on my system. [I believe > a customization key does not journalize the Activities it installs, > either.] Well, it should. And using the command line should have the same result as using the GUI. > My perception of the list view in Home is "here is an user interface > specifically suited for the manipulation of activity bundles". I'd > prefer to delete/upgrade/install activities through here, rather > than through Journal. [The other views of Home show activity labels > only with hovering - I have way too many activities installed for me > to try to remember what each icon represents.] Good point. The favorites view should be able to show labels, too. But the list view gets in the way more often than it is useful for me (and using activities surely outweighs installing/removing activities by far). - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Home view
Well, that's beside my point, it's the list view I find awkward, not the various other layouts. - Bert - Am 09.10.2008 um 14:35 schrieb Walter Bender: > You should try the sunflower view (or the spiral I describe in the How > to Modify Sugar chapter in the FLOSSmanual. (I am rewriting that > chapter in light of Scott's changes to favoriteslayout.py). > > -walter > > On Thu, Oct 9, 2008 at 8:31 AM, Bert Freudenberg > <[EMAIL PROTECTED]> wrote: >> Since we're kicking around ideas again ... >> >> I have to admit I hate the list view in the home screen. Maybe if it >> was simpler to switch between the list and favorites view (repeatedly >> pressing F3 was suggested, but not implemented) it would be less >> annoying. But right now I find myself just starring everything and >> using the freeform layout exclusively, which can easily deal with the >> number of activities I have installed. >> >> So, how about removing the list view and leaving that task to the >> Journal? It's a much more logical place anyway, the list view is >> basically a filtered view of the activity bundles in the Journal, >> right? So if the Journal allowed a filter to just show activities we >> would not need the list view and remove one point of confusion. >> >> - Bert - >> ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Home view
Since we're kicking around ideas again ... I have to admit I hate the list view in the home screen. Maybe if it was simpler to switch between the list and favorites view (repeatedly pressing F3 was suggested, but not implemented) it would be less annoying. But right now I find myself just starring everything and using the freeform layout exclusively, which can easily deal with the number of activities I have installed. So, how about removing the list view and leaving that task to the Journal? It's a much more logical place anyway, the list view is basically a filtered view of the activity bundles in the Journal, right? So if the Journal allowed a filter to just show activities we would not need the list view and remove one point of confusion. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activities can't be "hidden" any more
Am 09.10.2008 um 11:20 schrieb Tomeu Vizoso:
> On Thu, Oct 9, 2008 at 11:13 AM, Morgan Collett
> <[EMAIL PROTECTED]> wrote:
>> http://wiki.laptop.org/go/Activity_bundles#.info_File_Format still
>> says:
>>
>> - quote -
>> show_launcher = yes
>>
>> This key is optional. If not present, or if present with a value of
>> "yes", the activity is shown with its icon in the Sugar panel
>> launcher
>> and a valid 'icon' key/value pair is required. If specified with a
>> value of "no", the activity is not shown in the Sugar panel launcher,
>> and the 'icon' key is not required.
>> - end quote -
>>
>> However, as seen with Read, since the Home View redesign this no
>> longer has affect. If Read is starred, it is displayed on the
>> favourites view, not respecting the show_launcher field.
>>
>> Mikus and I have been discussing the implications of this for
>> activities which don't generate content and are only useful if
>> launched from the Journal with content (or joined in a collaborative
>> session which provides content).
>>
>> Can somebody confirm that this field is no longer of effect, so we
>> can
>> update the wiki page and expectations, or if this was an oversight,
>> can we discuss what we really want?
>
> I don't really know what's the expected behavior after the home view
> redesign.
>
> Taking it out from the favorites view is pretty easy, but the activity
> can still be launched form the activity list view and the journal
> which has the same problems. I guess the activity needs to be visible
> in those places because are the way of managing the bundle.
I have an idea :)
When you click the icon of an activity marked as no-launch, the shell/
journal could bring up the object chooser pre-filtered by the
activity's supported mime-types. Then the user could choose which
object to read or view, and the activity would be started with that
object.
This could actually be an entry in the palette for all activities that
have a non-empty list of mime-types (labeled "Start with ...",
inserted just below the current "Start"). If that was the case, then
the only difference between a regular and a "no-launch" activity would
be the default action invoked when clicking the icon, regular
activities would invoke "Start", the others "Start with ...".
Of course, we might deprecate the "show_launcher" option and rename it
to something else to better convey its intention ("requires-document"?).
The shell (and bundle builder) should generate a warning when
installing an activity that is marked as no-launch but has an empty
mime-type list.
- Bert -
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Journal Object Picker in Read
Am 08.10.2008 um 14:48 schrieb Tomeu Vizoso: > On Wed, Oct 8, 2008 at 2:33 PM, Bert Freudenberg > <[EMAIL PROTECTED]> wrote: >> Am 08.10.2008 um 14:23 schrieb Tomeu Vizoso: >> >>> If we can keep things simple for now, I'd rather do it. >> >> >> Well, if that does not mean doing nothing, I'm all for it. Why not >> just push your old patch then? It looks good. > > It won't apply as-is, but that solution sounds good to me. > Alternatively, instead of passing mime_types as an argument to the > constructor, we could make it an argument to the run() method. Both > seem good to me. I care more about the D-Bus bindings and they would not be effected by that. But adding it to the constructor seems sensible to me. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Journal Object Picker in Read
Am 08.10.2008 um 14:23 schrieb Tomeu Vizoso: > If we can keep things simple for now, I'd rather do it. Well, if that does not mean doing nothing, I'm all for it. Why not just push your old patch then? It looks good. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Journal Object Picker in Read
Am 08.10.2008 um 13:49 schrieb Tomeu Vizoso: > On Wed, Oct 8, 2008 at 1:30 PM, Bert Freudenberg > <[EMAIL PROTECTED]> wrote: >> Am 08.10.2008 um 12:03 schrieb Tomeu Vizoso: >> >>> On Wed, Oct 8, 2008 at 11:10 AM, Bert Freudenberg <[EMAIL PROTECTED] >>>> wrote: >>>> >>>> Am 08.10.2008 um 10:33 schrieb Morgan Collett: >>>> >>>>> I filed #8350 regarding adding the journal object picker to Read, >>>>> for >>>>> the case when it is launched from Home View without a document. >>>>> >>>>> There was a recent discussion on the library list about this, >>>>> since >>>>> the show_launcher setting isn't relevant any more - Read appears >>>>> in >>>>> Home View if you star it. (If Read is installed in the software >>>>> updater, it will be starred...) >>>>> >>>>> I have implemented this, and could release it for 8.2.1, but the >>>>> journal object picker doesn't currently have any filters for an >>>>> Activity to restrict the view to only relevant entries - so it >>>>> pops up >>>>> with the entire journal visible - images, Write entries, Browse >>>>> entries, etc where all we can handle in Read are relevant >>>>> downloaded >>>>> documents, and previous Read instances. >>>>> >>>>> Is this going to cause more problems than it's worth? >>>>> >>>>> I could make the object picker pop up again if the selected entry >>>>> failed to load, if that helps. >>>>> >>>>> An alternative to using the object picker is to have a string >>>>> break >>>>> and add a dialog that explains that you launched Read without a >>>>> document, and so it isn't useful, and make that stop Read when >>>>> acknowledged. >>>> >>>> >>>> Why not extend the object chooser to include a query parameter? >>> >>> I'm not 100% sure yet. How does the object chooser look when it is >>> prefiltered? Can the user undo the filter? Which properties can be >>> filtered? Any? Just the ones the user itself can? Can a free text >>> string be provided? >>> >>> If we could limit the preset filter to a list of mime types, I think >>> we would benefit from the simplicity. Can we do that? In which cases >>> is this not enough? >> >> >> I don't know - it just seems unwise to artificially limit a powerful >> API that is already exposed elsewhere, just because we cannot think >> of >> a use case right now. >> >> But I'm not too hung up on that one, a simple list of mime types is >> much better than no filtering, so go for it. >> >> How about allowing glob patterns in addition to concrete types? >> Though >> that might require extending the DS. > > The thing is that the D-Bus DS API is not certain to live much longer, > so I would prefer if the minimum expectations are set, so we can move > later to a better API with less problems for everyone. Well, the chooser is Journal API not DS API. And how would activities communicate with Sugar if not by D-Bus? - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Journal Object Picker in Read
Am 08.10.2008 um 12:03 schrieb Tomeu Vizoso: > On Wed, Oct 8, 2008 at 11:10 AM, Bert Freudenberg <[EMAIL PROTECTED] > > wrote: >> >> Am 08.10.2008 um 10:33 schrieb Morgan Collett: >> >>> I filed #8350 regarding adding the journal object picker to Read, >>> for >>> the case when it is launched from Home View without a document. >>> >>> There was a recent discussion on the library list about this, since >>> the show_launcher setting isn't relevant any more - Read appears in >>> Home View if you star it. (If Read is installed in the software >>> updater, it will be starred...) >>> >>> I have implemented this, and could release it for 8.2.1, but the >>> journal object picker doesn't currently have any filters for an >>> Activity to restrict the view to only relevant entries - so it >>> pops up >>> with the entire journal visible - images, Write entries, Browse >>> entries, etc where all we can handle in Read are relevant downloaded >>> documents, and previous Read instances. >>> >>> Is this going to cause more problems than it's worth? >>> >>> I could make the object picker pop up again if the selected entry >>> failed to load, if that helps. >>> >>> An alternative to using the object picker is to have a string break >>> and add a dialog that explains that you launched Read without a >>> document, and so it isn't useful, and make that stop Read when >>> acknowledged. >> >> >> Why not extend the object chooser to include a query parameter? > > I'm not 100% sure yet. How does the object chooser look when it is > prefiltered? Can the user undo the filter? Which properties can be > filtered? Any? Just the ones the user itself can? Can a free text > string be provided? > > If we could limit the preset filter to a list of mime types, I think > we would benefit from the simplicity. Can we do that? In which cases > is this not enough? I don't know - it just seems unwise to artificially limit a powerful API that is already exposed elsewhere, just because we cannot think of a use case right now. But I'm not too hung up on that one, a simple list of mime types is much better than no filtering, so go for it. How about allowing glob patterns in addition to concrete types? Though that might require extending the DS. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Journal Object Picker in Read
Am 08.10.2008 um 11:51 schrieb Morgan Collett: > On Wed, Oct 8, 2008 at 11:10, Bert Freudenberg > <[EMAIL PROTECTED]> wrote: >> >> Am 08.10.2008 um 10:33 schrieb Morgan Collett: >> >>> I filed #8350 regarding adding the journal object picker to Read, >>> for >>> the case when it is launched from Home View without a document. >>> >>> There was a recent discussion on the library list about this, since >>> the show_launcher setting isn't relevant any more - Read appears in >>> Home View if you star it. (If Read is installed in the software >>> updater, it will be starred...) >>> >>> I have implemented this, and could release it for 8.2.1, but the >>> journal object picker doesn't currently have any filters for an >>> Activity to restrict the view to only relevant entries - so it >>> pops up >>> with the entire journal visible - images, Write entries, Browse >>> entries, etc where all we can handle in Read are relevant downloaded >>> documents, and previous Read instances. >>> >>> Is this going to cause more problems than it's worth? >>> >>> I could make the object picker pop up again if the selected entry >>> failed to load, if that helps. >>> >>> An alternative to using the object picker is to have a string break >>> and add a dialog that explains that you launched Read without a >>> document, and so it isn't useful, and make that stop Read when >>> acknowledged. >> >> >> Why not extend the object chooser to include a query parameter? We >> discussed >> this a long time ago and it makes sense, it just has not bubbled to >> the top >> of the to-do list yet ... > > I'm looking into that, but it would be good to improve Read before > 9.1 lands. Adding the query should be low-risk if nothing else in the UI is touched, so might be appropriate for 8.2.1? Changing tomeu's patch in #3060 to support a full query seems rather trivial. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Journal Object Picker in Read
Am 08.10.2008 um 11:16 schrieb Simon Schampijer: > Bert Freudenberg wrote: >> Am 08.10.2008 um 10:33 schrieb Morgan Collett: >>> I filed #8350 regarding adding the journal object picker to Read, >>> for >>> the case when it is launched from Home View without a document. >>> >>> There was a recent discussion on the library list about this, since >>> the show_launcher setting isn't relevant any more - Read appears in >>> Home View if you star it. (If Read is installed in the software >>> updater, it will be starred...) >>> >>> I have implemented this, and could release it for 8.2.1, but the >>> journal object picker doesn't currently have any filters for an >>> Activity to restrict the view to only relevant entries - so it >>> pops up >>> with the entire journal visible - images, Write entries, Browse >>> entries, etc where all we can handle in Read are relevant downloaded >>> documents, and previous Read instances. >>> >>> Is this going to cause more problems than it's worth? >>> >>> I could make the object picker pop up again if the selected entry >>> failed to load, if that helps. >>> >>> An alternative to using the object picker is to have a string break >>> and add a dialog that explains that you launched Read without a >>> document, and so it isn't useful, and make that stop Read when >>> acknowledged. >> Why not extend the object chooser to include a query parameter? We >> discussed this a long time ago and it makes sense, it just has not >> bubbled to the top of the to-do list yet ... >> - Bert - > > http://sugarlabs.org/go/DevelopmentTeam/0.84/Ideas Also found the old ticket: http://dev.laptop.org/ticket/3060 - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Journal Object Picker in Read
Am 08.10.2008 um 10:33 schrieb Morgan Collett: > I filed #8350 regarding adding the journal object picker to Read, for > the case when it is launched from Home View without a document. > > There was a recent discussion on the library list about this, since > the show_launcher setting isn't relevant any more - Read appears in > Home View if you star it. (If Read is installed in the software > updater, it will be starred...) > > I have implemented this, and could release it for 8.2.1, but the > journal object picker doesn't currently have any filters for an > Activity to restrict the view to only relevant entries - so it pops up > with the entire journal visible - images, Write entries, Browse > entries, etc where all we can handle in Read are relevant downloaded > documents, and previous Read instances. > > Is this going to cause more problems than it's worth? > > I could make the object picker pop up again if the selected entry > failed to load, if that helps. > > An alternative to using the object picker is to have a string break > and add a dialog that explains that you launched Read without a > document, and so it isn't useful, and make that stop Read when > acknowledged. Why not extend the object chooser to include a query parameter? We discussed this a long time ago and it makes sense, it just has not bubbled to the top of the to-do list yet ... - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Question from Uruguay
Could someone respond to this: "por que nopuedo entrar activitie como estava antes" at http://wiki.laptop.org/go/Talk:Bert%27s_script I don't speak Spanish ... - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Image Viewer Activity
Am 29.09.2008 um 11:46 schrieb Sayamindu Dasgupta: > On Mon, Sep 29, 2008 at 11:57 PM, Gary C Martin > <[EMAIL PROTECTED]> wrote: >> On 29 Sep 2008, at 17:13, Sayamindu Dasgupta wrote: >> >>> Hello, >>> >>> I was a little annoyed with having to start up Browse to view >>> images, >>> and since I had done a small toy PyGTK based image viewer widget >>> sometime back, I decided to put that in an activity over the >>> weekend. >>> You can download it from >>> http://dev.laptop.org/~sayamindu/bundles/imageviewer/ >>> ImageViewer-1.xo >>> It can zoom and rotate images. However, it cannot put anything in >>> the >>> journal, since a workaround for #8155 would mean eating up a lot of >>> storage space (as I would have to create copies of the images for >>> each >>> journal entry). >>> A screenshot is at >>> http://dev.laptop.org/~sayamindu/Captura%20de%20pantalla_1.png >>> The code lives in Git: >>> http://dev.laptop.org/git?p=users/sayamindu/imageviewer-activity;a=tree >>> >>> Comments, patches and brickbats are welcome :-). >>> Thanks, >>> Sayamindu >> >> Hey, fantastic, thanks! :-) >> >> --Gary >> >> P.S. Any hints on changing the default activity that takes charge >> of a mime >> type? >> > > No clue on how to set the default activity associated with a mimetype > :-(. If anyone has any ideas, please let me know :-). /usr/share/sugar/data/mime.defaults - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Major differences between releases
I think it would be a good idea for everyone (activity authors in particular) to cross-check the changes in what packages are included in the new stable release, in particular what packages are *going away*: http://dev.laptop.org/~bert/update.1-8.2.html Also, is there any chance someone will take on http://dev.laptop.org/ticket/4695 (Document API changes between Ship.1 and Update.1 and 8.2) after the release before working on the next one? - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] G1G1 Pre-installed Activities Request for Help Testing
Am 25.09.2008 um 10:06 schrieb Sameer Verma: > On Thu, Sep 25, 2008 at 12:04 PM, Sameer Verma <[EMAIL PROTECTED]> > wrote: >> On Sun, Sep 21, 2008 at 1:12 PM, Sameer Verma <[EMAIL PROTECTED]> >> wrote: >>> >>> In an attempt to make the decision-making process more unbiased >>> (or at >>> least more multi-criteria) I've put up a basic spreadsheet for a >>> scoring matrix at >>> http://spreadsheets.google.com/ccc?key=p_Xhb6KcXLyEViA50CnCaDg&hl=en >>> >>> In the spreadsheet, there are three main components. Column B has >>> factors such as stability, performance, etc to assess against. I >>> just >>> made these up, but feel free to make your own. The weights (column >>> C) >>> essentially defines the importance of each factor as a percentage >>> of a >>> total of 100%. The rest of the columns are for each activity. Feel >>> free to add your own. Score them on a scale of 1 to 10. Each score >>> gets weighted and you'll see totals at the bottom. Sort for the >>> totals >>> in Descending order and skim off the top 10. >>> >>> There you have it. Multi-criteria decision-making made simple. >>> >>> Sameer >>> >> I've added a new set of factors to the spreadsheet which now reflects >> the list from >> http://wiki.laptop.org/go/Creating_an_activity#Include_your_Activity_in_the_core.3F >> >> This list is row 41 and below. >> >> Before I go on and add more to it, is anyone interested in building >> this further? >> > BTW, the spreadsheet is at > http://spreadsheets.google.com/ccc?key=p_Xhb6KcXLyEViA50CnCaDg&hl=en So by that metric, Terminal is the best activity. Huh? - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Composition -- we've been here before!
Am 24.09.2008 um 16:46 schrieb Michael Stone: > Folks, > > We've been over this ground before -- have any of the old bugs been > fixed? > [...] > http://dev.laptop.org/ticket/6759 At least this one has been fixed 4 months ago. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [RELEASE] Calculate 25
Am 24.09.2008 um 15:54 schrieb Gary C Martin: > Not sure why but for me SW update is not picking up v25 (I have v24 > installed). I checked the wiky Activities page but you seem to have > that set fine (SW update looks there by default). I'm wondering if > your update_url = http://dev.laptop.org/~rwh/calculate content is > working correctly. That page does not have the special markup required by the updater. This is explained here: http://wiki.laptop.org/go/Activity_microformat - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame gets in the way when alt-tabbing
Am 23.09.2008 um 06:21 schrieb Erik Garrison: > Both Joyride and 8.2 streams have composition enabled by default. > > You can test composition by running "xcompmgr -d :0.0" in the > terminal. It is available, but the window manager does not use it, afaik. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Keeping Trac(k)
Am 19.09.2008 um 19:07 schrieb Gary C Martin: > Hi Bert, > > On 19 Sep 2008, at 13:27, Bert Freudenberg wrote: > >> For keeping up with new Trac tickets I discovered this RSS feed: >> >> http://dev.laptop.org/timeline?ticket=on&max=50&daysback=7&format=rss >> >> ... which only has entries for opened and closed tickets. This is >> much >> more bearable than subscribing to the bug notify list. >> >> Even better would be if I could filter that by component :) > > I think you can, I just made up a quick track query and my browser > (Safari) indicates an RSS feed is available, can then subscribe. > Here's the URI it gave me for new+reopened and Action is test in > build: > > feed://dev.laptop.org/query?status=new&status=reopened&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&next_action=test+in+build&format=rss > This does not give me the tickets created or closed in the last 7 days. I want a filtered timeline: http://dev.laptop.org/timeline - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Keeping Trac(k)
For keeping up with new Trac tickets I discovered this RSS feed: http://dev.laptop.org/timeline?ticket=on&max=50&daysback=7&format=rss ... which only has entries for opened and closed tickets. This is much more bearable than subscribing to the bug notify list. Even better would be if I could filter that by component :) - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] G1G1v2 Activities
Am 19.09.2008 um 01:13 schrieb Douglas Bagnall: > Greg Smith wrote: > >> What do you think are the most important activities to include? > > If we're sticking to activities with valid activity.info files, then > (AFAICT) we're limited to: > > XaoS - org.codewiz.XaoS > Sokoban - de.hpi.swa.Sokoban > Pipes- de.hpi.swa.Pipes > Bounce - bounce > Chat - org.laptop.Chat > DrGeoII - org.ofset.DrGeoII > Breakout - de.hpi.swa.Breakout > Funtowers- de.hpi.swa.Funtowers > DiceWars - de.hpi.swa.DiceWars > X activity - org.laptop.wiki.XActivity > StackAttack - de.hpi.swa.StackAttack > Joke Machine - org.worldwideworkshop.JokeMachineActivity > Sokobaenle - de.hpi.swa.Sokobaenle > BlockAttack - de.hpi.swa.BlockAttack > Abalone - de.hpi.swa.Abalone > SameGame - de.hpi.swa.SameGame > > > Not that it really matters, of course. > > Most activities fail by having no bundle_id, and only 36/115 have > host_version. Hehe. Random useless fact: 68.75% of the activities on this list are Squeak-based ;) > Good on whoever does the swa.hpi.de games. Kudos to the student Squeak hackers at the University of Potsdam, Germany. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [RELEASE] etoys-3.0.2153
http://dev.laptop.org/pub/sugar/sources/etoys/etoys-3.0.2153.tar.gz * enable Pango for unknown locales (#8530) * fix composite character input (#8531) * fix camera not working in some locales (#8540) * releases sound device in WorldStethoscope (#8541) * preserve meta data in Journal (#8550) - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] G1G1v2 Activities
I noticed in the new help activity there is an activity sampler of 21 activities. Are these going to be shipped? - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [RELEASE] etoys 3.0.2147 / etoys-activity-93
http://dev.laptop.org/pub/sugar/sources/etoys-activity/etoys-activity-93.tar.gz * added license info to bundle http://dev.laptop.org/pub/sugar/sources/etoys/etoys-3.0.2147.tar.gz * update translation: ja * fix loading project authored in different locale (#8495) * fix opening text files from Journal (#8402) - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [RELEASE] etoys 3.0.2141 / etoys-activity-92
In the rush towards 8.2 I've been a bit lazy announcing new Etoys releases. But here goes: = Sources = http://dev.laptop.org/pub/sugar/sources/etoys/ http://dev.laptop.org/pub/sugar/sources/etoys-activity/ = Changes = etoys-3.0.2141 / etoys-activity-92 * Enable object chooser etoys-3.0.2139 / etoys-activity-91 * Updated translations: de * Fix saving projects with non-ascii names (#8212) * Fix buddy flap showing more buddies (#7749) etoys-3.0.2126-1 / etoys-activity-90 * Updated translations: de, ja * Support private sharing (#5280) * Do not save menu project (#8046) etoys-3.0.2121 / etoys-activity-89 * updated translations: de, mn (#7976) * Fix crash in Russian locale (#8193) * Fix logging errors (#6391) * Fix corrupted project names in Journal (#8199) * Fix Journal timestamps (#8176) * Automatically enable pango (#7610, #8163) * fix clipboard (#8199) * fix forward-direction and rotation-center halo issues (#8210) * various fixes (#7320, #7737, #8162, #8193, #8210) etoys-3.0.2100-1 / etoys-activity-88 * add translations ar, bg, fa_AF, ht, mn, mr, nl, ro, si, te, tr * update bn, el, en, es, fr, it, ko, ne, ps, pt, pt_BR, ru, sv, zh_TW * fix text input (#7737) * fix sharing error (#8129) * save timestamp in Journal (#8152) * preserve name set in Journal (#8087) * fix 'obtrudes' tile (#7931) * hide broken audio chat and screen sharing (#7745, #7746) = VM changes = For two bugs, Squeak VM changes were necessary: squeak-vm-3.10-3olpc10 * fix writing to stderr (#6391) squeak-vm-3.10-3olpc9 * respect the TZ variable used by Sugar (#8176) A huge THANKS to the developers, testers and translators! - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Reviews report
Am 10.09.2008 um 14:15 schrieb Release Team: > = Rejected requests = > > 8.2-757: Copy-to-clipboard broken in Journal > http://dev.laptop.org/ticket/8287 :( - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Some extra information for Etoys translation
IMHO the comments in the POT are not explicit enough for a translator to understand their "meta" nature. They should have examples. Also the phrase could be made to stand out better. Maybe a common prefix, and use all upper-case? "PO_LANGUAGE_NAME" might alert the translator better than "Language-Name" which looks like any regular phrase: #: TRANSLATORS: Put in the name of your language, NOT the translation of "language name". E.g. "Español" or "Русский". msgid "PO_LANGUAGE_NAME" And since Etoys does not use a single font like Scratch does, why do we try to mimic it? - Bert - Am 02.09.2008 um 02:02 schrieb Yoshiki Ohshima: > Thank you, Sayamindu, > > By the way, while trying to copy the "extra information" from > Scratch to Etoys, I found that some translators translated the > keyword, when they are supposed to provide the information. For > example, Linux-Font in French for Scratch is translated, > "Fonte-Linux", and "Language-Name" in Kreyol is "Lang-Non", Linux-Font > for Turkish is "linux yaz? tipi", etc. (I pasted the "Language-Name" > entry from Arabic, but not sure what it actually says.) I saw bunch > of language names in Scratch and all looked ok so I was assuming the > data on Pootle is ok, too... > > So, folk, please visit these entries and read the comments. Thank > you! > > -- Yoshiki > > At Sat, 30 Aug 2008 02:46:23 +0530, > Sayamindu Dasgupta wrote: >> >> On Thu, Aug 28, 2008 at 3:49 AM, Yoshiki Ohshima <[EMAIL PROTECTED]> >> wrote: >>> Hello, >>> >>> We've added some mechanism to Etoys so that you can (indirectly) >>> specify the rendering mechanism for text in Etoys. >>> >>> Soon an few entries will show up on the Pootle server, and one of >>> these is "Linux-Font". If you think your language should be >>> rendered >>> with Pango, specify the prefered font name as the translation. >>> Or, if >>> you think it is not necessary, leave it blank. >>> >>> The font name doesn't have to exact; as long as the entry is not >>> empty, the Etoys system asks Pango to render text. Likewise, please >>> provide the language name in the language for "Language-Name". It >>> will be displayed in the language chooser menu. >>> >>> The entries are the same as Scratch's; so I will copy-and-paste from >>> Scratch's to Etoys as a default. >>> >>> Sayamindu, could you run the script that push stuff from git to >>> Pootle, if the next 24 hour cycle is not too close? >>> >> >> >> Done. >> >> Thanks, >> Sayamindu >> >> >> -- >> Sayamindu Dasgupta >> [http://sayamindu.randomink.org/ramblings] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] A few questions.
Am 01.09.2008 um 11:54 schrieb Christopher Sawtell: > Greets, > > 1) Is this the correct list to ask simplistic questions? If not could > somebody please direct me to the correct list. Sure, if it is Sugar-related. The emulation disk image question would be better directed at the "devel" list. > 2) As I live in NZ a genuine hardware XO is utter vapour ware for me, > so I have to either use the sugar packages as published by the Ubuntu > folks, or to Install VirtualBox and run an image. The question is: > which road should I take? If you suggest the image in a VirtualBox > route, I would be grateful as to a suggestion as to which one, there > are _so_ many. I hope to run the XO apps. on a T41 ThinkPad. Developers can request an XO anywhere in the world: http://wiki.laptop.org/go/Developers_program > > 3) I am preparing a simplistic little "Counting Book for 21st Century > Children". So I need to know whether the standard XO file set has a > PDF reader as standard? Yes, see http://wiki.laptop.org/go/Read - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] PlayGo v2 and v3
Am 29.08.2008 um 10:00 schrieb Marco Pesenti Gritti: > Simon Schampijer wrote: >> Some breakfast notes > > Hmmm. First or second? :P This is getting out of hand. We are *not* hobbits. [reaches for the next roll and jelly] - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Landing patches about the network devices UI
Am 25.08.2008 um 17:56 schrieb Eben Eliason: > The fact that the mesh > devices were even added to the Neighborhood view was a last minute > hack, and we've been living with it (and confusing people with it) > ever since. Have to agree, this causes a lot of confusion. Since the UI is redesigned anyway the icon should move to its rightful place. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] joyride-weekly: joyride-2230
On 31.07.2008, at 17:59, Gary C Martin wrote: > On 31 Jul 2008, at 14:44, Bert Freudenberg wrote: > >> On 31.07.2008, at 15:14, Bert Freudenberg wrote: >> >>> On 31.07.2008, at 02:41, Michael Stone wrote: >>> >>>> Dear world, >>>> >>>> This week's 'please test this joyride' is joyride-2230. Test group >>>> release notes, care of Charlie, are available at >>>> >>>> http://wiki.laptop.org/go/ >>>> Test_Group_Release_Notes#Build_Joyride_2230 >>> >>> >>> olpc-update thinks that build does not exist. >> >> >> The error actually is "unexpected server greeting: fakeroot" > > Glad it's not just me then. I thought I had some random intermittent > network issue (for the last week or two) so had given up with olpc- > updates rsync attempts to the server. I defaulted back to manually > downloading the .toc and .usb files from the web server, sticking > them on a USB stick and using olpc-update --usb. SOmeone fixed it. I updated to 2233 just fine. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] joyride-weekly: joyride-2230
On 31.07.2008, at 15:14, Bert Freudenberg wrote: > On 31.07.2008, at 02:41, Michael Stone wrote: > >> Dear world, >> >> This week's 'please test this joyride' is joyride-2230. Test group >> release notes, care of Charlie, are available at >> >> http://wiki.laptop.org/go/ >> Test_Group_Release_Notes#Build_Joyride_2230 > > > olpc-update thinks that build does not exist. The error actually is "unexpected server greeting: fakeroot" - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] joyride-weekly: joyride-2230
On 31.07.2008, at 02:41, Michael Stone wrote: > Dear world, > > This week's 'please test this joyride' is joyride-2230. Test group > release notes, care of Charlie, are available at > > http://wiki.laptop.org/go/ > Test_Group_Release_Notes#Build_Joyride_2230 olpc-update thinks that build does not exist. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Presence Participant ID
Hi, I just noticed the addition of this function to the PS API: • SearchActivitiesByParticipants(au) → o • Search for activities having the given participants. • Returns: the view representing the result of the search. What participant id does this take? Presence "participants" are buddies, so I would have expected this function to take an 'ao' argument. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Congratulations! but Sugar sucks
Am 24.07.2008 um 17:53 schrieb Benjamin M. Schwartz: > Bert Freudenberg wrote: > | Am 24.07.2008 um 14:25 schrieb Benjamin M. Schwartz: > | > |> 1. The datastore > |> 2. OS Updates > |> 3. File Sharing > |> 4. Activity Modification > |> 5. Bitfrost > |> 6. Power management > | > | Note that half of these items have nothing to do with Sugar, oo the > | subject line is a bit misleading. > > Every one of them requires work on the Linux-based software stack that > runs on the XO. The name of that stack is Sugar, as far as I'm aware. > Perhaps a breakdown would be helpful: > > 1. The datastore: Glucose > 2. OS Updates: Ribose. (Ribose is all the low-level software that > keeps > Sugar running on the XO) > 3. File Sharing: Glucose > 4. Activity Modification: Glucose and Fructose. > 5. Bitfrost: Glucose and Ribose. > 6. Power management: Glucose, Ribose, and EC. I don't think that taxonomy actually has caught on. Commonly, only the "fructose" and "glucose" layers are referred to as "Sugar" (as for example discussed on the Sugar list) - basically, the UI and parts it directly depends on (datastore, presence). This is the stuff most directly impacting the learning experience, whereas bitfrost, power management, and OS updates are both of more general use (e.g., I'd love to see bitfrost-like security in my desktop, too) and not directly visible to the learner. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Congratulations! but Sugar sucks
Am 24.07.2008 um 14:25 schrieb Benjamin M. Schwartz: > 1. The datastore > 2. OS Updates > 3. File Sharing > 4. Activity Modification > 5. Bitfrost > 6. Power management Note that half of these items have nothing to do with Sugar, oo the subject line is a bit misleading. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] RTL blocker for 8.2.0?
Am 24.07.2008 um 14:55 schrieb Khaled Hosny: > On Thu, Jul 24, 2008 at 12:55:27PM -0400, Greg Smith wrote: >> Hi Guys, >> >> RTL is a blocker and it should be all RTL issues unless we can show >> that >> they are cosmetic or there is an acceptable work around. >> >> The reason they are show stoppers is that we have major Arabic >> deployments planned for this fall and winter (northern hemisphere). >> >> I believe these are regression bugs in that RTL works correctly >> (better?) in previous releases. > > AFAIK, most RTL bugs are there from the start. > >> What do we need to do to get some people with knowledge of "bidi >> scripts" to help? > > I'm interested in BiDi and RTL issue (in fact I reported most of the > RTL > bugs). I'll soon install a fresh joyride build and see what is still > missing for proper RTL support. FWIW I don't think Etoys can be made to work correctly in RTL any time soon. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Textbook (was Re: [OLPC-Games] Physics -- Newtonian, mechanics.. for kids!)
Am 24.07.2008 um 00:19 schrieb Yoshiki Ohshima: > I don't want sound to be a jerk..., but a game like Asteroids is so > right on the sweet spot of Etoys (take a look at the existing Lunar > Lander, and think about extending it with better controls and > rotation). Actually, I found it surprisingly hard to do ... - Bert - > And, the biggest advantage of that route I think is all scripts can > be written by kids and they can experiment different scripts and > parameters. That would be more interesting on educational side. > > (Just for the record that I read these emais, albeit slowly^^;) And > thank you Edward again for thinking about the contents aspect of the > project. > > -- Yoshiki ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Joyride 2201 blocker
Am 23.07.2008 um 20:28 schrieb Daniel Drake: > On Wed, 2008-07-23 at 19:20 -0400, Mikus Grinbergs wrote: >> I do most of my work with CLI from the Terminal. >> >> On my XO with Joyride 2201 there is no "bash history" accessible in >> Terminal -- hitting up-arrow at the prompt does NOT call up what had >> been previously entered at the prompt. ["bash history" is >> accessible from the text console (alt-ctl-F1).] > > Please file a ticket, and also let us know which joyride version this > did work with (if known). I filed http://dev.laptop.org/ticket/7613 earlier today before I noticed that many other short cuts are broken, too - frame key, journal key, or the cursor keys as you found. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Autosave in 8.2.0?
Am 20.07.2008 um 08:59 schrieb Marco Pesenti Gritti: > On Sun, Jul 20, 2008 at 5:44 PM, Bert Freudenberg <[EMAIL PROTECTED] > > wrote: >> Thanks for not answering, > > Hmm? Both Tomeu and me answered. > > http://lists.laptop.org/pipermail/devel/2008-July/016914.html > http://lists.laptop.org/pipermail/devel/2008-July/016951.html I see. Thanks - I have to check my email setup :/ >> and not updating the API doc, > > The time I can devote to OLPC is *very* limited these days and I had > no time until today to even check this API was working properly... I > just finished up the python Activity bits and I have a patch up for > review. I will try to update the doc on monday. > >> and me having >> to dig through Sugar patches to find out how this works. >> >> I updated the doc: >> http://wiki.laptop.org/go/Low-level_Activity_API#D-Bus_Methods >> === >> org.laptop.Activity.SyncData() >> Called when the laptop is about to shutdown, reboot, or >> suspend. The >> activity must save its state in the datastore. >> === >> Apparently this does not send a reason for having to sync - IMHO >> suspend is not as severe a reason as impending shutdown/reboot so an >> activity might want to choose to not save on suspend if suspends are >> as frequent as we anticipate. > > This code never went in actually... See the mails I referenced. Okay. Thanks and apologies. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Autosave in 8.2.0?
Am 20.07.2008 um 12:27 schrieb Tomeu Vizoso: > On Sun, Jul 20, 2008 at 5:44 PM, Bert Freudenberg <[EMAIL PROTECTED] > > wrote: >> Am 17.07.2008 um 07:37 schrieb Bert Freudenberg: >> >>> Am 17.07.2008 um 00:10 schrieb Tomeu Vizoso: >>> >>>> Marco has added a session manager to Sugar (in 8.2.0) that takes >>>> care >>>> of telling activities to save their work because the system is >>>> being >>>> shut down. Haven't verified if this is complete and working. Have >>>> you, >>>> Marco? If so, this would also take care of the case where kids shut >>>> down before closing all running activities first. >>> >>> >>> How does this work from an activity's pov? >>> >>> - Bert - >> >> >> Thanks for not answering, and not updating the API doc, and me having >> to dig through Sugar patches to find out how this works. > > Bert, you should know better than others how things are here. We > cannot manage to do the things we know that must be done, much less we > can do those properly. If I was in any regular job, I would limit > myself to do what I can, and do it right. Here we just cannot behave > like that. > > You are right to be frustrated by this situation, but please don't ask > us to do more than what is in our hands. If you know anyone who would > like to join us in this craziness, please point them to > http://www.laptop.org/en/jobs.shtml . I apologize, I was particularly frustrated when I sent this. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Design Question
Am 20.07.2008 um 14:14 schrieb Alexander Ortner: > +1 for the ring > > > (i am new to open source, so please be patient with me) > > i know this question doesn't really belong here, but: why was the > sugar UI changed? can i find a discussion about this anywhere? the > new version lost the frame, didn't it? at least it'S not there in my > sugar jhbuild env. > The former Alt short cuts are Alt-Shift now. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Autosave in 8.2.0?
Am 17.07.2008 um 07:37 schrieb Bert Freudenberg: > Am 17.07.2008 um 00:10 schrieb Tomeu Vizoso: > >> Marco has added a session manager to Sugar (in 8.2.0) that takes care >> of telling activities to save their work because the system is being >> shut down. Haven't verified if this is complete and working. Have >> you, >> Marco? If so, this would also take care of the case where kids shut >> down before closing all running activities first. > > > How does this work from an activity's pov? > > - Bert - Thanks for not answering, and not updating the API doc, and me having to dig through Sugar patches to find out how this works. I updated the doc: http://wiki.laptop.org/go/Low-level_Activity_API#D-Bus_Methods === org.laptop.Activity.SyncData() Called when the laptop is about to shutdown, reboot, or suspend. The activity must save its state in the datastore. === Apparently this does not send a reason for having to sync - IMHO suspend is not as severe a reason as impending shutdown/reboot so an activity might want to choose to not save on suspend if suspends are as frequent as we anticipate. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] OLPC/Sugar related MIME Types...
Am 13.07.2008 um 20:39 schrieb Martin Langhoff: > I am going to add some MIME types for Apache on the XO > > - application/vnd.olpc-sugar xo > - application/vnd.olpc-content xol > - application/vnd.olpc-journal-entry xoj > > The above list comes from a bit of Googling about. Are there any other > mime types that we care about? I think the Squeak mimetypes (used by the Etoys activity) are not in the default Apache mime types: - application/x-squeak-project pr - application/x-squeak-source sts - application/x-squeak-object sqo - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Presence Service D-Bus API
Am 15.07.2008 um 00:01 schrieb Guillaume Desmottes: > Le lundi 14 juillet 2008 à 21:54 -0700, Bert Freudenberg a écrit : >> Am 14.07.2008 um 05:48 schrieb WikiAdmin: >> >>> anonymous user 91.179.26.46 edited Presence Service D-Bus API >>> http://wiki.laptop.org/index.php?title=Presence_Service_D-Bus_API&diff=0&oldid=137835 >> >> >> This adds the GetBuddyByTelepathyHandle() and ListChannels() methods. >> Should we document the PS version of when this was introduced? > > I am this anonymous user. :) > > GetBuddyByTelepathyHandle() was in PS since age but was forgotten on > the > wiki, so I added it. > > ListChannels() was recently added (PS 0.81.3), see #4757 for details. Okay, I added this to the documentation: "added in PS 0.81.3 (joyride-2128, 8.2-3)" - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Presence Service D-Bus API
Am 14.07.2008 um 05:48 schrieb WikiAdmin: > anonymous user 91.179.26.46 edited Presence Service D-Bus API > http://wiki.laptop.org/index.php?title=Presence_Service_D-Bus_API&diff=0&oldid=137835 This adds the GetBuddyByTelepathyHandle() and ListChannels() methods. Should we document the PS version of when this was introduced? - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Easiest way to run the latest activities
Am 11.07.2008 um 12:20 schrieb Simon Schampijer: > Morgan Collett wrote: >> On Thu, Jul 10, 2008 at 11:35, Bert Freudenberg >> <[EMAIL PROTECTED]> wrote: >>> Am 10.07.2008 um 10:44 schrieb Morgan Collett: >>> >>>> On Wed, Jul 9, 2008 at 21:31, Bert Freudenberg <[EMAIL PROTECTED] >>>> > >>>> wrote: >>>>> Am 09.07.2008 um 20:07 schrieb Sayamindu Dasgupta: >>>>> >>>>>> On Wed, Jul 9, 2008 at 11:12 PM, Daniel Drake <[EMAIL PROTECTED]> >>>>>> wrote: >>>>>>> On Wed, 2008-07-09 at 23:11 +0530, Sayamindu Dasgupta wrote: >>>>>>>> The easiest way, perhaps, to run the bleeding edge version of >>>>>>>> Sugar on >>>>>>>> an XO is to run the latest joyride. Is there a similar way to >>>>>>>> run >>>>>>>> the >>>>>>>> latest activities on an XO ? >>>>>>> I use: >>>>>>> http://dev.laptop.org/~bert/joyride-activities.py >>>>>>> >>>>>>> see http://wiki.laptop.org/go/Bert%27s_script >>>>>>> >>>>>> Hmm.. for some activities >>>>>> http://dev.laptop.org/~erikos/sucrose-activities.py seem to >>>>>> provide >>>>>> more recent stuff. >>>>> Really? That would mean the latest Sugar release is not in >>>>> Joyride, >>>>> which would be a problem. >>>> Bert's joyride-activities script seems to pull from >>>> http://xs-dev.laptop.org/~cscott/repos/joyride/, which is very >>>> out of >>>> date. For example, it has Chat-37 as the latest, but Chat-42 has >>>> been >>>> released. >>>> >>>> How do we get activity updates in there? >>> >>> By the normal Joyride procedure (put the .xo into your ~/ >>> public_rpms): >>> >>> http://wiki.laptop.org/go/Build_system#Instructions_for_Use >> Ah, since the activities were removed from the build images I stopped >> doing that. I'll do that again. >> Morgan > > Yeah until we have another way to update the activities I think the > best is to update by the normal joyride procedure. To get a full > list of the latest activities and not only the sucrose ones. > > I will do the ones I maintain now as well and encourage you to do so > as well unless someone has a better idea. > > Best, > Simon Heh, I just kept doing as part of my regular release procedure ;) - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Etoys team visits Cambridge
Hi folks, many of the VPRI developers are attending the Scratch conference at MIT. We'll fly in a day early so that we would have some time on Wed. the 23rd to talk about issues, future plans, or whatever else comes up :) We're leaving Monday night so I hope there will be even more opportunities to catch up. Please contact me if you are interested in seeing us. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] (another) WebKit port of Browse
Am 08.07.2008 um 06:35 schrieb Mikus Grinbergs: > A reference was made to Gears: >> My point was exactly that it is a plugin. >> There are other plugins that are educationally useful. > > Security. I believe that 'Browse' is restricted as to how much it > is allowed to modify the operating system itself. Such restrictions > would apply to plugins as well. That concept NEEDS to be enforced. It is. > [War story: When plugins first became available for Netscape, I > installed one. But Netscape started behaving differently from how I > had thought I had set it up. I investigated, and found out that > "under the covers" the plugin had CHANGED (without telling me) some > Netscape settings to the way *it* wanted them. Got rid of it fast.] > > My point is that a 'plugin' is typically a "binary blob" -- the > person installing it on his computer has NO IDEA as to what that > plugin might surreptitiously be doing "under the covers". And with Bitfrost the user does not *have to have an idea*. A browser plugin can *only* do what the browse activity can do. Nothing more - which is in stark contrast to what a plugin on a regular machine can do (namely, everything the user can do). - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [OT] Re: Home View appearance
Am 08.07.2008 um 09:37 schrieb NoiseEHC: > http://www.thewebsiteisdown.com/ Hah! Must. Stop. Laughing. It. Hurts. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] etoys-3.0.2050 / etoys-activity-84
Getting closer: http://dev.laptop.org/pub/sugar/sources/etoys/etoys-3.0.2050.tar.gz http://dev.laptop.org/pub/sugar/sources/etoys-activity/etoys-activity-84.tar.gz ... or if you prefer: http://etoys.laptop.org/rpms/etoys-3.0.2050-1.noarch.rpm http://etoys.laptop.org/rpms/Etoys-84.xo NEWS * Pango fixes * updated translations: ja, de * collab refactoring in prep of tubes support * remove pre-update.1 support * ETOYS_DEBUG env var controls logging * minor fixes Brought to you by the VPRI team and Etoys community. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [SURVEY] builders, how do you build? what do you build?
Am 27.06.2008 um 23:23 schrieb Erik Garrison: > Developers, specifically those running build systems, > > Many of us are confused about the software flows inherent in the daily > build processes which are occuring at OLPC. I would like to conduct a > simple survey of all people building software for OLPC so that all > of us > can better understand the sources of the software running on the XO > and > XS without individually hassling the responsible parties every time we > have generic questions about their build processes. > > Builders, please describe your local build network: > > 0) Who are you and who do you directly work for? Bert Freudenberg, under contract with Viewpoints Research Institute (VPRI). I usually build the rpms. Yoshiki Ohshima and Takashi Yamamiya (both employed by VPRI) do when I am unavailable. > 1) What do you build? etoys rpm, squeak-vm rpm, Etoys xo bundle > 2) Where does it come from? / Who directly provides you with source > code? Source comes directly from VPRI. Developers there are Yoshiki Ohshima, Takashi Yamamiya, Scott Wallace, Ted Kaehler, Ian Piumarta, and y.t., directed by Alan Kay and Kim Rose. There are many more contributors from the Etoys and Squeak community, contributions are selectively pulled by the VPRI team. > 3) Where does the output of your build process go? / Who handles the > immediate output of your builds? rpms are pulled into the build from ~bert/public_rpms/joyride on dev.laptop.org by way of being uploaded to http://tinlizzie.org/olpc/sugar/rpm/ (a VPRI-operated server) and mirrored to http://etoys.laptop.org/rpms/ (one can also "yum install" from the latter) > 4) Where specifically is it built? (I want server names and/or > descriptions, where security is a concern please share them with me > privately.) My personal machine running a virtual machine with Fedora-7. > 5) What build systems do you use to build software? Please briefly > describe their operation or provide a link to documentation or source > code which does. http://wiki.laptop.org/go/Etoys_RPM_and_XO_bundle Note that this describes the current build process, there might be changes in the future. For example, etoys is also made available via sugar, and there was talk to get squeak and etoys into Fedora. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Add an option for choosing the layout in the favorites view.
On 21.06.2008, at 10:25, Marco Pesenti Gritti wrote: > On Sat, Jun 21, 2008 at 3:54 AM, Michael Stone <[EMAIL PROTECTED]> > wrote: >> On Fri, Jun 20, 2008 at 06:27:33PM +0200, Marco Pesenti Gritti wrote: >>> On Fri, Jun 20, 2008 at 6:24 PM, Tomeu Vizoso >>> <[EMAIL PROTECTED]> wrote: On Fri, Jun 20, 2008 at 6:08 PM, Walter Bender <[EMAIL PROTECTED] > wrote: > Is this done in a way such that it can be set by the > customization key > process? I can imagine that many groups will prefer the ring to > random > and want to make it an installation default. Not right now, but would be quite easy to add an option to the control panel and let customization keys change the stored preference. >>> >>> Even if not exposed in the cp UI we should at least have an hidden >>> preference. >>> We have no way right to customize sugar profiles but we should >>> have one. >>> >>> Marco >> >> I'm interested by the (implicit) idea that (all?) settings modifiable >> through the control panel should also be customizable. However, as I >> pointed out not long ago, some care needs to be taken to restrict the >> ability of the customization process to violate our security >> principles. >> >> As a strawman, how about using a convention or technology similar to >> >> http://thedjbway.org/daemontools/envdir.html >> >> to record the key-value settings that make up the bulk of the >> 'customizable' features? > > I'd rather use GConf which is what all the software we depend on uses > and understand. I'd rather not tie Sugar too closely to Gnome. I like Michael's strawman. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Localization] Kreyòl Localization
On 20.06.2008, at 19:07, Edward Cherlin wrote: > Etoys on the XO Anyone translating Etoys should subscribe to the Etoys list. http://lists.laptop.org/listinfo/etoys Etoys is more complex than all the other activities combined, and we are still working on improving the situation for translators (see the past discussions). - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] etoys-3.0.2029 / etoys-activity-83
Fresh from the press: http://dev.laptop.org/pub/sugar/sources/etoys/etoys-3.0.2029.tar.gz http://dev.laptop.org/pub/sugar/sources/etoys-activity/etoys-activity-83.tar.gz bundled: http://etoys.laptop.org/rpms/etoys-3.0.2007-1.noarch.rpm http://etoys.laptop.org/rpms/Etoys-83.xo NEWS * Pango fixes (tested with Nepalese) * new DBus bindings * updated QuickGuides * a few more strings made translatable The one still not ready feature is tubes support, it should land in a few days. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Home Design: Free Layout View
On 12.06.2008, at 21:08, Eben Eliason wrote: > Please observe the new design mockups on the wiki at > http://wiki.laptop.org/go/Designs/Activity_Management for further > details. As code freeze is rapidly approaching and these changes are > slated for the August release aside the rest of the redesign, your > feedback is greatly appreciated. Thanks! Hehe. Back to the desktop ;) But it is a much better use of space, so no disagreement here. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Journal able to use "open with" for activity bundles
On 11.06.2008, at 02:34, Eben Eliason wrote: > I vote for: > - > Resume > - > Resume in > > - > > ...for instances, and... > > - > Start > - > Open in> > - > > The submenu can then contain: > > - > Paint (default) > - > Other 1 > Other 2 > ... > - > > Another option, assuming we have (or gain) the ability to apply labels > to menu dividers, is to add a "resume with" or "open with" label to > the divider, and then simply group the available activities below > that. (This amounts to what we have now, but with the added > indication that the action taken with respect to the activities in the > list is eg. "resume with". I'm late to this thread so forgive me if I missed some semantic discussion, but ... Isn't "resume with" an oxymoron? "Resuming" an activity means we continue to do what we were doing. Instances of activities are the verbs of our interface language, and documents/people/other objects are the nouns. Using a different activity to continue to work on an object cannot be called "resuming" because it is a different verb even though the noun stays the same. It doesn't even work grammatically, "resume with " is not proper English, is it? Ideally we'd have actual verbs in the menu, which would make helpers like "start", "open", "resume" unnecessary. Or would this be taking the metaphor too far? - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame activation
On 10.06.2008, at 12:15, Tomeu Vizoso wrote: > Hi, > > do we have any feedback regarding frame activation and the new control > panel option? > > Is it ok to ship with hot corners on by default and let the users > change it if they wish? As much as I hate the mouse activation, I still think this is a sensible default. On the XO we have a Frame key, but on other hw discovering the frame could be a lot harder. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Idea: Aerial photographs of all villages where XO's are deployed
On 06.06.2008, at 18:18, Urko Fernandez wrote: >> can the XO can access Google maps? >> > I don't have an XO-1, but Google Maps works in the browse activity > under sugar-jhbuild. Works fine on the XO too. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Devel-announce] Terminal-12 is out
On 05.06.2008, at 19:54, Sayamindu Dasgupta wrote: > A new version (version 12) of Terminal Activity has been released. > > * #5520: Make the activity exit when the user exits the shell. > (sayamindu) Yay! :) - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] etoys-3.0.2007 / etoys-activity-82
Freshly released: http://dev.laptop.org/pub/sugar/sources/etoys/etoys-3.0.2007.tar.gz http://dev.laptop.org/pub/sugar/sources/etoys-activity/etoys-activity-82.tar.gz or, if you prefer ready-to-use bundles: http://etoys.laptop.org/rpms/etoys-3.0.2007-1.noarch.rpm http://etoys.laptop.org/rpms/Etoys-82.xo NEWS * more translatable phrases * minor tile fixes - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Jun 5, Sucrose 0.81.2 Tarballs Due
On 04.06.2008, at 17:52, Marco Pesenti Gritti wrote: > Hello! > > Here are the modules which are included in the release: > > Glucose: http://wiki.sugarlabs.org/go/Roadmap#Glucose_Modules > Fructose: http://wiki.sugarlabs.org/go/Roadmap#Fructose_Modules This is now http://wiki.sugarlabs.org/go/ReleaseTeam/Roadmap#Glucose_Modules http://wiki.sugarlabs.org/go/ReleaseTeam/Roadmap#Fructose_Modules > Please provide source code tarballs and announce them as explained > here: > > http://wiki.sugarlabs.org/go/Release#Module_release http://wiki.sugarlabs.org/go/ReleaseTeam#Module_release - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Missing 0.81.1 tarballs
I did not see a Makefile in the other activity tarballs I looked at ... Do you have an example? Where should it install? - Bert - On 23.05.2008, at 18:47, Marco Pesenti Gritti wrote: > Not urgent, but it would be nice to have a makefile in etoys-activity > to install it... > > Marco > > On Thu, May 22, 2008 at 6:14 PM, Bert Freudenberg <[EMAIL PROTECTED] > > wrote: >> >> On 22.05.2008, at 13:37, Marco Pesenti Gritti wrote: >> >>> See: >>> >>> http://wiki.sugarlabs.org/go/Release#Module_release >>> >>> Please release your modules as soon as possible. We are missing: >>> >>> read-activity >>> write-activity >>> tamtam-activity >>> pippy-activity >>> etoys-activity >> >> >> I uploaded tarballs for etoys and etoys-activity: >> >> http://dev.laptop.org/pub/sugar/sources/ >> >> - Bert - >> >> >> ___ >> 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] Help regarding Sugar on Ubuntu
The Etoys activity does that already. I'm not familiar with the Xephyr code base but hopefully it would not be too hard to add scaling. Another option is running Sugar in x11vnc instead of Xephyr and using a scaling VNC viewer. - Bert - On 23.05.2008, at 17:07, Eben Eliason wrote: > For what its worth (and I know this probably isn't easy, or we'd > already have support for it), what we really need for useful > testing/developing is a way to scale the output to the window as a > post-draw operation. That is, render everything as though it were a > 1200x900 screen, and scale to the window size (assuming 4:3). > sugar-emulator -x is quite nice, but it requires a large monitor to > use effectively. > > Naturally, this is somewhat the opposite of what we want to happen > when running in fullscreen on screens of various resolutions, in which > the subcomponents within the UI should independently scale or not, as > appropriate. There's a fair amount of work to be done there as well, > to make sizes and proportions appear correctly no matter the > resolution. It would be great if we could find someone in the > community interested in attacking this type of cleanup throughout the > UI, since we're clearly biased towards the XO (and need to be based on > our resources). > > - Eben > > > On Fri, May 23, 2008 at 9:36 AM, Waqas Toor > <[EMAIL PROTECTED]> wrote: >> Hello Marco, >> >> On Fri, May 23, 2008 at 1:45 PM, Marco Pesenti Gritti >> <[EMAIL PROTECTED]> wrote: >>> sugar.gtkrc and sugar/graphics/style.py >>> >> sugar.gtkrc wont work, sugar-xo.gtkrc has the effects >> and I will check style.py also >> >> Thanks >> >>> Marco >>> >>> On Fri, May 23, 2008 at 12:03 AM, Waqas Toor <[EMAIL PROTECTED] >>> > wrote: Hello All, I have changed fullscreen mode of Xephyr into 800x600, but now how to change the size of frames and icons ? I have tried changing sugar-xo.gtkrc file but nothing happens, any clues? 2ndly, the activities inside this small screen do not show properly i.e they remain the actual full screen size how to make this environment fit into the size of 800x600 Regards -- Waqas Toor member of OLPC Pakistan Team member of Ubuntu Pakistan Team ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar >>> >> >> >> >> -- >> Waqas Toor >> member of OLPC Pakistan Team >> member of Ubuntu Pakistan Team >> ___ >> Sugar mailing list >> Sugar@lists.laptop.org >> http://lists.laptop.org/listinfo/sugar >> > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Core Sugar framework now in Debian Testing!
On 23.05.2008, at 14:01, Morgan Collett wrote: > On Fri, May 23, 2008 at 12:32 PM, Jonas Smedegaard <[EMAIL PROTECTED]> > wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On Thu, May 22, 2008 at 04:39:19PM -0600, Debian testing watch wrote: >>> FYI: The status of the sugar source package >>> in Debian's testing distribution has changed. >>> >>> Previous version: (not in testing) >>> Current version: 0.79.4-2 >> >> All core Sugar packages are now in Debian Testing! >> >> With "core" I mean all Sugar software except activities themselves. >> >> (upstream have no clear definition of "core" - it seems they agree >> that >> Sugar should always include some activities, but does not agree on >> some >> common default "core" set of activities...) > > You must have missed the recent activity on the sugar list... Sugar as > an upstream project now has designated "demo" activities which distros > can choose to bundle. > > http://wiki.sugarlabs.org/go/Taxonomy gives names to different > components in the stack which as been known in whole or part as > "Sugar". Fructose now refers to the activities bundled with Sugar. > > http://wiki.sugarlabs.org/go/Modules lists Sugar components, > dependencies and these activities. > > http://wiki.sugarlabs.org/go/Release shows how releases are done of > the Sugar (I mean, Glucose) modules and Fructose activities. > > http://wiki.sugarlabs.org/go/Roadmap shows the planned release > strategy for the next few months. > >> We need more activities packaged! Please speak up if you are >> interested >> in helping out. > > I haven't done packaging before - it's always been on my TODO list to > learn. I run Ubuntu, but I'm interested in getting involved (with the > view to making sure Ubuntu releases with the appropriate versions of > the various components). Please remind me where your documentation is, > and what list to join. I think we should have a page on the sugarlabs > wiki tracking each distro's packaging. > > I helped test Jani's Ubuntu packages before the hardy release. > Unfortunately I only realised days before the release that the sugar > versions included were not the most appropriate versions: taken from a > different branch to the stable release. While it looks the same as the > stable release (0.75.x in build 703) there are differences, which may > mean bugs in the Ubuntu version (0.79.0) which were fixed in the > 0.75.x series after that release. So I really want to see distro > releases (especially Ubuntu) having the most appropriate versions of > the Sugar stack. > > We are not OpenSSL, but... I do think it is important that we maintain > good communication with distro packagers to assist in this. Etoys is missing, and is about to be rejected by Debian's ftp masters. This time not because of the license (which finally was solved) but because of Squeak's use of object memory snapshots (a.k.a. images). See below. - Bert - Begin forwarded message: > From: Bert Freudenberg <[EMAIL PROTECTED]> > Date: 23. Mai 2008 11:56:38 MESZ > To: [EMAIL PROTECTED] > Cc: "José L. Redrejo Rodríguez" <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: etoys_3.0.1916+svn132-1_amd64.changes (almost) REJECTED > > On 21.05.2008, at 23:06, Thomas Viehmann wrote: >> Hi José, Bert, Holger, >> >> this is, unfortunately, the REJECT of etoys. >> First of all, thanks Bert, Holger, José for the discussion of some of >> the concepts. However, I am afraid that there are some fundamental >> concerns that have not been eliminated (yet). As such I would like to >> invite you to start a discussion on the packaging of squeak session >> images on [EMAIL PROTECTED] Feel free to forward this >> mail if you consider it useful as a starting point. >> >> It seems to me that the method of distributing VM sessions in .image >> files as the preferred form of modification does not match too well >> with Debian practices of compiling packages from source and having >> easy access to the differences between various versions of a package. >> >> So as far as I understand it it seems like a typical squeak image >> cannot be bootstrapped[1] from (textual) source and that the typical >> mode of operation is to modify some known image and distribute the >> result. As such, the preferred form of modification is indeed the >> image file. >> >> This, in my opinion, raises at least the following questions that >> seem >> fundamental to me: >>
