Re: [sugar] Any idea why ./setup fix_manifest should auto delete my locale directory?
On Fri, Sep 19, 2008 at 3:23 AM, Gary C Martin [EMAIL PROTECTED] wrote: Any idea why running ./setup fix_manifest should be auto deleting my locale directory? Seems a little mean spirited of it - doesn't warn me or anything. locale should always be build automatically when using bundlebuilder. Are you making modifications to it? Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] G1G1v2 Activities
On Fri, Sep 19, 2008 at 4:01 AM, Gary C Martin [EMAIL PROTECTED] wrote: I'm showing my age here, but is bundle_id a replacement for service_name? Seem to be identical. Yeah, service_name is deprecated but they are basically the same thing. bundlebuilder should probably warn about it. Marco ___ 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
Re: [sugar] G1G1v2 Activities
On 19 Sep 2008, at 09:15, Marco Pesenti Gritti wrote: On Fri, Sep 19, 2008 at 4:01 AM, Gary C Martin [EMAIL PROTECTED] wrote: I'm showing my age here, but is bundle_id a replacement for service_name? Seem to be identical. Yeah, service_name is deprecated but they are basically the same thing. bundlebuilder should probably warn about it. Marco So I should keep both in my activity.info for backwards compatibility with early builds? Thanks for all the responses, I obviously haven't quite understood the way string translations** are designed for yet, will go have another read and poke about. **basically trying to absorb the Moon.activity/locale/es/ activity.linfo that was added to Moon-4 for the Peru deployment bundle. I'm now assuming this file is being generated (or prevented from auto deletion) by something in po which I'm missed. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] G1G1v2 Activities
On Fri, Sep 19, 2008 at 1:10 PM, Gary C Martin [EMAIL PROTECTED] wrote: So I should keep both in my activity.info for backwards compatibility with early builds? This was change *long* time ago. I suspect your activity would not work for other reasons if run with such an old Sugar. Marco ___ 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=onmax=50daysback=7format=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
[sugar] Reviews report
= Approved requests = Alternate home layouts; fixed ring scaling; better modularization of layouts http://dev.laptop.org/ticket/7685 Switching between zoom levels seem to leak http://dev.laptop.org/ticket/8485 Indicate connected AP in Neighborhood view. http://dev.laptop.org/ticket/8554 Can't see all items in the Control Panel http://dev.laptop.org/ticket/8487 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Keeping Trac(k)
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=onmax=50daysback=7format=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=newstatus=reopenedcol=idcol=summarycol=statuscol=typecol=prioritycol=milestonecol=componentnext_action=test+in+buildformat=rss --Gary ___ 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=onmax=50daysback=7format=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=newstatus=reopenedcol=idcol=summarycol=statuscol=typecol=prioritycol=milestonecol=componentnext_action=test+in+buildformat=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
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 12:13 AM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: Let's keep thinking about this. For example, I wonder what Metacity does to a window that is both _NET_WM_STATE_FULLSCREEN and _NET_WM_STATE_BELOW? Does it stack it below the Frame, if the Frame is _NET_WM_TYPE_DOCK and _NET_WM_STATE_ABOVE? If not, could we convince the Metacity developers that this is a good idea? I just thought of a worst problem with the FULLSCREEN approach. FULLSCREEN windows are always on the top of NORMAL windows. I think the general issue is that the meaning of FULLSCREEN type on the desktop is very different from our needs, sincethe typical use case is a video player. The type is used to mark windows which must be: 1 Always on the top of everything else. 2 Maximized/undecorated. We would need to drop 1. What about making Activities run as _NET_WM_TYPE_DESKTOP? How does Metacity handle multiple DESKTOP windows? (It probably isn't happy about them...) I'm pretty sure it won't handle them as we would like. Also DESKTOP is used for the home/group/mesh view already. It may be that we can find a way to make this work under stock Metacity if we're creative. If not, Metacity is under very active development. Perhaps we can find a small change that resolves our problem and is satisfying to upstream Metacity. It could be done by extending metacity (upstream) to provide an option to enable a different handling of FULLSCREEN windows. But what is the advantage over defining a new type which is more closely tied to our use case? The one I can think of is that existing toolkits has already a way to create fullscreen windows without using low level API. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marco Pesenti Gritti wrote: | On Fri, Sep 19, 2008 at 12:13 AM, Benjamin M. Schwartz | [EMAIL PROTECTED] wrote: | Let's keep thinking about this. For example, I wonder what Metacity does | to a window that is both _NET_WM_STATE_FULLSCREEN and | _NET_WM_STATE_BELOW? Does it stack it below the Frame, if the Frame is | _NET_WM_TYPE_DOCK and _NET_WM_STATE_ABOVE? If not, could we convince the | Metacity developers that this is a good idea? | | I just thought of a worst problem with the FULLSCREEN approach. | FULLSCREEN windows are always on the top of NORMAL windows. Why is this a problem? When do we need an Activity to be visible, full-screen, and yet below a NORMAL window? - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjT7zMACgkQUJT6e6HFtqRNUgCeIEI1prZOLgGWycAdRcGCefq4 LUgAn0jMC1yiHd2LkOAhZ/iPYwoJHyi6 =IHRK -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 2:00 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Fri, Sep 19, 2008 at 12:13 AM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: Let's keep thinking about this. For example, I wonder what Metacity does to a window that is both _NET_WM_STATE_FULLSCREEN and _NET_WM_STATE_BELOW? Does it stack it below the Frame, if the Frame is _NET_WM_TYPE_DOCK and _NET_WM_STATE_ABOVE? If not, could we convince the Metacity developers that this is a good idea? I just thought of a worst problem with the FULLSCREEN approach. FULLSCREEN windows are always on the top of NORMAL windows. I think the general issue is that the meaning of FULLSCREEN type on the desktop is very different from our needs, sincethe typical use case is a video player. The type is used to mark windows which must be: 1 Always on the top of everything else. 2 Maximized/undecorated. We would need to drop 1. What about making Activities run as _NET_WM_TYPE_DESKTOP? How does Metacity handle multiple DESKTOP windows? (It probably isn't happy about them...) I'm pretty sure it won't handle them as we would like. Also DESKTOP is used for the home/group/mesh view already. It may be that we can find a way to make this work under stock Metacity if we're creative. If not, Metacity is under very active development. Perhaps we can find a small change that resolves our problem and is satisfying to upstream Metacity. It could be done by extending metacity (upstream) to provide an option to enable a different handling of FULLSCREEN windows. But what is the advantage over defining a new type which is more closely tied to our use case? The one I can think of is that existing toolkits has already a way to create fullscreen windows without using low level API. Are we set on moving to metacity? I remember murmurs of using xmonad, as well as another wm I can't remember the name of. Are these stacking/hinting problems common to all window mangers, or just metacity? bobby Marco ___ 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] Ideas for Journal: How epiphany browser manages bookmarks just with tags
Ideas for Journal: How epiphany browser manages bookmarks just with tags (and does it nicely, with potential of improving of course). I made a screenshot slide-show of how tagging and the dynamic bookmarks menu based solely on tags work in Gnome's Epiphany browser. I hope this can be usefull to gather ideas for how the tagging system in the Journal could work. This could also be helpful if tagging in the future can be done within activities, so that they are easily, and thus more often, used. I show how in Epiphany: tags are searched; tags are suggested; pre-existing and new tags are added; tags are presented; and how tagged bookmarks are organized in a menu. The size is a bit big because of all the screenshots, it's 46.7 MB . C_scott uploaded it for me, at http://dev.laptop.org/~cscott/eduardo-epiphany-tags.pdf Eduardo ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Unannounced String Freeze break ??
Hi all, While chewing through the translations on the final leg for 8.2, I noticed this commit in Sugar. http://dev.laptop.org/git?p=sugar;a=commitdiff;h=afaa5f77dd01948a27575602cf5c655d025990b9 It adds five new strings to sugar, and the patch mentions it does not come in the way of string freeze :-S (http://dev.laptop.org/attachment/ticket/7480/updated-network-module-for-control-panel-v3.diff). I am a bit confused. This is definitely a break in string freeze, and yet, the patch mentions that string freeze is not affected. Was a string freeze break approval asked for in this case ? Thanks, Sayamindu PS: Michael, I think we need to refine the Trac process a bit. Can we have a approval for string freeze break item in the next action field, so that the bug can move forward only if the approval is obtained ? -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] G1G1v2 Activities
On 19 Sep 2008, at 03:49, Douglas Bagnall wrote: Gary C Martin [EMAIL PROTECTED] wrote: Perhaps correcting http://wiki.laptop.org/go/Activity_tutorial would help? Good point -- done, at least for host_version and bundle_id. As it happens the actually published HelloWorld activity is one of the worst offenders, having no activity_version. That might even break things. Fab, thanks. I guess the trick is to flag wave about the activities that do things 'right', the only way I got things going was by rooting around in some of the existing activity source code, probably picking up all sorts of bad habits. Perhaps it could be worth linking to a few Activity source trees in git that folks think are a good next steps to investigate (for after someone has passed the 'hello world' type level stage)? OK, well... I 'think' Moon-5 can now go on your shiny happy list – Yes! :-) --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 8:30 PM, Bobby Powers [EMAIL PROTECTED] wrote: Are we set on moving to metacity? I remember murmurs of using xmonad, as well as another wm I can't remember the name of. Are these stacking/hinting problems common to all window mangers, or just metacity? They are common to all standard compliant window manager. To be honest I haven't even looked into the metacity implementation in detail yet. I'm trying to figure out something that make sense on the base of the EWMH specification. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 8:55 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Fri, Sep 19, 2008 at 8:30 PM, Bobby Powers [EMAIL PROTECTED] wrote: Are we set on moving to metacity? I remember murmurs of using xmonad, as well as another wm I can't remember the name of. Are these stacking/hinting problems common to all window mangers, or just metacity? They are common to all standard compliant window manager. To be honest I haven't even looked into the metacity implementation in detail yet. I'm trying to figure out something that make sense on the base of the EWMH specification. Btw the main reason we are considering metacity is that it uses several of the libraries used for the Sugar UI (gobject, gtk, gconf etc). Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Unannounced String Freeze break ??
On Fri, Sep 19, 2008 at 2:32 PM, Sayamindu Dasgupta [EMAIL PROTECTED] wrote: I am a bit confused. This is definitely a break in string freeze, and yet, the patch mentions that string freeze is not affected. Was a string freeze break approval asked for in this case ? I think the idea was that it only *added* strings and didn't *modify* strings, so it shouldn't affect existing translations (we'd just have a few more untranslated strings)? But you're right, we should have an explicit 'strings signoff' step in the process. If nothing else, we should be justifying why we think these strings don't need to be translated. We should probably have a 'last minute change' process written up as well, so that we always have (say) a specific one-week window at the end of the process for nothing but translation changes to allow translators a shot (at least) at catching up with the 'last minute' string changes. I hope in the 9.1 timeframe to be able to distribute updates to translations like activity updates are distributed, which ought to ease the pain somewhat. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Ideas for Journal: How epiphany browser manages bookmarks just with tags
On Fri, Sep 19, 2008 at 2:31 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: Ideas for Journal: How epiphany browser manages bookmarks just with tags (and does it nicely, with potential of improving of course). I made a screenshot slide-show of how tagging and the dynamic bookmarks menu based solely on tags work in Gnome's Epiphany browser. I hope this can be usefull to gather ideas for how the tagging system in the Journal could work. This could also be helpful if tagging in the future can be done within activities, so that they are easily, and thus more often, used. I show how in Epiphany: tags are searched; tags are suggested; pre-existing and new tags are added; tags are presented; and how tagged bookmarks are organized in a menu. The size is a bit big because of all the screenshots, it's 46.7 MB . C_scott uploaded it for me, at http://dev.laptop.org/~cscott/eduardo-epiphany-tags.pdf Eduardo Eben, Eduardo, and I have been chatting about this some over IRC. What I find most interesting here is how *filesystem paths* (well, URL paths in this particular case) are integrated with tags. For example, when you type 'fsf', both 'http://fsf.org/' and other things tagged with 'fsf' show up. This ties in with one of my frustrations with google's tag system: I have olpc, olpc-fedora, olpc-sugar, olpc-sugarlabs, etc tags in google, when what I really want is 'olpc/fedora', 'olpc/sugar', etc. Sometimes I want to see all olpc-related mail, sometimes only sugar-related olpc mail, etc. If you accept that tags can sometimes be ordered, so that a/b is different than b/a (although both will show up on searches for 'a' and 'b'), then this starts looking more and more like a way to view filesystems as well, for those old enough to want to do that. If you have files in ~/Journal/Music/Bach/Disc1 and ~/Journal/Music/Beethoven/Disc1, you can search for 'Bach', 'Music Bach' as well as 'Bach/Disc1' or 'Music/Bach/Disc1' if you want to be specific. When you insert a USB key with files in a directory called 'Music/Mozart', they appear in the journal as if they were tagged 'Music/Mozart' and you can search for 'Mozart' or 'Music' to find them. When I copy them to my XO, the tags come with, and I have operations to retag groups of files that are the result of a search (which can look very much like groups of files which are in a specific directory). Rather than having two separate views for 'hierarchy' and 'journal', this unifies them so achieve a more consistent and growable interface: you don't have to discard everything you know and learn a new metaphor and interface when you start to use 'folders'. From irc: (02:18:45 PM) C. Scott Ananian: by default searches will be confined to ~/Journal; the real question is how to search *outside* that directory. (02:18:51 PM) HoboPrimate: look at nautilus (02:19:04 PM) HoboPrimate: you see the directories as buttons. (02:19:19 PM) HoboPrimate: imagine seeing just a Journal button there (02:19:24 PM) HoboPrimate: below, the search box (02:19:33 PM) HoboPrimate: this would mean, you are searching within the journal only (02:19:49 PM) HoboPrimate: now, if you click on the journal button, it expands to allow changing it [...] (02:21:59 PM) C. Scott Ananian: HoboPrimate: well, in my ideal world you could apply a tag to any file (02:22:05 PM) C. Scott Ananian: HoboPrimate: it will just be a special xattr (02:22:27 PM) HoboPrimate: that would rock. (02:22:45 PM) HoboPrimate: so tagging wouldn't be a Journal specific thing, but (02:23:04 PM) HoboPrimate: be propagated when you move the file to other non-sugar but xattr aware systems (02:23:14 PM) C. Scott Ananian: yes The dynamic tag suggestion and ordering stuff that epiphany has (nicely presented by eduardo) would be directly applicable; all we need is the special idea that *all files are tagged by default by their path* and *there are special ordered tags* to extend the journal into a filesystem browser. Browsing a directly hierarchy feels just like browsing through tag sets; once I pick the 'Music/' tag, the 'Music/Bach' and 'Music/Beethoven' tags show up as possible extensions to my search. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 8:28 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: | I just thought of a worst problem with the FULLSCREEN approach. | FULLSCREEN windows are always on the top of NORMAL windows. Why is this a problem? When do we need an Activity to be visible, full-screen, and yet below a NORMAL window? Oh, I had missed the focused bit of this parth of EWMH: focused windows having state _NET_WM_STATE_FULLSCREEN I'm more convinced about this approach after having played with it in GNOME (with fullscreen applications like terminal, totem and epiphany). As far as I can tell so far the only issue is to keep the frame always on top, but there are ways to deal with that. Sayamindu, what do you think? Should we experiment with this approach? Give it a try in GNOME... Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Unannounced String Freeze break ??
On Sat, Sep 20, 2008 at 12:28 AM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Fri, Sep 19, 2008 at 2:32 PM, Sayamindu Dasgupta [EMAIL PROTECTED] wrote: I am a bit confused. This is definitely a break in string freeze, and yet, the patch mentions that string freeze is not affected. Was a string freeze break approval asked for in this case ? I think the idea was that it only *added* strings and didn't *modify* strings, so it shouldn't affect existing translations (we'd just have a few more untranslated strings)? Even addition is a string freeze break and should be announced. Anyway, I just announced this on the l10n list, hopefully at least some of the translators will be able to catch up. But you're right, we should have an explicit 'strings signoff' step in the process. If nothing else, we should be justifying why we think these strings don't need to be translated. We should probably have a 'last minute change' process written up as well, so that we always have (say) a specific one-week window at the end of the process for nothing but translation changes to allow translators a shot (at least) at catching up with the 'last minute' string changes. Agreed. I hope in the 9.1 timeframe to be able to distribute updates to translations like activity updates are distributed, which ought to ease the pain somewhat. --scott Yeah - I'm looking at the way this is done ib Ubuntu, and I think this can work for us as well. Will we have support for installing extra RPMs via the customization key in 9.1 ? Thanks, Sayamindu -- ( http://cscott.net/ ) -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Thu, Sep 18, 2008 at 4:07 PM, Sayamindu Dasgupta [EMAIL PROTECTED] wrote: Marco and I have been discussing on how to make a window manager like Metacity fit into the Sugar environment, and based on our current discussions, as well as past discussions, it seems clear that we need changes to the Extended Window Manager Hints spec[1]. For details on I think you are confusing the role of the Window Manager. When I run sugar under metacity, I don't *want* my activities to be full screen. When I use a windowing wm, I expect them to be in (decorated) windows. Ideally, the sugar home view would run on root, like in nautilus. On the XO, we are using a special tiling window manager. You can use a window manager like XMonad on your non-XO if you want that style of window management. That's a window manager property, sugar activities should have nothing to do with it. When I'm running Browse in my window, and then select Fullscreen mode, *then* it applies the full screen hint, and really *does* run full screen. This is just like Firefox does. Some of the links at the top of http://wiki.laptop.org/go/9.1.0#Suggestions_from_User:CScott point to window managers we could run on the XO to provide better support of the 'each activity has a full screen' window management mode. Further, they offer better support of 'floating layers', so that an application like the gimp can have a 'full screen' layer all to itself *in which* it can have several different (decorated) windows. Something like having a dedicated virtual desktop per activity. I suppose we could add a new hint for some activities indicating which of their multiple windows (if any) should be the 'background' one mapped full-screen, but I believe the existing hints are adequate. Playing around with the gimp in XMonad may be instructive. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Unannounced String Freeze break ??
On Fri, Sep 19, 2008 at 8:32 PM, Sayamindu Dasgupta [EMAIL PROTECTED] wrote: Hi all, While chewing through the translations on the final leg for 8.2, I noticed this commit in Sugar. http://dev.laptop.org/git?p=sugar;a=commitdiff;h=afaa5f77dd01948a27575602cf5c655d025990b9 It adds five new strings to sugar, and the patch mentions it does not come in the way of string freeze :-S (http://dev.laptop.org/attachment/ticket/7480/updated-network-module-for-control-panel-v3.diff). I am a bit confused. This is definitely a break in string freeze, and yet, the patch mentions that string freeze is not affected. Was a string freeze break approval asked for in this case ? I think we approved this in IRC. The reason the patchs says that it doesn't break the string freeze is that a previous version of the patch was changing strings, while this one only adds them. But yeah, we should use trac or email for string breaks . We lost that in the rush of the final release days :( Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Unannounced String Freeze break ??
On Fri, Sep 19, 2008 at 3:24 PM, Sayamindu Dasgupta [EMAIL PROTECTED] wrote:
Yeah - I'm looking at the way this is done ib Ubuntu, and I think this
can work for us as well. Will we have support for installing extra
RPMs via the customization key in 9.1 ?
Rough notes: (some of this is from
http://wiki.laptop.org/go/9.1.0#Suggestions_from_User:CScott)
* translation system should look in local, then activity, then
system translation tables, then repeat for each in a set of fallback
languages (eg, quechua, spanish, english)
* separable translation packs
* wiki-like editing of translatable labels in the UI
Switch to sugar.gettext module, with this extended lookup process for
message strings.
Switch to sugar.Label gui element, which automatically supports
editing yr local translations? Expose local dictionary in the
journal, so that Uploading/merging can be a separate program.
(String edit should happen in a separate program's window --
communicate over dbus? -- to facilitate editing of transient strings.
API should be, L(gettext msgid w/ formatting, *args), so that
gettext can be taught about L(...) as a msg marker. Variants to
support alternate domains and contexts. N_ variant probably not
needed. OR: sugar.Label(N_('message id %s'), *args, **gettextkwds)
yes, that's better. think hard about ngettext; probably kwargs like
'plural=N_('plural string'), count=n', but gettext needs to know.
(this label will also support the below)
Language change in the frame; on-the-fly change language in all open apps.
--scott
--
( http://cscott.net/ )
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We are talking about replacing Matchbox with Metacity in the XO build of Sugar. C. Scott Ananian wrote: | When I run | sugar under metacity, I don't *want* my activities to be full screen. I think you mean When I run Sugar inside a standard desktop environment on a computer with a large monitor... | Some of the links at the top of | http://wiki.laptop.org/go/9.1.0#Suggestions_from_User:CScott point to | window managers we could run on the XO to provide better support of | the 'each activity has a full screen' window management mode. That is the role for which we are discussing Metacity. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjT/m4ACgkQUJT6e6HFtqQ2dQCgmcNRf5982XIG3oIMEXaB4pG4 IrEAn3XbUFrVPOuMy0cJ13U7V6l2xvd5 =JLrm -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, 19 Sep 2008, Sayamindu Dasgupta wrote: Hello all, Marco and I have been discussing on how to make a window manager like Metacity fit into the Sugar environment, and based on our current discussions, as well as past discussions, it seems clear that we need changes to the Extended Window Manager Hints spec[1]. For details on why we want to do that, take a look at the first draft of the proposal at http://dev.laptop.org/~sayamindu/sugar_metacity/draft_1.txt The simplest way to do this is mentioned in the draft, namely, to have a new _NET_WM_WINDOW_TYPE hint, called _NET_WM_WINDOW_TYPE_NETBOOK_APP (feel free to suggest a better name :-P). All sugar activities are hinted as _NET_WM_WINDOW_TYPE_NETBOOK_APP, and the window manager maximizes and undecorates them. _NET_WM_WINDOW_KIOSK would seem to be a little better to me. netbook_app seems to imply something hardware specific, and it's not at all clear that it's appropriate for all netbooks. kiosk mode implies a specific type of use, which isn't quite the same thing, but I think the effect of it would be the same, and that is a term that's already understood. However, Marco suggests that for applications like Firefox, or Thunderbird, we may actually want them to be in maximized+undecorated in Sugar as well, to maximize screen real estate usage. In such a situation, things become a bit more complicated. Marco suggests a double hint, some thing like _NET_WM_WINDOW_TYPE_NORMAL | _NET_WM_WINDOW_TYPE_APPLICATION. In a normal desktop environment the second _NET_WM_WINDOW_TYPE_APPLICATION will not have any effect, but in Sugar, _NET_WM_WINDOW_TYPE_APPLICATION will be honoured, and windows having this hint will be maximized + undecorated. However, this brings up two problems a) applications like firefox will need to be modified so that they set the _NET_WM_WINDOW_TYPE_APPLICATION hint (ideally we would like to run the applications unmodified). b) one of the major reasons why we can do away with the decorations in case of sugar activities is that they are designed to work well without decorations (eg: a large close button on the window itself). otoh, most desktop applications do not have this, and the close button is usually somewhere hidden in the menu. In some cases the close button may not be accessible at all (eg: a rogue popup in firefox which somehow circumvents the popup blocker and disables the menubar). Note that this is a problem with the existing Firefox activity as well. you can't cover every case, but even if the menubar is disabled, the keystroke combination to close the window works. David Lang ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 9:26 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: I think you are confusing the role of the Window Manager. When I run sugar under metacity, I don't *want* my activities to be full screen. When I use a windowing wm, I expect them to be in (decorated) windows. Yeah, ideally it should work like that. That's the main point I was trying to make about both Sayamindu and Benjamin proposal. Ideally, the sugar home view would run on root, like in nautilus. This should already work fine. I suppose we could add a new hint for some activities indicating which of their multiple windows (if any) should be the 'background' one mapped full-screen, but I believe the existing hints are adequate. That's what the PRIMARY/APPLICATION was meant to be in my proposal... I'm not sure the existing hints are adeguate, but if there are window managers which manage to deal with the gimp correctly, then I guess there are at least ways to make reasonable guesses. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 3:33 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We are talking about replacing Matchbox with Metacity in the XO build of Sugar. Right, I think that's where you're going wrong. You should be considering replacing Matchbox with a better window manager. Metacity is the wrong one. | When I run | sugar under metacity, I don't *want* my activities to be full screen. I think you mean When I run Sugar inside a standard desktop environment on a computer with a large monitor... No, I mean what I said. Who says 1200x900 is small? | Some of the links at the top of | http://wiki.laptop.org/go/9.1.0#Suggestions_from_User:CScott point to | window managers we could run on the XO to provide better support of | the 'each activity has a full screen' window management mode. That is the role for which we are discussing Metacity. again, that's probably not the right window manager to be looking at. Metacity is not designed to do this, and the maintainer does not like to add cruft to it. It is the poster child of the *non*extensible, *do things only one way* window manager. Not the right one for this. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 9:43 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: Well, if there's only one window, and it's stretchable, then your decision is easy. If it requests a fixed size, then you should probably decorate and float all the windows. I could also see floating all fixed size windows and tiling all stretchable windows -- that would make the 'gimp' work nicely; all the palettes would be floating and all the drawings would be tiled. And that's using only the stretchable hint. =) I'm not entirely opposed to adding new hints for oddball apps, but I'd like 99% of apps to work as-is, and from my review of the wms out there, it seems quite plausible that we can do this. FWIW, the wm itself can add hints based on window class for outliers, without requiring the outliers themselves to be changed. I see you mention three window managers on your page (including metacity). It would nice to see a quick analysis of their strengths/weaknesses for our use case... If we go with this approach, Sugar itself is likely to require small or no changes and I can just let you and Sayamindu deal with all of it :) Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Ideas for Journal: How epiphany browser manages bookmarks just with tags
2008/9/19 C. Scott Ananian [EMAIL PROTECTED]: On Fri, Sep 19, 2008 at 2:31 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: Ideas for Journal: How epiphany browser manages bookmarks just with tags (and does it nicely, with potential of improving of course). I made a screenshot slide-show of how tagging and the dynamic bookmarks menu based solely on tags work in Gnome's Epiphany browser. I hope this can be usefull to gather ideas for how the tagging system in the Journal could work. This could also be helpful if tagging in the future can be done within activities, so that they are easily, and thus more often, used. I show how in Epiphany: tags are searched; tags are suggested; pre-existing and new tags are added; tags are presented; and how tagged bookmarks are organized in a menu. The size is a bit big because of all the screenshots, it's 46.7 MB . C_scott uploaded it for me, at http://dev.laptop.org/~cscott/eduardo-epiphany-tags.pdf Eduardo Eben, Eduardo, and I have been chatting about this some over IRC. What I find most interesting here is how *filesystem paths* (well, URL paths in this particular case) are integrated with tags. For example, when you type 'fsf', both 'http://fsf.org/' and other things tagged with 'fsf' show up. This ties in with one of my frustrations with google's tag system: I have olpc, olpc-fedora, olpc-sugar, olpc-sugarlabs, etc tags in google, when what I really want is 'olpc/fedora', 'olpc/sugar', etc. Sometimes I want to see all olpc-related mail, sometimes only sugar-related olpc mail, etc. If you accept that tags can sometimes be ordered, so that a/b is different than b/a (although both will show up on searches for 'a' and 'b'), then this starts looking more and more like a way to view filesystems as well, for those old enough to want to do that. I don't follow this. Thinking in Journal terms, where currently the only access is through the search box, you could search for olpc sugarlabs to see your olpc-sugar e-mails, or olpc to see all which fit under olpc, i.e. olpc-fedora+olpc-sugarlabs+olpc-sugar. A search which doesn't work if you follow the containerization way of directories, would be if you searched just for sugarlabs . This would give you olpc-sugarlabs results, but also would find sugarlabs tagged entries which didn't belong to the olpc- root (like a logo of Sugarlabs, or some document about it). To go back to the way Gmail works, or should work, would be having the ability to assign multiple tags to each label, i.e., make them be virtual folders. So in your case you would have one which showed results with tags olpc, sugar, another olpc, fedora, and olpc, sugar, and olpc, sugarlabs. Then you could still have one just with tag olpc which would show all of the above, or you could just search for olpc tagged entries giving all of the above as well. So I agree that some kind of containerization is needed, but not in the form of a/b being different than b/a, but by using virtual folders or saved searches which would effectively act as virtual folders, with specific tags, search terms, object types, even a period of time if you wished. (Debian has had for some time debtags, which are a more advanced method of tagging objects originally developed for libraries, but I think is too formal for kids, since it would need for them to learn a new classification system to categorize their library of objects.) If you have files in ~/Journal/Music/Bach/Disc1 and ~/Journal/Music/Beethoven/Disc1, you can search for 'Bach', 'Music Bach' as well as 'Bach/Disc1' or 'Music/Bach/Disc1' if you want to be specific. When you insert a USB key with files in a directory called 'Music/Mozart', they appear in the journal as if they were tagged 'Music/Mozart' and you can search for 'Mozart' or 'Music' to find them. When I copy them to my XO, the tags come with, and I have operations to retag groups of files that are the result of a search (which can look very much like groups of files which are in a specific directory). Yep, I think this is a good idea to move files from a hierarchical system to a non hierarchical system (the Journal) and still reuse the information contained in that first organizational system. Rather than having two separate views for 'hierarchy' and 'journal', this unifies them so achieve a more consistent and growable interface: you don't have to discard everything you know and learn a new metaphor and interface when you start to use 'folders'. I hope, like I said above, that virtual folders or saved searches (they're the same, just differently named) would replace static folders. From irc: (02:18:45 PM) C. Scott Ananian: by default searches will be confined to ~/Journal; the real question is how to search *outside* that directory. (02:18:51 PM) HoboPrimate: look at nautilus (02:19:04 PM) HoboPrimate: you see the directories as buttons. (02:19:19 PM) HoboPrimate: imagine seeing just a Journal button there
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Sat, Sep 20, 2008 at 12:49 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Fri, Sep 19, 2008 at 8:28 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: | I just thought of a worst problem with the FULLSCREEN approach. | FULLSCREEN windows are always on the top of NORMAL windows. Why is this a problem? When do we need an Activity to be visible, full-screen, and yet below a NORMAL window? Oh, I had missed the focused bit of this parth of EWMH: focused windows having state _NET_WM_STATE_FULLSCREEN I'm more convinced about this approach after having played with it in GNOME (with fullscreen applications like terminal, totem and epiphany). As far as I can tell so far the only issue is to keep the frame always on top, but there are ways to deal with that. Sayamindu, what do you think? Should we experiment with this approach? Give it a try in GNOME... I took a look, and it does seem promising. However, in this case, we need to figure out how to circumvent our existing fullscreen code. For the frame, setting it to have _NET_WM_STATE_ABOVE might help. Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 3:56 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Fri, Sep 19, 2008 at 9:43 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: Well, if there's only one window, and it's stretchable, then your decision is easy. If it requests a fixed size, then you should probably decorate and float all the windows. I could also see floating all fixed size windows and tiling all stretchable windows -- that would make the 'gimp' work nicely; all the palettes would be floating and all the drawings would be tiled. And that's using only the stretchable hint. =) I'm not entirely opposed to adding new hints for oddball apps, but I'd like 99% of apps to work as-is, and from my review of the wms out there, it seems quite plausible that we can do this. FWIW, the wm itself can add hints based on window class for outliers, without requiring the outliers themselves to be changed. I see you mention three window managers on your page (including metacity). It would nice to see a quick analysis of their strengths/weaknesses for our use case... I spent a while looking at documentation for all of them, but I need to schedule some hands-on experience time. Some moderate customization of the wm is probably necessary, since many of them ship with power user defaults with keyboard window switching, etc. The exact 'one virtual desktop per application' (well, maybe not a real virtual desktop, but roughly) use case doesn't seem to be out-of-the-box, but shouldn't be too hard. XMonad had erikg as a user advocate, but I worry about maintaining a Haskell app. It does have a vibrant user community, though, and is easily customized. My feeling is that metacity will be hard to upstream patches to, and it would be more work to get working 'right', since it's pretty much designed *not* to be extensible. But it is the default wm these days. awesome seems to be on the ball wrt standards compliance, but is extended in Lua (yet another language) and I don't know anyone who uses it -- not that there aren't people, it just doesn't have a local advocate. awesome and whimsy are among those listed on http://www.freedesktop.org/wiki/Specifications/wm-spec -- whimsy is written in python, which I like, but seems immature, which I don't. whimsy also doesn't support the 'floating' layer necessary for apps like gimp. So, my initial impression was that awesome would probably work fine, but that if erikg or m_stone wanted to hack on XMonad, I could easily be convinced of that, too. If whimsy sprouted decent support for floating windows, I'd seriously consider it; it would be nice to have a small hackable wm in our standard language. awesome was on the top of my list to hack around with when I get time and see if I could make it do the tricks I wanted it to do. If we go with this approach, Sugar itself is likely to require small or no changes and I can just let you and Sayamindu deal with all of it The main changes required, I think, would actually be to the shell code to make it happy running on a root window. There's some reparenting magic that's done to make that work right; I was pointed to the xpenguins source for information on what that involves, I don't think it's a lot that needs to be done. We might have to tweak the frame implementation so that it speaks the same standard wm-communication language as the window selectors in the gnome panel, if it doesn't already; haven't looked at that. And, of course, I wanted to switch sugar to using the standard X activity startup notification mechanism, and the standard desktop notification mechanism. Those aren't strictly required for the wm switchover, but would complete most of the work of making us a real citizen of the outside world. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Sat, Sep 20, 2008 at 12:56 AM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Thu, Sep 18, 2008 at 4:07 PM, Sayamindu Dasgupta [EMAIL PROTECTED] wrote: Marco and I have been discussing on how to make a window manager like Metacity fit into the Sugar environment, and based on our current discussions, as well as past discussions, it seems clear that we need changes to the Extended Window Manager Hints spec[1]. For details on I think you are confusing the role of the Window Manager. When I run sugar under metacity, I don't *want* my activities to be full screen. When I use a windowing wm, I expect them to be in (decorated) windows. Ideally, the sugar home view would run on root, like in nautilus. Metacity was provided just as an example. The issue here is that we want to replace Matchbox with something which would let us support normal desktop applications better, ideally without requiring any kind of modification to the applications themselves. (better support, for instance means, not messing up The Gimp) On the XO, we are using a special tiling window manager. You can use a window manager like XMonad on your non-XO if you want that style of window management. That's a window manager property, sugar activities should have nothing to do with it. Agreed. But are sugar activities (or rather, should sugar applications be) the same as normal desktop applications from a window manager peerspective. When I'm running Browse in my window, and then select Fullscreen mode, *then* it applies the full screen hint, and really *does* run full screen. This is just like Firefox does. Yes, that is why I'm still somewhat opposed to running all our activities with the FULLSCREEN hint permanently on - IMO, we need to differentiate between the two modes of an application or an activity, and the window manager needs to know about that. Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Sat, Sep 20, 2008 at 1:13 AM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Fri, Sep 19, 2008 at 3:35 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: I suppose we could add a new hint for some activities indicating which of their multiple windows (if any) should be the 'background' one mapped full-screen, but I believe the existing hints are adequate. That's what the PRIMARY/APPLICATION was meant to be in my proposal... I'm not sure the existing hints are adeguate, but if there are window managers which manage to deal with the gimp correctly, then I guess there are at least ways to make reasonable guesses. Well, if there's only one window, and it's stretchable, then your decision is easy. If it requests a fixed size, then you should probably decorate and float all the windows. I could also see floating all fixed size windows and tiling all stretchable windows -- that would make the 'gimp' work nicely; all the palettes would be floating and all the drawings would be tiled. And that's using only the stretchable hint. =) GIMP is stretchable. It looks ugly when it is stretched too much, but you can stretch it or even maximize it if you want. Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Ideas for Journal: How epiphany browser manages bookmarks just with tags
On Fri, Sep 19, 2008 at 3:59 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: 2008/9/19 C. Scott Ananian [EMAIL PROTECTED]: On Fri, Sep 19, 2008 at 2:31 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: Ideas for Journal: How epiphany browser manages bookmarks just with tags (and does it nicely, with potential of improving of course). I made a screenshot slide-show of how tagging and the dynamic bookmarks menu based solely on tags work in Gnome's Epiphany browser. I hope this can be usefull to gather ideas for how the tagging system in the Journal could work. This could also be helpful if tagging in the future can be done within activities, so that they are easily, and thus more often, used. I show how in Epiphany: tags are searched; tags are suggested; pre-existing and new tags are added; tags are presented; and how tagged bookmarks are organized in a menu. The size is a bit big because of all the screenshots, it's 46.7 MB . C_scott uploaded it for me, at http://dev.laptop.org/~cscott/eduardo-epiphany-tags.pdf Eduardo Eben, Eduardo, and I have been chatting about this some over IRC. What I find most interesting here is how *filesystem paths* (well, URL paths in this particular case) are integrated with tags. For example, when you type 'fsf', both 'http://fsf.org/' and other things tagged with 'fsf' show up. This ties in with one of my frustrations with google's tag system: I have olpc, olpc-fedora, olpc-sugar, olpc-sugarlabs, etc tags in google, when what I really want is 'olpc/fedora', 'olpc/sugar', etc. Sometimes I want to see all olpc-related mail, sometimes only sugar-related olpc mail, etc. If you accept that tags can sometimes be ordered, so that a/b is different than b/a (although both will show up on searches for 'a' and 'b'), then this starts looking more and more like a way to view filesystems as well, for those old enough to want to do that. I don't follow this. Thinking in Journal terms, where currently the only access is through the search box, you could search for olpc sugarlabs to see your olpc-sugar e-mails, or olpc to see all which fit under olpc, i.e. olpc-fedora+olpc-sugarlabs+olpc-sugar. A search which doesn't work if you follow the containerization way of directories, would be if you searched just for sugarlabs . This would give you olpc-sugarlabs results, but also would find sugarlabs tagged entries which didn't belong to the olpc- root (like a logo of Sugarlabs, or some document about it). To go back to the way Gmail works, or should work, would be having the ability to assign multiple tags to each label, i.e., make them be virtual folders. So in your case you would have one which showed results with tags olpc, sugar, another olpc, fedora, and olpc, sugar, and olpc, sugarlabs. Then you could still have one just with tag olpc which would show all of the above, or you could just search for olpc tagged entries giving all of the above as well. So I agree that some kind of containerization is needed, but not in the form of a/b being different than b/a, but by using virtual folders or saved searches which would effectively act as virtual folders, with specific tags, search terms, object types, even a period of time if you wished. I don't mean to belittle the utility of virtual folders (I think they're quite powerful), but you can also get a close approximation to them by applying a sufficiently unique tag to a group of items as well. In fact, a basic implementation of such a feature could do exactly that, requesting a name for the virtual folder and then tagging the selected items with vf:Name of virtual folder (or something similar, but you get the idea). The real question (I didn't overlook this!) regarding the concept of virtual folders (or, more specifically, saved searches) is whether or not they are dynamic. That is, does the saved search represent an expression or a value? My above tag idea is only valid, of course, when they are represented in value form. For more power (but more complexity) one would store the search terms, filters, etc. and re-apply them on the fly to a growing list. I'm not sure which of these is more desired. They both have merits. (Debian has had for some time debtags, which are a more advanced method of tagging objects originally developed for libraries, but I think is too formal for kids, since it would need for them to learn a new classification system to categorize their library of objects.) If you have files in ~/Journal/Music/Bach/Disc1 and ~/Journal/Music/Beethoven/Disc1, you can search for 'Bach', 'Music Bach' as well as 'Bach/Disc1' or 'Music/Bach/Disc1' if you want to be specific. When you insert a USB key with files in a directory called 'Music/Mozart', they appear in the journal as if they were tagged 'Music/Mozart' and you can search for 'Mozart' or 'Music' to find them. When I copy them to my XO, the tags come with, and I have operations to retag groups of
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Sat, Sep 20, 2008 at 1:26 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Fri, Sep 19, 2008 at 9:43 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: Well, if there's only one window, and it's stretchable, then your decision is easy. If it requests a fixed size, then you should probably decorate and float all the windows. I could also see floating all fixed size windows and tiling all stretchable windows -- that would make the 'gimp' work nicely; all the palettes would be floating and all the drawings would be tiled. And that's using only the stretchable hint. =) I'm not entirely opposed to adding new hints for oddball apps, but I'd like 99% of apps to work as-is, and from my review of the wms out there, it seems quite plausible that we can do this. FWIW, the wm itself can add hints based on window class for outliers, without requiring the outliers themselves to be changed. I see you mention three window managers on your page (including metacity). It would nice to see a quick analysis of their strengths/weaknesses for our use case... Just a note that Xmonad seems to pull in 35 MBs of RPMs as dependencies. I'm not sure whether that is good for our storage space. Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Ideas for Journal: How epiphany browser manages bookmarks just with tags
On Fri, Sep 19, 2008 at 3:59 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: 2008/9/19 C. Scott Ananian [EMAIL PROTECTED]: On Fri, Sep 19, 2008 at 2:31 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: If you accept that tags can sometimes be ordered, so that a/b is different than b/a (although both will show up on searches for 'a' and 'b'), then this starts looking more and more like a way to view filesystems as well, for those old enough to want to do that. I don't follow this. Thinking in Journal terms, where currently the only access is through the search box, you could search for olpc sugarlabs to see your olpc-sugar e-mails, or olpc to see all which fit under olpc, i.e. olpc-fedora+olpc-sugarlabs+olpc-sugar. A search which doesn't work if you follow the containerization way of directories, would be if you searched just for sugarlabs . This would give you olpc-sugarlabs results, but also would find sugarlabs tagged entries which didn't belong to the olpc- root (like a logo of Sugarlabs, or some document about it). My example might not have been the best, but independent tags start having real problems when I have a lot of tags and many of the tags are duplicated. Some more examples: * jill/joe might be what jill thinks of joe, while joe/jill might be what joe thinks of jill. * techsquares/lists is email relating to the mailing lists I maintain for tech-squares, while lists contains all my subscription information for mailing lists I belong to, and lists/techsquares is thus my own mailman login for the techsquares list (which I'm on, as well as maintain). * The total list of tags in my gmail instance is very large! But the top-level list could be much smaller if I could order them hierarchically. So I agree that some kind of containerization is needed, but not in the form of a/b being different than b/a, but by using virtual folders or saved searches which would effectively act as virtual folders, with specific tags, search terms, object types, even a period of time if you wished. I think this is a separate functionality. This lets me take my 'techsquares/lists subscribe-requests' search and turn it into a top level tag. Containerization is meant to prevent all tags from becoming top level. Rather than having two separate views for 'hierarchy' and 'journal', this unifies them so achieve a more consistent and growable interface: you don't have to discard everything you know and learn a new metaphor and interface when you start to use 'folders'. I hope, like I said above, that virtual folders or saved searches (they're the same, just differently named) would replace static folders. They're complimentary. If you look at [[Olpcfs]], there's a way to navigate 'tag space' and even 'search space' as if it were a directory. Ordered tags are a way to navigate directory space as if it were a tag soup. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Unannounced String Freeze break ??
Marco Pesenti Gritti wrote: On Fri, Sep 19, 2008 at 8:32 PM, Sayamindu Dasgupta [EMAIL PROTECTED] wrote: Hi all, While chewing through the translations on the final leg for 8.2, I noticed this commit in Sugar. http://dev.laptop.org/git?p=sugar;a=commitdiff;h=afaa5f77dd01948a27575602cf5c655d025990b9 It adds five new strings to sugar, and the patch mentions it does not come in the way of string freeze :-S (http://dev.laptop.org/attachment/ticket/7480/updated-network-module-for-control-panel-v3.diff). I am a bit confused. This is definitely a break in string freeze, and yet, the patch mentions that string freeze is not affected. Was a string freeze break approval asked for in this case ? I think we approved this in IRC. The reason the patchs says that it doesn't break the string freeze is that a previous version of the patch was changing strings, while this one only adds them. Yeah the comment could have been clearer :/ Sorry, I will make sure to announce it properly next time. Best, Simon ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Ideas for Journal: How epiphany browser manages bookmarks just with tags
On Fri, Sep 19, 2008 at 4:57 PM, Eben Eliason [EMAIL PROTECTED] wrote: Two) to get at the thing you're looking for. So, again, I'm not sure that order really matters. Of course, if it DID really matter for a reason I'm not presently considering, we could allow tags of the form: A/B To match on A, B, A B B A, and also A/B (but not B/A). In other words, the addition of the slash to the tag format is used similarly to the way quotes are used to group two tags into one. Instead of grouping, however, it orders instead. It's interesting, but I'm not sure I see a good utility there yet. I think there is compelling utility in terms of mapping tag space to a filesystem and back. I hope that (like quotes) there is not all that often when you need to use them -- but they are a useful power-user feature. The following are all related searches: A B-- matches these tag sets A B C, B A C, A/B C, B/A C, etc. A/B-- matches A/B, C/A/B, A/B/C, etc. B/A-- matches B/A, C/B/A, B/A/C, etc. A B -- matches 'A B' C, etc /A/B -- matches A/B/C but not C/A/B They express slightly different meanings, but in many cases will be indistinguishable from A B. I think they add a lot of power to the tag language, although naive users won't need to use it often. Completion on a search for A/B would suggest A/B/C if there is a 'subfolder' C; it would suggest A/B C if there was an item labelled with A/B and tag C. If a young user has never made subfolders, then the slash-separated options will never be suggested and all this power remains hidden. An interesting point Eduardo brought up was the relationship between folders and saved searches. Do tag completions (ie sub folders or related tags) show up in the journal itself, or only in a pane during a search? If they show up as first class objects, then it might be nice to have searches in general as first class objects. I think I'm arguing that tag completions are not the same thing as journal items, and only show up during a search. I could be convinced otherwise. Another interesting point: gmail's UI never lets you see the results of the 'empty' search (that is, all objects). By default the search is restricted to 'in:Inbox' and the easiest UI mechanisms always restrict the search to a 'folder'. You can click 'Search Mail' with an empty search query, though, and what you get is very similar to what one might imagine the Journal to be: a chronological list of all your email (activity instances), grouped by thread (version), with a list of clickable tags on each which you can use to find other similar emails (activity instances). Gmail does have a flexible 'rules' system to help automatically tag/categorize/file documents, though; it may be worthwhile thinking what the Journal could do in that regard. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 4:50 PM, Sayamindu Dasgupta [EMAIL PROTECTED] wrote: Metacity was provided just as an example. The issue here is that we want to replace Matchbox with something which would let us support normal desktop applications better, ideally without requiring any kind of modification to the applications themselves. (better support, for instance means, not messing up The Gimp) +1 Agreed. But are sugar activities (or rather, should sugar applications be) the same as normal desktop applications from a window manager peerspective. Yes, for the most part. Inkscape or gnumeric running with one window open should look the same as a sugar activity. Things only start getting interesting when I open two documents simultaneously in inkscape. When I'm running Browse in my window, and then select Fullscreen mode, *then* it applies the full screen hint, and really *does* run full screen. This is just like Firefox does. Yes, that is why I'm still somewhat opposed to running all our activities with the FULLSCREEN hint permanently on - IMO, we need to differentiate between the two modes of an application or an activity, and the window manager needs to know about that. +1 GIMP is stretchable. It looks ugly when it is stretched too much, but you can stretch it or even maximize it if you want. wow, i never realized this. You're right. I was just trying to illustrate that the layout strategy doesn't have to be very complicated for most applications. Gimp does set reasonable window hints, and simply falling back to floating mode with window decorations when multiple non-dialog windows are mapped is a good first-draft wm policy. Just a note that Xmonad seems to pull in 35 MBs of RPMs as dependencies. I'm not sure whether that is good for our storage space. Wow. I think part of the reason is that Xmonad supports recompiling itself on the fly to allow you to dynamically edit the wm configuration, and so pulls in the entire Haskell compiler and all its libraries. I'm willing to bet that a static configuration could be made much smaller -- but that's clearly one of the issues that should be relevant in the final choice for wm. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] G1G1v2 Activities
On Thu, 18 Sep 2008, [EMAIL PROTECTED] wrote: benjamin m. schwartz wrote: Chris Ball wrote: | So, we shipped 19 activities with G1G1v1; that means the ten activities | people vote for here are likely to be a subset of that list, and we | aren't learning much about what new things we should include. People | replying might decide to give 20 suggestions instead of 10, or to omit | original G1G1 activities from their list. | Also, G1G1v1 shipped with the old Sugar interface, which made managing large numbers of installed Activities very difficult. By contrast, the new Sugar UI means that we could easily ship 100 Activities, with only 15 starred by default. Activities' average size on disk varies substantially, but many simpler ones are only about 100 KB, compressed. 100 Activities * 100 KB = 10 MB, or 1% of the disk. Each additional Activity provides more opportunity for exploration, and makes the experience more enjoyable, so I would advocate for shipping as many as possible. i disagree, to the extent that the activities appear on the laptop in a completely unorganized fashion -- there's no real notion of topic, or testedness, or age-appropriateness. too many can make the prospect of exploring them overwhelming, especially given how long it takes to try them, and that most of the names bear almost no relation to the content. i think it's better to ship a a good representative sample, and clear instructions (somewhere -- is it at least in a pre-loaded library page?) on how to explore and get more from our wiki. isn't there an activity to manage activities? is there any way to order them so that this one shows up first? If so, then I would say ship as close to everything as possible, with the idea that this management activity will help the user remove what they don't want easily. not everyone who's playing around with an XO has network connectivity, which makes it _far_ easier to remove stuff that you don't care about then to add additional stuff in later. I suspect that most of the G1G1 laptops out there are running the default set of activities. Also, if you don't know what types of activities exist, you won't go looking for them. if you have lots of samples it's far easier to think of other similar things to look for. In fact, thinking about this as I've been typing this message, I think it would be a _good_thing_ if there was an entry for every activity that's supported, even if all that the 'activity' consists of is a web page that shows what the activity is and has a link to download it (useful for activities that are otherwise too large or not appropriate for all ages) David Lang ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] G1G1v2 Activities
On Thu, Sep 18, 2008 at 10:01 PM, Gary C Martin [EMAIL PROTECTED] wrote: However, any hints would be much appreciated as to what this last remaining setup.py WARNING is trying to tell me? WARNING:root:bundle_name deprecated, now comes from activity.info I've not had much luck tracking it down, and I make no reference to bundle_name in my code. When you call BundleBuilder in setup.py, don't pass in a string in the constructor, leave it empty. It interprets the argument as a 'bundle_name' and is complaining that it's going to ignore what you passed in and use the name specified in activity.info instead. Yes, it took me a *long* time to finally realize this. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] G1G1v2 Activities
On Thu, Sep 18, 2008 at 7:13 PM, Douglas Bagnall [EMAIL PROTECTED] wrote: If we're sticking to activities with valid activity.info files, then (AFAICT) we're limited to: Actually, we can only ship activities with valid license= tags in the activity.info files. I don't think many on your list qualify. But that doesn't matter at the moment -- we'll poke the authors to add appropriate license information (and host_version!) for the activities we decide to ship. Let's return to the original question: what activities should those be? Concentrating on activities *not* in the original G1G1 list, as cjb suggests, is probably a good idea -- although if there are any of those activities you activity *don't* think we should ship, that's probably of interest as well. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] G1G1v2 Activities
I vote very strongly for Ruler. It's less than 20kb non-compressed! It's too small *not* to include. Top Ten: 1.) Ruler 2.) Moon 3.) StarChart 4.) Bridge 5.) XaoS 6.) Frotz 7.) WikiBrowse Spanish 8.) Words 9.) Tumbleboy On Fri, Sep 19, 2008 at 7:48 AM, Marco Pesenti Gritti [EMAIL PROTECTED]wrote: On Fri, Sep 19, 2008 at 1:10 PM, Gary C Martin [EMAIL PROTECTED] wrote: So I should keep both in my activity.info for backwards compatibility with early builds? This was change *long* time ago. I suspect your activity would not work for other reasons if run with such an old Sugar. Marco ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
Lots of discussion -- but I'm not sure how much benefit the Sugar *user* might receive. I think that everybody agrees (myself included) that the user must be able to call up the Frame anytime. And for typical Activities, the amount of screen real estate they *themselves* obstruct (which the Frame itself doesn't already obstruct) is small. Looks like a general mechanism to free up screen real estate ends up freeing mainly areas that get overlain anyway whenever Frame is called. To me, supporting multiple windows for one Activity is a much more pressing need than supporting full screen for every Activity. In the current Sugar implementation, alt-tab appears to provide an adequate way to navigate among such windows (i.e., screens) - but more discussion is needed about the role of Frame in this situation. I see nothing wrong with what some Activities already implement - by default they run with some areas obstructed by decorations -- but at the option of the user a short-cut removes those decorations. [Now if the discussion were about how to best implement such a facility - go to it. But it seems to me the discussion is leaning too far towards a let's free the Activity's limits crusade.] I think that to a user, gray circles left in Frame are of more immediate concern than shortcomings of using Matchbox with Sugar. mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 4:59 PM, Mikus Grinbergs [EMAIL PROTECTED] wrote: Lots of discussion -- but I'm not sure how much benefit the Sugar *user* might receive. Some users will want to use gimp. Some will want to use metacity. To me, supporting multiple windows for one Activity is a much more pressing need than supporting full screen for every Activity. In the current Sugar implementation, alt-tab appears to provide an adequate way to navigate among such windows (i.e., screens) - but more discussion is needed about the role of Frame in this situation. I envision having one screen with multiple windows. Basically, each activity gets its own virtual desktop. You can either have these windows decorated or not, depending on whether you prefer tiled or overlapping window managers. I think that to a user, gray circles left in Frame are of more immediate concern than shortcomings of using Matchbox with Sugar. That would be my 'we should use the standard X startup notification mechanism' rant. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] G1G1v2 Activities
I wouldn't include Bridge yet. It's great, but not complete. I would include: WikiBrowse PlayGo Frotz Clock GCompris Chess GCompris Sudoku XaoS Moon StarChart ePals On Fri, Sep 19, 2008 at 5:53 PM, Seth Woodworth [EMAIL PROTECTED] wrote: I vote very strongly for Ruler. It's less than 20kb non-compressed! It's too small *not* to include. Top Ten: 1.) Ruler 2.) Moon 3.) StarChart 4.) Bridge 5.) XaoS 6.) Frotz 7.) WikiBrowse Spanish 8.) Words 9.) Tumbleboy ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] G1G1 Pre-installed Activities Request for Help Testing
Hi All, Thanks a lot for the input on which activities to ship! Here is the list of activities I will to management as my suggestion on what we ship. Please help test these! See the end of the e-mail for instructions. The list I recommend is essentially the G1G1 activities (kudos to the team who chose the first set!). In addition to those I list a few which got repeated votes (except Chess and Sudoku which are a concession to SJ ;-) Original G1G1 activities: Browse Read Write Paint Record TamTam Jam, Mini, on fence: Synthlab, Edit, Chat Pippy Etoys Turtle Art Calculate Measure Distance Memorize Terminal Log Analyze New ones: Help Implode Speak Maze SimCity Scratch Xaos StarChart Moon GCompris Chess GCompris Sudoku The only significant change from the original G1G1 set is the TamTam. I think we should include 2 not 4 so as not to over weight them against other activities. Let me know if anyone has comments on that (Jean can you live with that?). Not all of these are sure to make it. On the other hand it's very unlikely that anything else will make it. So if you have an urgent request or a specific concern please speak up now. Of course, anyone can download additional activities so even if an activity is not on this list, it still attracts a lot of users. We need help testing these with the latest 8.2 image. We plan to make a release candidate today and if it passes smoke test we will add the activities and content to create a signed release candidate on Monday! Developers, Please reply with the final version and URL of each activity which we should include in the image. Each one must pass final test and have an active and reachable developer to make the final list. Morgan, can you make sure we have a contact e-mail and name on each of these? Also, let me know if you any of them are orphaned or not well maintained. All, Please test them all one more time let us know how it goes. I want to know if each of these passes the tests described here: http://wiki.laptop.org/go/Test_cases_8.2.0#Activities Please create a new test case for any activity that needs one. To do that, go to this page: http://wiki.laptop.org/go/Form:Test_case and entering Tests/Activities/nameofactivity to create a new test case. Then choose activity from the drop down and you can just paste in the steps test from above for a start. Then you can add a test result by clicking on the + sign next to the test case (it takes a little while for them to show up after creation). You can also e-mail comments or test results back to this list. Thanks a lot for your help. Thanks, Greg S ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] G1G1 Pre-installed Activities Request for Help Testing
What are your criteria? Are you ranking things by supportability and size? If so Ruler is a no-brainer. It's 20kb and is unlikely to break easily. On the other hand SimCity is hard to make drastic changes and still be called SimCity. It's currently buggy and has no active maintainer. On Fri, Sep 19, 2008 at 6:27 PM, Greg Smith [EMAIL PROTECTED] wrote: Hi All, Thanks a lot for the input on which activities to ship! Here is the list of activities I will to management as my suggestion on what we ship. Please help test these! See the end of the e-mail for instructions. The list I recommend is essentially the G1G1 activities (kudos to the team who chose the first set!). In addition to those I list a few which got repeated votes (except Chess and Sudoku which are a concession to SJ ;-) Original G1G1 activities: Browse Read Write Paint Record TamTam Jam, Mini, on fence: Synthlab, Edit, Chat Pippy Etoys Turtle Art Calculate Measure Distance Memorize Terminal Log Analyze New ones: Help Implode Speak Maze SimCity Scratch Xaos StarChart Moon GCompris Chess GCompris Sudoku The only significant change from the original G1G1 set is the TamTam. I think we should include 2 not 4 so as not to over weight them against other activities. Let me know if anyone has comments on that (Jean can you live with that?). Not all of these are sure to make it. On the other hand it's very unlikely that anything else will make it. So if you have an urgent request or a specific concern please speak up now. Of course, anyone can download additional activities so even if an activity is not on this list, it still attracts a lot of users. We need help testing these with the latest 8.2 image. We plan to make a release candidate today and if it passes smoke test we will add the activities and content to create a signed release candidate on Monday! Developers, Please reply with the final version and URL of each activity which we should include in the image. Each one must pass final test and have an active and reachable developer to make the final list. Morgan, can you make sure we have a contact e-mail and name on each of these? Also, let me know if you any of them are orphaned or not well maintained. All, Please test them all one more time let us know how it goes. I want to know if each of these passes the tests described here: http://wiki.laptop.org/go/Test_cases_8.2.0#Activities Please create a new test case for any activity that needs one. To do that, go to this page: http://wiki.laptop.org/go/Form:Test_case and entering Tests/Activities/nameofactivity to create a new test case. Then choose activity from the drop down and you can just paste in the steps test from above for a start. Then you can add a test result by clicking on the + sign next to the test case (it takes a little while for them to show up after creation). You can also e-mail comments or test results back to this list. Thanks a lot for your help. Thanks, Greg S ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 10:37 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: The main changes required, I think, would actually be to the shell code to make it happy running on a root window. There's some reparenting magic that's done to make that work right; I'm not sure what you mean exactly here... The home/mesh/groups view are all inside a single DESKTOP window, which is the same as the nautilus desktop afaik. All the other windows will be stacked on the top of it. I was pointed to the xpenguins source for information on what that involves, I don't think it's a lot that needs to be done. We might have to tweak the frame implementation so that it speaks the same standard wm-communication language as the window selectors in the gnome panel, if it doesn't already; haven't looked at that. It's not because matchbox doesn't like it. Trivial to change. And, of course, I wanted to switch sugar to using the standard X activity startup notification mechanism, and the standard desktop notification mechanism. I'm not sure this is necessary. All the activities will be run by the shell in 0.84 and the UI feedback is in the shell. I don't think we need inter process communication. The only use case I can think of is running activities from the command line but that's minor, I don't even think gnome-terminal supports it. Something else which I think is necessary is to support the standard icon property. Should not be very difficult. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Sat, Sep 20, 2008 at 1:10 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: And, of course, I wanted to switch sugar to using the standard X activity startup notification mechanism, and the standard desktop notification mechanism. I'm not sure this is necessary. All the activities will be run by the shell in 0.84 and the UI feedback is in the shell. I don't think we need inter process communication. The only use case I can think of is running activities from the command line but that's minor, I don't even think gnome-terminal supports it. Scratch that, I lied... I hope the freedesktop spec is flexible enough to implement our kind of UI feedback. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Sat, Sep 20, 2008 at 1:16 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Sat, Sep 20, 2008 at 1:10 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: And, of course, I wanted to switch sugar to using the standard X activity startup notification mechanism, and the standard desktop notification mechanism. I'm not sure this is necessary. All the activities will be run by the shell in 0.84 and the UI feedback is in the shell. I don't think we need inter process communication. The only use case I can think of is running activities from the command line but that's minor, I don't even think gnome-terminal supports it. Scratch that, I lied... I hope the freedesktop spec is flexible enough to implement our kind of UI feedback. At first sight it seem to be. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Fri, Sep 19, 2008 at 7:16 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Sat, Sep 20, 2008 at 1:10 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: And, of course, I wanted to switch sugar to using the standard X activity startup notification mechanism, and the standard desktop notification mechanism. I'm not sure this is necessary. All the activities will be run by the shell in 0.84 and the UI feedback is in the shell. I don't think we need inter process communication. The only use case I can think of is running activities from the command line but that's minor, I don't even think gnome-terminal supports it. Scratch that, I lied... I hope the freedesktop spec is flexible enough to implement our kind of UI feedback. I read the spec, it seemed sane. Proof will be in the implementation, though, of course. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Supporting desktop applications, extending the EWMH spec
On Sat, Sep 20, 2008 at 1:26 AM, C. Scott Ananian [EMAIL PROTECTED] wrote: Scratch that, I lied... I hope the freedesktop spec is flexible enough to implement our kind of UI feedback. I read the spec, it seemed sane. Proof will be in the implementation, though, of course. Yeah... Regarding implementation, gtk 2.14 added API to handle the launcher part: http://library.gnome.org/devel/gdk/stable/gdk-Application-launching.html Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] G1G1 Pre-installed Activities Request for Help Testing
On 08-09-19, at 18:27, Greg Smith wrote: Hi All, Thanks a lot for the input on which activities to ship! Here is the list of activities I will to management as my suggestion on what we ship. Please help test these! See the end of the e-mail for instructions. The list I recommend is essentially the G1G1 activities (kudos to the team who chose the first set!). In addition to those I list a few which got repeated votes (except Chess and Sudoku which are a concession to SJ ;-) Original G1G1 activities: Browse Read Write Paint Record TamTam Jam, Mini, on fence: Synthlab, Edit, Chat Pippy Etoys Turtle Art Calculate Measure Distance Memorize Terminal Log Analyze New ones: Help Implode Speak Maze SimCity Scratch Xaos StarChart Moon GCompris Chess GCompris Sudoku The only significant change from the original G1G1 set is the TamTam. I think we should include 2 not 4 so as not to over weight them against other activities. Let me know if anyone has comments on that (Jean can you live with that?). Yes. However, I think Mini and Edit would be my picks. Your call. Not all of these are sure to make it. On the other hand it's very unlikely that anything else will make it. So if you have an urgent request or a specific concern please speak up now. Of course, anyone can download additional activities so even if an activity is not on this list, it still attracts a lot of users. We need help testing these with the latest 8.2 image. We plan to make a release candidate today and if it passes smoke test we will add the activities and content to create a signed release candidate on Monday! Developers, Please reply with the final version and URL of each activity which we should include in the image. Each one must pass final test and have an active and reachable developer to make the final list. Morgan, can you make sure we have a contact e-mail and name on each of these? Also, let me know if you any of them are orphaned or not well maintained. All, Please test them all one more time let us know how it goes. I want to know if each of these passes the tests described here: http://wiki.laptop.org/go/Test_cases_8.2.0#Activities Please create a new test case for any activity that needs one. To do that, go to this page: http://wiki.laptop.org/go/Form:Test_case and entering Tests/Activities/nameofactivity to create a new test case. Then choose activity from the drop down and you can just paste in the steps test from above for a start. Then you can add a test result by clicking on the + sign next to the test case (it takes a little while for them to show up after creation). You can also e-mail comments or test results back to this list. Thanks a lot for your help. Thanks, Greg S ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] G1G1 Pre-installed Activities Request for Help Testing
This seems weighted toward older kids. I think you should include all of gcompris and TuxPaint. Paint is not a good drawing app for young children (or anybody else, but I digress). Colors is good. Cartoon builder is good for young kids. On Fri, Sep 19, 2008 at 5:42 PM, jean piche [EMAIL PROTECTED] wrote: On 08-09-19, at 18:27, Greg Smith wrote: Hi All, Thanks a lot for the input on which activities to ship! Here is the list of activities I will to management as my suggestion on what we ship. Please help test these! See the end of the e-mail for instructions. The list I recommend is essentially the G1G1 activities (kudos to the team who chose the first set!). In addition to those I list a few which got repeated votes (except Chess and Sudoku which are a concession to SJ ;-) Original G1G1 activities: Browse Read Write Paint Record TamTam Jam, Mini, on fence: Synthlab, Edit, Chat Pippy Etoys Turtle Art Calculate Measure Distance Memorize Terminal Log Analyze New ones: Help Implode Speak Maze SimCity Scratch Xaos StarChart Moon GCompris Chess GCompris Sudoku The only significant change from the original G1G1 set is the TamTam. I think we should include 2 not 4 so as not to over weight them against other activities. Let me know if anyone has comments on that (Jean can you live with that?). Yes. However, I think Mini and Edit would be my picks. Your call. Not all of these are sure to make it. On the other hand it's very unlikely that anything else will make it. So if you have an urgent request or a specific concern please speak up now. Of course, anyone can download additional activities so even if an activity is not on this list, it still attracts a lot of users. We need help testing these with the latest 8.2 image. We plan to make a release candidate today and if it passes smoke test we will add the activities and content to create a signed release candidate on Monday! Developers, Please reply with the final version and URL of each activity which we should include in the image. Each one must pass final test and have an active and reachable developer to make the final list. Morgan, can you make sure we have a contact e-mail and name on each of these? Also, let me know if you any of them are orphaned or not well maintained. All, Please test them all one more time let us know how it goes. I want to know if each of these passes the tests described here: http://wiki.laptop.org/go/Test_cases_8.2.0#Activities Please create a new test case for any activity that needs one. To do that, go to this page: http://wiki.laptop.org/go/Form:Test_case and entering Tests/Activities/nameofactivity to create a new test case. Then choose activity from the drop down and you can just paste in the steps test from above for a start. Then you can add a test result by clicking on the + sign next to the test case (it takes a little while for them to show up after creation). You can also e-mail comments or test results back to this list. Thanks a lot for your help. Thanks, Greg S ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel -- The water won't clear up 'til we get the hogs out of the creek. -- Jim Hightower ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] G1G1 Pre-installed Activities Request for Help Testing
On 20 Sep 2008, at 01:42, jean piche wrote: The only significant change from the original G1G1 set is the TamTam. I think we should include 2 not 4 so as not to over weight them against other activities. Let me know if anyone has comments on that (Jean can you live with that?). Yes. However, I think Mini and Edit would be my picks. Your call. Oh I think Synthlab is great! Think of all those budding sound engineers! I know it currently (using ~8.2) starts to stutter if you hit more than a few keys at once and wave the mouse about, but it's makes some great sounds through an amp if your gentle on the keys. :-) --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] G1G1v2 Activities
On 19 Sep 2008, at 22:50, C. Scott Ananian wrote: On Thu, Sep 18, 2008 at 10:01 PM, Gary C Martin [EMAIL PROTECTED] wrote: However, any hints would be much appreciated as to what this last remaining setup.py WARNING is trying to tell me? WARNING:root:bundle_name deprecated, now comes from activity.info I've not had much luck tracking it down, and I make no reference to bundle_name in my code. When you call BundleBuilder in setup.py, don't pass in a string in the constructor, leave it empty. It interprets the argument as a 'bundle_name' and is complaining that it's going to ignore what you passed in and use the name specified in activity.info instead. Yes, it took me a *long* time to finally realize this. --scott And just like magic, the warning has gone. Thanks scott! Does anyone disagree with me modifying pages I find on the wiki that show this (incase there is some side effect I am unaware of)? So where I see: bundlebuilder.start(HelloWorldActivity) I'd edit to: bundlebuilder.start() --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] G1G1v2 Activities
Here are my top 10 ranking, (with the next 10, if assuming some basic required packages) Journal Browse Write Record Paint Maze Calculate Pippy Physics (or x2o) Measure Implode Speak Memorize TamTam Moon XaoS Read Help Terminal XoIRC My criteria is basic activities or younger children exploring, and as the user 'masters' those activities... which activities would be next in the development/adventure/discovery/coolness/learning process. :) These are my close running 21st place :) StarChart eToys TurtleArt Chat Watch and Listen (Helix media player) WikiBrowse - SPOILER ALERT Below is my own informal tally so far, :) Record 10 Browse 9 TamTam 8 Write 8 Paint 7 Pippy 6 eToys 6 Measure 5 Speak 5 Read 5 Physics (or X2O) 5 TurtleArt 5 Chat 4 Journal 3 Memorize 3 Help 3 Terminal 3 Moon 2 Distance 2 Firefox 2 SimCity 2 XaoS 2 Frotz 2 Implode 2 Watch and Listen (Helix media player) 1 Acoustic Tape Measure / Distance 1 XoIRC 1 Memory 1 Maze 1 Calculate 1 Ruler 1 StarChart 1 Bridge 1 Words 1 Tumbleboy 1 PlayGo 1 Clock 1 GCompris Chess 1 GCompris Sudoku 1 StarChart 1 ePals 1 WikiBrowse 1 WikiBrowse Spanish 1 FYI, some people assumed basic Activities would be included no matter what: . . like Journal, Browse, and Help, Terminal. Cool ! :) -iXo ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] G1G1v2 Activities
On Wed, Sep 17, 2008 at 2:54 PM, Greg Smith [EMAIL PROTECTED] wrote: Hi All, We need to pick the activities we ship with 8.2 when its manufactured for G1G1 users. Management needs to sign off on the final list as early as next week. Its not definitive but we want your input on what we should include. What do you think are the most important activities to include? Please pick up to 10 and put them in order of priority. We will tally the votes and use that as input to the decision. Thanks, Greg S PS this is not a scientific voting system like used recently in the sugar vote. I accept Arrow's impossibility theorem (http://en.wikipedia.org/wiki/Arrow%27s_impossibility_theorem) and my math foo is weak so I'm not going to try and justify the methodology. 1. Measure 2. Etoys 3. Turtle Art with Sensors 4. Scratch 5. xo-get 6. Dr. Geo II 7. E-Paati/E-Paath 8. Record 9. TamTamJam 10. TamTamSynthLab There are several others that I can't recommend until I try them, or some other features are added. E-Pals is at the top of that list. -- Don't panic.--HHGTTG, Douglas Adams fivethirtyeight.com, 3bluedudes.com Obama still ahead in EC! http://www.obamapedia.org/ Join us! http://wiki.sugarlabs.org/go/User:Mokurai For the children ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Ideas for Journal: How epiphany browser manages bookmarks just with tags
Eben Eliason writes: On Fri, Sep 19, 2008 at 3:59 PM, Eduardo H. Silva hoboprimate at gmail.com wrote: 2008/9/19 C. Scott Ananian cscott at laptop.org: Eben, Eduardo, and I have been chatting about this some over IRC. What I find most interesting here is how *filesystem paths* (well, URL paths in this particular case) are integrated with tags. It's more than interesting. Solving the path problem is critical. Paths allow compatibility with the world, including the laptop itself. They are also a decent way to organize things, far from perfect yet Superior to the overflowing inbox. BTW, I'm delighted to see some serious consideration of the issue. If you accept that tags can sometimes be ordered, so that a/b is different than b/a (although both will show up on searches for 'a' and 'b'), then this starts looking more and more like a way to view filesystems as well, for those old enough to want to do that. ... So I agree that some kind of containerization is needed, but not in the form of a/b being different than b/a, but by using virtual folders or saved searches which would effectively act as virtual folders, with specific tags, search terms, object types, even a period of time if you wished. The case of b/a being distinct from a/b is necessary. You may call it a necessary evil, but in any case is is necessary. The question then becomes: Is the alternate method good, and is it good enough to implement despite any user confusion and performance issues that may exist? Perhaps there should be a mode switch, with regular filesystems (USB stick, SD card, /, $HOME, /tmp) being visible only when in ordered mode. The real question (I didn't overlook this!) regarding the concept of virtual folders (or, more specifically, saved searches) is whether or not they are dynamic. That is, does the saved search represent an expression or a value? My above tag idea is only valid, of course, when they are represented in value form. For more power (but more complexity) one would store the search terms, filters, etc. and re-apply them on the fly to a growing list. I'm not sure which of these is more desired. They both have merits. If both work, then a mode switch could be made available. Note that work means scalability for both CPU time and RAM. On the existing hardware, you need to handle 100 thousand files. On something like a regular PC you'll need to handle a million. That means O(log) scaling at worst, for both CPU time and RAM. If you have files in ~/Journal/Music/Bach/Disc1 and ~/Journal/Music/Beethoven/Disc1, you can search for 'Bach', 'Music Bach' as well as 'Bach/Disc1' or 'Music/Bach/Disc1' if you want to be specific. When you insert a USB key with files in a directory called 'Music/Mozart', they appear in the journal as if they were tagged 'Music/Mozart' and you can search for 'Mozart' or 'Music' to find them. When I copy them to my XO, the tags come with, and I have operations to retag groups of files that are the result of a search (which can look very much like groups of files which are in a specific directory). Yep, I think this is a good idea to move files from a hierarchical system to a non hierarchical system (the Journal) and still reuse the information contained in that first organizational system. Absolutely. This is a critical element which we need to make work when we flesh out support for external devices in the next release. This idea is the only solace I have been able to give to the many many people frustrated with the previous behavior of the devices in the Journal. Round trip ability (USB - XO - USB) is important. Losing all the directory info is no good. For the journal to be truly usable, it needs to support pretty much all that we ask of a filesystem. You'll know you're doing OK when you can build joyride out of the journal. (git works, gcc works, etc.) At the end of my pdf, I showed how epiphany creates a seemingly hierarchical bookmark menu. But it is only seemingly. Remember, there where 3 bookmarks tagged education and free software. Because these tags where so popular, they became top-level menus, and inside each of these menus, the same 3 bookmarks lived, in their own section because they shared an extra tag. This is a really powerful structure, and I think it's just the thing we need to make navigating the Journal more pleasurable (for those that really don't like the idea of searching). Getting the thresholds right for the number of items required to use a tag before it becomes top level will be a challenge (it should probably be based on a ratio to total unique tags). Give priority to tags (and anti-tags) which split the set of files most evenly. This greatly reduces search time; it is equivalent to balancing a binary tree. Thanks for sharing this. I think the ideas we're talking about should definitely be added to the list of future goals so we can work them in. It would be a big improvement. That's
