Re: [Sugar-devel] Sugar Print Queue and Device Icon
On Tue, Jun 23, 2009 at 18:42, Eben Eliason wrote: > On Tue, Jun 23, 2009 at 3:35 AM, Vamsi Krishna > Davuluri wrote: >> 2) It lists processing job on the top, and sorts >> the list accoring to first come first serve. > > Cool. Making the status gray would still be nice. What's the reason > for prefixing each with "Document" it seems unnecessary to me. I'd > stick with (title + '\n' + status). Actually, I guess you'd have to > have two labels, in order to make the status gray, and put those in a > VBox... You can actually do that inside the same gtk.Label, see how it is done for activity tags in the home view: http://git.sugarlabs.org/projects/sugar/repos/mainline/commits/014a004eb2a708bd368f494e98a6c3705495cf76 Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Better workaround for Xephyr keyboard problem seen running sugar-emulator (jhbuild run)
On Thu, Jun 25, 2009 at 00:16, Dan Krejsa wrote: > Hi, > > I've found what I think is a better workaround for the Xephyr problem seen > running sugar-emulator, in which keyboard mappings are not inherited from > the main X server. > > One workaround known so far is to go into the Terminal activity > and run > > setxkbmap us > > (or whatever keyboard map & options you want). However, that doesn't fix > all keys, > in particular it doesn't fix the arrow keys (at least for me). What does > work > is to execute, in a host shell outside of the sugar emulator, > > xkbcomp $DISPLAY :100 Any idea why it fails in Ubuntu Intrepid with: Warning: Could not load keyboard geometry for :0.0 BadAlloc (insufficient resources for operation) Resulting keymap file will not describe geometry ? Thanks, Tomeu > replacing :100 with the actual X display of the Xephyr X server; > $DISPLAY is of course the name of the encompassing X display in > which Xephyr runs as a client. This copies the XKB settings from > the encompassing display to the display under Xephyr. > > You have to run xkbcomp after having sent some keyboard events > to Xephyr -- if you do it before that, it seems not to work for some reason > that I don't understand well. > > That leads me to a really hackish patch to: > > sugar-jhbuild/source/sugar/bin/sugar-emulator > > adding a -k option that does the xkbcomp to copy the XKB settings to > Xephyr before starting sugar. The most awkward bit is that I had to > add code to put an ugly little window in the Xephyr server waiting for an > initial keystroke before calling xkbcomp. I know very little about X; maybe > someone can figure out how to avoid that bit. > > If you use the patch, start sugar-emulator as follows: > > $ ./sugar-jhbuild run sugar-emulator -k & > > Briefly tested only under Fedora 11. Enjoy, > > [1] http://dev.sugarlabs.org/ticket/342 > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] FUDCon hackfest proposal: assessment
On Wed, Jun 24, 2009 at 13:11, Greg DeKoenigsberg wrote: > > I have scheduled two hackfest sessions at FUDCon. > > 1st session, Friday afternoon, from 2pm to 4pm. The goal is to get people > together, discuss the goal (spec for sharing assessment data) and get a wide > range of ideas. I'm sorry to have missed it. Here are some pointers to existing frameworks: The TeacherMate framework source code, checkout the classes.zip file linked there: http://pocketschool.stanford.edu/node/28 More about how it's used in: http://www.innovationsforlearning.org/about_teachermate.php http://www.innovationsforlearning.org/teachers_guide.php And I would also give a look at the administration activity in a recent version of GCompris, > 2nd session, Sunday from 10am onwards, will be hacking to get some of this > idea implemented. Hope to get there! Regards, Tomeu > Simon, Tony and I are all planning to be there. I hope we can get lots of > other folks there too, from various projects. > > --g > > -- > Computer Science professors should be teaching open source. > Help make it happen. Visit http://teachingopensource.org. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar and ebooks
On Sat, Jun 27, 2009 at 03:07, Bastien wrote: > Sayamindu Dasgupta writes: > >> ..and I just pre-released a FBReader Activity for SOAS and other >> Fedora 11 based builds (it may also work in other distro based builds >> - I haven't tested, but it won't work in anything else than x86 >> (32-bit) for sure ;-). >> >> http://dev.laptop.org/~sayamindu/experimental/FBReader-10.xo > > Great! Thanks (also thx for the comment on Teleread.) > > I just tested your FBReader.xo on sugar-jhbuild, but can't launch it. > I attach the shell.log. The relevant error message will be in another file in the same dir where you found shell.log. Regards, Tomeu > > > > -- > Bastien > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] datastore results inconsistency
On Fri, Jun 26, 2009 at 18:57, Daniel Drake wrote: > Hi Tomeu, > > I found the issue with the journal showing a duplicated entry after > hand-deleting a datastore entry. Thanks for looking at this. As we discussed on IRC, things are a bit more complex than I initially thought and we should rebuild all the index when we find that the disk contents don't match the index. Would be great if you could try these patches and see if the journal is more resistant in these cases: DS: http://shell.sugarlabs.org/~tomeu/rebuild_index_on_inconsistency.patch Shell: http://shell.sugarlabs.org/~tomeu/remake_cache_on_inconsistency.patch Thanks, Tomeu > It's an issue in the datastore, in the same function: DataStore.find() > > After your patch, we now weed out the entries that don't exist on-disk, > but we still return "count" items (which is not adjusted accordingly) > > My suggested fix: decrement count in the loop if the file does not > exist. > > for uid in uids: > if os.path.exists(layoutmanager.get_instance().get_entry_path(uid)): > metadata = self._metadata_store.retrieve(uid, properties) > entries.append(metadata) > + else: > + count = count - 1 > > Daniel > > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
2009/6/21 Edward Cherlin : > We have about 60 characters worth of blank space in every Journal > entry. It would be a great help if we could display 40-50 characters > from the description field for each entry on the main page. We could > also drop off the word Activity from every Activity name. Are you sure that the description is the best use of the available space? I was thinking about displaying the tags beneath the title Would that work for you? Regards, Tomeu > I am going to create dozens of lesson plans in Turtle Art soon, and I > would like not to have to fish for them. The search field helps, but > is not enough. Eventually, we will have hundreds and perhaps thousands > of Turtle Art lessons, and likewise for Etoys, Scratch, Pippy, and a > number of other activities. > > -- > Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name > And Children are my nation. > The Cosmos is my dwelling place, The Truth my destination. > http://earthtreasury.org/worknet (Edward Mokurai Cherlin) > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Customizing a Master Stick
2009/6/21 Edward Cherlin : > On Sun, Jun 21, 2009 at 7:13 AM, Caroline > Meeks wrote: >> I have a cool USB Copy machine thanks to NexCopy. > > What is its capacity? Can some of us order sticks from you for schools > and demos? What do sticks cost in appropriate quantity? > >> My plan for FOSSED is to create a stick, download the extra activities, etc. >> I want, ideally add the manual pdf, and then de-personalize the stick and >> copy it. >> >> Walter showed me that rm -r .sugar will take a stick back to the state where >> it asks for your name. >> >> But it also clears the journal entirely. The activities I've downloaded are >> still there, but no longer in my favorites. > > I believe that .sugar/default/favorite_activities may be one of the > files you want to keep. I don't know whether > /usr/share/sugar/data/activities.defaults is significant for what you > want to do, but I suspect so. > >> I think I want to be a bit more selective. What should I delete to just >> remove the users name and colors, but leave the Journal. > > For this and other reasons, we need to document .sugar. For example, I > need to extract Journal entries created in SoaS running on VirtualBox, > where I cannot mount either a real or virtual USB drive. > > .sugar > debug (configuration) > default/ > cache/ > com.garcmartin.Moon/ > data/ > datastore/ > logs/ > nm/ > org.laptop.*Activity/ > buddy-icon.jpg > favorite_activities > owner.key > owner.key.pub > terminalrc > > And so forth. > >> Where do I look to see the Journal contents so I can delete that which I >> want to get rid of by hand. > > The org.laptop.*Activity directories have the structure > > org.laptop.*Activity/ > data/ > instance/ > tmp/ > > Files needed by the Activity are in data/. For example, Turtle > Art keeps the .png files rendered from the .svgs in > .sugar/default/org.laptop.TurtleArtActivity/instance/. > That way it doesn't have to render them every time it starts. > > Journal entries are encoded in .sugar/default/datastore/. > > Presumably someone could take some of the Python code from Journal and > create a Journal browser that operates outside Sugar, and lets > developers and teachers transfer Journal entries without having to do > it by USB stick every time. This shouldn't be hard, the DS format is explained here: http://wiki.sugarlabs.org/go/Development_Team/Datastore_Rewrite Torello has already coded a FUSE plugin that will allow mounting the DS to a directory in the root filesystem. Regards, Tomeu >> Thanks! >> Caroline >> >> -- >> Caroline Meeks >> Solution Grove >> carol...@solutiongrove.com >> >> 617-500-3488 - Office >> 505-213-3268 - Fax >> >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel >> >> > > > > -- > Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name > And Children are my nation. > The Cosmos is my dwelling place, The Truth my destination. > http://earthtreasury.org/worknet (Edward Mokurai Cherlin) > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] is olpcgames obsolete?
2009/6/25 Asaf Paris Mandoki : > Wondering around sugarlabs wiki I found the way to save the current state of > an activity to the journal here > > http://wiki.sugarlabs.org/go/Development_Team/Almanac/sugar.activity.activity > > The physics and x2o activities are based on olpcgames.activity which handles > reading/writing files to the journal in a rather strange way. Is olpcgames > obsolete? I think that rather than obsolete, it's unmaintained. > I've found much more documentation for sugar.activity than for > olpcgames.activity. Will it be a good idea to port the Physics activity from > using olpcgames modules to use the sugar modules? May be, though rather than the sugar modules, you would be using mostly PyGTK plus some of the widgets in sugar.* (optionally). I don't know pygames myself so I cannot directly answer your question. Regards, Tomeu > Greetings, > Asaf > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Introduction and question about introducing Sugar development
2009/6/26 Steve Dalton : > Hi All > > Just went on IRC channel - but no-one around - so I'll try here. > > Steve Dalton here from Gold Coast, Queensland, Australia. I'm an experienced > developer - mainly C/C++/Java/Groovy - but also dabble with Ruby/Python, just > starting out playing with Sugar development > > I was kindly donated 5 XOs a while back and I have been trying to get a bit > of a local OLPC developers group started here in QLD. Have young kids and my > (almost) 4 year old is already getting stuck into Sugar and working things > out which makes me think you guys are onto something really awesome - I'd > love to help in some way. > > Anyway - one way I think I might be able to stimulate some local activity is > by doing some sort of live demo on developing with Sugar. I was hoping to > demo something at Barcamp Brisbane next month and possibly something at the > OSDC (Open Source Developers Conference) in Brisbane later this year if it > works. I have made one of my paper submission for OSDC a Sugar one but It's > sitting in my drafts folder until I can be sure I have something that has > half a chance of working out (I like jumping in at the deep-end but don't > want to make a complete fool of myself). > > Does anyone have any good suggestions on what to do? I've done the Hello > world demo and had a look at some of the activities already developed... but > was hoping to do something a little more interesting with some "cool" value > to get people interested. Are there any canned demos or tutorials around that > anyone can recommend? Might give me some ideas. Not that I know, though my recommendation would be to check out how your kid is using Sugar and think of how the learning experience could be improved. Most experienced developers will be happier to help if it's something that addresses a real need than if it's something done out of pure curiosity. Regards, Tomeu > Many thanks in advance > Steve > > -- > I did have a signature, but the dog ate it. > > google:steve.dalton | skype:spidieman | msn: m...@steve.dalts.net | > yahoo:daltonsp | aol: spidie100 | twitter: @spidie | mynetfone:09203861 > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Loading videos onto a Sugar Stick for local access
2009/6/23 Caroline Meeks : > I'd like to put the videos that are on dailymotion onto my master stick so > that people at FOSSED will be able to view them even if internet is no good. > > Any idea how to do this? Had any luck with this? If not, please explain a bit more what you want to do. Regards, Tomeu > Thanks, > Caroline > > -- > Caroline Meeks > Solution Grove > carol...@solutiongrove.com > > 617-500-3488 - Office > 505-213-3268 - Fax > > ___ > IAEP -- It's An Education Project (not a laptop project!) > i...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Sun, Jun 28, 2009 at 20:13, Gary C Martin wrote: > Hi Tomeu, > > On 28 Jun 2009, at 09:59, Tomeu Vizoso wrote: > >> 2009/6/21 Edward Cherlin : >>> >>> We have about 60 characters worth of blank space in every Journal >>> entry. It would be a great help if we could display 40-50 characters >>> from the description field for each entry on the main page. We could >>> also drop off the word Activity from every Activity name. >> >> Are you sure that the description is the best use of the available >> space? I was thinking about displaying the tags beneath the title >> >> Would that work for you? > > +1 for tags beneath titles. > > I've just tried a quick mock-up to bounce around some ideas, Tomeu is there > a wiki page you're working from that this (and others) could go? Likely > needs more refinement but might a few more thinking on it :-) I'm afraid that would be quite a bit of work, right now I'm planning on just adding there the string as-they-are from the Tags field. But would be great if someone wanted to work further on tag entry and display. Regards, Tomeu > Regards, > --Gary > > > > > > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Mon, Jun 29, 2009 at 16:55, Aleksey Lim wrote: > On Sun, Jun 21, 2009 at 02:39:22PM -0700, Edward Cherlin wrote: >> We have about 60 characters worth of blank space in every Journal >> entry. It would be a great help if we could display 40-50 characters >> from the description field for each entry on the main page. We could >> also drop off the word Activity from every Activity name. > > maybe using several views > * one line view > * full view(multi lined view) > * thumbs > > btw I hope we'll decide to work on all these object list related > features in one place, now we have Journal, Library(partially implemented) > and not implemented Dairy(http://erikos.sweettimez.de/?p=742) Yup, I personally love the mockups at http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal . Other opinions? Regards, Tomeu > -- > Aleksey > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugarcamp - November 7th-12th 2009 ?
On Mon, Jun 29, 2009 at 16:55, Simon Schampijer wrote: > Hi, > > the SFScon 2009 will be held in Bolzano [1]. As part of that the TIS[2] > would be willing host a Sugarcamp. The camp would be part of the free > software week [3], where a GNOME Hackfest will happen as well. > > It fits quite well in our release cycle (0.88 planning/hacking) and > having the GNOME Hackfest next door would create nice synergies. We > would start on a weekend to have better chances on getting (students and > people who have to work during the week) everyone a chance to attend. > > How does that sound? Sounds great! Tomeu > Simon > > [1] http://www.sfscon.it/2009/ > [2] http://www.tis.bz.it/ > [3] http://www.freesoftwareweek.org/ > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Jaunty up and running
On Tue, Jun 30, 2009 at 10:41, James Michael DuPont wrote: > Hi all, > We have recieved two XOs from greece for kosovo and we have started the > translation process. > > I have finally gotten sugar running on jaunty and on my linpus, the problem > is with the logo load paths and the start commands for xhepyr > here are my hacks : Thanks to the nice guys on #sugar for thier help. > > http://ping.fm/vip4k > > http://ping.fm/66dXb > > http://ping.fm/b8s9t > > Here is our group page, with a link to the video proof :) > http://sfk2009.ning.com/group/onelaptopperchildkosova That shows you aren't using the Sugar theme (which would explain as well why you needed to do the icon path hacks), have you discovered why GTK2_RC_FILES isn't set? Regards, Tomeu > We would like to take this chance to invite you all to come to Prishtina on > aug. 29/30. > > Travel expenses for speakers are in the works, > call for papers is here : > http://docs.google.com/View?id=dg66p3sw_85ds8nbths > > Thanks, > mike > > -- > James Michael DuPont > Founding Board Member > Free/Libre Open Source Software Kosova > FLOSSK > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Marketing] Debrief of Sugar on a Stick v1 Strawberry launch for all teams
On Tue, Jun 30, 2009 at 12:12, Sean DALY wrote: > > * No OLPC briefing beforehand. > The authors of the key articles in this launch sought comment from > OLPC, who provided an odd statement from Professor Negroponte, odd > enough that it was heavily edited or truncated by the journalists. The > BBC published more of the quote than anyone, obliging us to respond > that NN hadn't understood the tech. The statement did not make sense > and was out of phase with what is currently under development, namely > a Gnome/Sugar choice of default desktop similar to Apple's OS9/OSX > solution of a few years ago. We are in contact with OLPC's PR people > so as to smooth bumps prior to launches; perhaps Adam Holt can help us > in this regard as well. First of all, congratulations on this enormous success! People not with us one year ago can read in this thread a bit about NN's views on Sugar: http://lists.sugarlabs.org/archive/sugar-devel/2008-April/thread.html#5307 Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [GSoC] I need help for Webified - SSB activity favicons
On Thu, Jun 25, 2009 at 02:56, Lucian Branescu wrote: > In case you don't know what Webified is > http://wiki.sugarlabs.org/go/Webified http://honeyweb.wordpress.com > > In short, I have added to Browse the ability to create SSB > (http://en.wikipedia.org/wiki/Site-specific_browser) activities. > > Since I'm generating activities, they need to have icons. After some > discussions, I have decided to use a .svg wrapper icon for all SSBs > that includes the website favicon. > > > I need to extract the favicon from a website and include it in the > .svg icon. Any thoughts? Can SVG images contain bitmaps? Because I guess that most sites will be using a PNG or GIF. > Right now, I'm doing > > > cls = components.classes['@mozilla.org/network/io-service;1'] > io_service = cls.getService(interfaces.nsIIOService) > ns_uri = io_service.newURI(uri, None, None) > > cls = components.classes['@mozilla.org/browser/favicon-service;1'] > favicon_service = cls.getService(interfaces.nsIFaviconService) > > favicon_service.getFaviconData(ns_uri) > > > But the last line throws xpcom.Exception: -2147221231. I haven't been > able to figure out what that error is. At this point, I would debug the mozilla side of things. It may seems like a pain, but may actually save you time when compared with trying things randomly. Another option is once you get the URI to download it (see nsChannel components). HTH, Tomeu > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Presence Service and Resume Behavior
On Tue, Jun 30, 2009 at 06:01, Eben Eliason wrote: > On Mon, Jun 29, 2009 at 11:03 PM, Benjamin M. > Schwartz wrote: >> Eben Eliason wrote: >>> On Mon, Jun 29, 2009 at 10:34 PM, Benjamin M. >>> Schwartz wrote: Eben Eliason wrote: > I know GroupThink does everything it can to prevent collisions, but > with this we should also be thinking about the worst case. The > intended baseline behavior (before we get into any fancy merging > libraries) was to allow two instances with the same activity_id but > different version_ids to run simultaneously, and be joined by any of > their participants, thus allowing manual copy/paste merging. The > instance left open last would then become, naturally, the most recent > and therefore the "agreed upon" version moving forward. Hmm. This creates a bit of a dilemma. In Groupthink, there is no such thing as a collision. You could say "collisions are not supported". Therefore, my model has been that different versions of a document should always be launched into a single shared session, where the data will be merged immediately and automatically. If the user wishes to create a separate branch not to be automatically merged with the existing document, she should create a copy of the journal entry with a new activity_id. (No, we don't seem to have a UI for that.) >>> >>> The most basic UI for that, as I see it, is a "Keep a copy" secondary >>> item under the Keep button. >> >> Yep. This is what I expected the "Copy" option in the Journal to do, but >> that copies to the clipboard. Two options, "Copy to Clipboard" and "Copy >> this Entry" would be necessary >> >>> If the system is designed to prevent different versions from joining into a single shared session, then perhaps this explains the observed behavior. It also entirely prevents automerging of offline work. >>> >>> I don't think they're incompatible at all. >> >> I think we agree that they are incompatible as currently implemented, and >> that any implementation that permits this sort of automerging looks >> substantially different from what we have now, as you detail. > > Yup. > >>> Hence, perhaps some need for asking an open activity instance if it >>> can successfully "merge" (whatever that means to the activity) some >>> other object handle its given. If success is returned, the merge >>> happens; if failure is returned, the shell opens the requested >>> activity normally. >> >> I do not think an "object-based" merge system is best for this purpose. >> It seems to me that such a system would prevent any online "negotiation" >> between the two sides. Things get dramatically uglier if you consider >> joining a session containing many members, but not the initiator. Which >> user gets to decide whether the new one can join, when all users are equal? > > The leaderless merge issue doesn't seem any harder than the basic > leaderless collaboration issue. But I might be missing some obvious > complications. The short of it seems to be that the activity would > have to elect a given client to handle the merge. > >> It's not exactly a beautiful solution, but I'd prefer a toggle in >> activity.info: automerge=True/False. If automerge is False or >> unspecified, then we retain the current behavior (for the sake of > > And because the current behavior is the "correct" thing to do if merge > can't be automatic anyway! > >> compatibility). If automerge is True, then different versions are always >> combined into a single shared session. > > I'd carefully word this as "always attempted to be combined"... > >> To support "unreliable merge", we can use a self.unshare() method. If the >> local activity process, after negotiating with other group members, >> decides that merge is impossible, then it may leave the shared session >> shortly after joining and return to private scope. >> >> How does that sound? > > This sounds almost exactly like what I was suggesting, but in the > opposite direction. I was proposing to ask the activity on the fly if > it could perform a merge (this method would return false if > unimplemented), returning false when it wasn't possible (after > whatever negotiation was necessary...this method could be async). > You're suggesting to first check a global constant defined by the > activity to see if it will even try to merge at all, and a second > fallback method to be called (by the activity) in the case of a > failure. Actually, I guess if it's async, our two methods are > basically the same, except that you suggest the addition of the flag > in .info, which seems like a reasonable enough idea, though not > strictly necessary. > > In any case, both seem roughly equivalent in terms of experience, in > which case I don't really care. =) Ben and Eben, do we have now a clear idea of where the problem lies and which API needs to be added to solve it? Thanks, Tomeu > Eben > > >> --Ben >> >> >
Re: [Sugar-devel] [Telepathy] Sugar Presence Service and Resume Behavior
On Tue, Jun 30, 2009 at 10:57, Guillaume Desmottes wrote: > Le lundi 29 juin 2009 à 22:12 -0400, Benjamin M. Schwartz a écrit : >> My GSoC project involves getting "offline collaboration" working. My model >> for this is that two users can join a shared session, then go offline, >> resume the session from the journal, continue working, and then later >> resume again when they are on the same network/server and have the two >> instances merge. In Groupthink, all of my algorithms are designed to >> support this. However, I have discovered that when two such instances are >> resumed, they do not connect to each other.* >> >> I believe the problem lies in the interaction between the Presence Service >> and the Datastore, and before I spend too many hours puzzling out how it >> works, I wonder if anyone could tell me what changes are likely to be >> necessary to achieve the desired behavior. From my limited understanding >> of the code, it seems that if an instance is resumed from the Journal, its >> unique activity_id might change, and this might prevent it from being >> correctly identified as an instance of an existing shared session. > > PS doesn't know anything about Journal or DS. He just allows you to > create activity, share it (using the D-Bus API) and discover shared > ones. > > I can't really tell you more as I never been involved in the Journal/DS > bits. > >> I also wonder what the status of the Presence Service rewrite/removal is. > > Mission-Control 5 was finally released (!) so it would be good to start > considering actually killing PS. Unfortunately, no body is working on > this afaik. Hmm, a crazy idea: how hard would be to cook a pygtk app that can run both inside Sugar and inside GNOME and have collaboration working? Or in other words: what would need to be changed in the Sugar shell, toolkit and PS so that we can support current activities and also new ones that don't use anything sugar-specific in their collaboration code? That could be a good step forward. Thanks, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [API proposal] toolbox.get_toolbars()
On Tue, Jun 30, 2009 at 04:55, Lucian Branescu wrote: > While adding the bookmarklet functionality to Browse, I realised that > the toolbox API is hard to work with if your toolbars change. For > example, set_current_toolbar() takes the index of the toolbar as a > parameter, something which you can't really know if your toolbars move > around. > > Tomeu suggested I propose to extend the toolbox API with a > get_toolbars() method. This method returns a list of the actual > Toolbar objects, in the order they currently have in the gtk.Notebook. > This method allows for things like if toolbar in > toolbox.get_toolbars() or toolbar_index = > toolbox.get_toolbars().index(toolbar), giving a lot more flexibility > in manipulating toolbars. > It could also kill off the ugly _TOOLBAR_FOO globals in Browse. > > I've made toolbox.toolbars a property for get_toolbars(). > > I have attached a patch to toolbox.py, in the sugar.graphics package. Could you please follow http://wiki.sugarlabs.org/go/Development_Team/CodeReview#Patch_guidelines ? I would also like to hear from the activity team (Gary?) if they have any objection to this API addition (I would like to see sugar-toolkit changes being driven by them at some point in the future). Thanks! Tomeu > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [API proposal] toolbox.get_toolbars()
On Wed, Jul 1, 2009 at 11:31, Aleksey Lim wrote: > On Wed, Jul 01, 2009 at 11:11:30AM +0200, Tomeu Vizoso wrote: >> On Tue, Jun 30, 2009 at 04:55, Lucian Branescu >> wrote: >> > While adding the bookmarklet functionality to Browse, I realised that >> > the toolbox API is hard to work with if your toolbars change. For >> > example, set_current_toolbar() takes the index of the toolbar as a >> > parameter, something which you can't really know if your toolbars move >> > around. >> > >> > Tomeu suggested I propose to extend the toolbox API with a >> > get_toolbars() method. This method returns a list of the actual >> > Toolbar objects, in the order they currently have in the gtk.Notebook. >> > This method allows for things like if toolbar in >> > toolbox.get_toolbars() or toolbar_index = >> > toolbox.get_toolbars().index(toolbar), giving a lot more flexibility >> > in manipulating toolbars. >> > It could also kill off the ugly _TOOLBAR_FOO globals in Browse. >> > >> > I've made toolbox.toolbars a property for get_toolbars(). >> > >> > I have attached a patch to toolbox.py, in the sugar.graphics package. >> >> Could you please follow >> http://wiki.sugarlabs.org/go/Development_Team/CodeReview#Patch_guidelines >> ? >> >> I would also like to hear from the activity team (Gary?) if they have >> any objection to this API addition (I would like to see sugar-toolkit >> changes being driven by them at some point in the future). > > In my case(writing activities for 0.82+) it doesn't make any sense to have > this patch in sugar-toolkit because its 0.86 feature. Moreover I did > similar thing in sugar-port(and use sugar-port wrapper instead of using > sugar-toolkit directly) > http://git.sugarlabs.org/projects/sugar-port/repos/mainline/blobs/master/activity.py#line312 How that line of code relates to the toolbar patch? Tomeu > -- > Aleksey > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Mon, Jun 29, 2009 at 18:14, Gary C Martin wrote: > On 29 Jun 2009, at 16:07, Tomeu Vizoso wrote: > >> On Mon, Jun 29, 2009 at 16:55, Aleksey Lim wrote: >>> >>> On Sun, Jun 21, 2009 at 02:39:22PM -0700, Edward Cherlin wrote: >>>> >>>> We have about 60 characters worth of blank space in every Journal >>>> entry. It would be a great help if we could display 40-50 characters >>>> from the description field for each entry on the main page. We could >>>> also drop off the word Activity from every Activity name. >>> >>> maybe using several views >>> * one line view >>> * full view(multi lined view) >>> * thumbs >>> >>> btw I hope we'll decide to work on all these object list related >>> features in one place, now we have Journal, Library(partially >>> implemented) >>> and not implemented Dairy(http://erikos.sweettimez.de/?p=742) >> >> Yup, I personally love the mockups at >> http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal . >> >> Other opinions? > > I like the intent, but I don't think the "activity centric" view has > concrete enough spec to consider implementing yet. There is just way too > much magic sauce in those mock-ups to my mind. The closest I've seen > something like this implemented, is with Apple's iPhoto, where imported > photos are auto arranged into single expandable "events" based on each > photos date/time metadata. You're given a couple of preferences for > adjusting the granularity (one event per week, one event per day, one event > per 8hrs, one event per 2hrs). Works quite well most of the time, you can > always manually merge two events into one, or split one event into two, if > it gets them wrong. I don't see that as so problematic. Activities are already saving the items that go to the Objects view, we just may need (or not) to remove some of the metadata and make them more document-like. About the Actions view, we have a baseline for activities that is "Worked on Paint for 15 minutes". But activities would be free to change that to whatever makes most sense. I can see how the shell would have a very hard time guessing how best to represent what the user did in activities, but activities have much more information and I think it's where we should put this logic. > I guess we could make the "activity centric" view work in the same way, a > fixed time slice that rolls up N hrs work into a collapsable/expandable > block that the user can custom name (and/or some auto name based on the > content). Not sure we would need that, but we could use Projects as containers ;) > The still raises lot's of questions, what happens when you resume some image > you painted from way back to take a quick look? Where does it now show in > activity centric view? Does it get removed from its old block positioning > and to some new active block; perhaps it get multi-linked so now appears > twice (you can still find it in the original old place and also find it in > new place)? I see past actions as immutable. In that case a new action entry would be added, and if the Paint activity wishes, it can label it "Looked at paint 'My house'" if it detects that no change happened. Or it can just not create any entry if it makes most sense from that point of view. > -=-=-=-=-=- > > The grid/thumb view should be a top level button, not as is shown buried in > a sub palette here: > > http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#09 > > I'd consider 2 primary view type buttons: > > 1). List view, just as we get now > 2). Grid view, much like as implemented in Library Sure, I don't see those mockups as a detailed spec for implementing right now, but I think they explain some very exciting ideas for moving forward. > -=-=-=-=-=- > > Having said all this, it seems sensible to pick a few solid Journal > improvements and just make some robust steps forward, like: Totally agreed! > - Showing tags under the title would be great (Tomeu, I will help where I > can) Hope to push my work on the journal treeview soon, then you can take it and do whatever graphics modifications you want. > - Batch entry modification (FWIW, don't like the tick box, that feels like > an old school html web form hack) Any alternative? > - Better Anything toolbar filter palette (use a grid layout to minimise > scrolling) Yeah, that will be great. I think Walter already submitted a patch to move the file types up. > - Perhaps a Tag toolbar filter palette (could be a mini tag cloud) Could you draw a quick napkin mockup to illustrate that? Thanks, Tomeu > Regards, > --Gary > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Wed, Jul 1, 2009 at 00:22, Aleksey Lim wrote: > On Tue, Jun 30, 2009 at 09:43:38PM +0200, Simon Schampijer wrote: >> Hi, >> >> in this week we want to talk about the Journal and datastore [1] >> improvements planned for 0.86. The Library activity [2] has shown some >> interesting concepts as well. What are the common goals, how to move >> forward, where to invest? > > Just some thoughts before meeting. > > For new Journal we have: > * action-centric view > * object-centric view > > In my mind they are quite different, > action-centric view relates to timelines when object-centric is more > like a browsing of objects(sort, tag them etc). > > So, what about using Library's code base for object-centric view? Have no objection to that, though we first need to see on which UI changes we agree for 0.86 and then we'll integrate the code as with any other contribution. Looking forward to discuss this further, Tomeu > -- > Aleksey > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [API proposal] toolbox.get_toolbars()
On Wed, Jul 1, 2009 at 11:44, Aleksey Lim wrote: > On Wed, Jul 01, 2009 at 11:38:51AM +0200, Tomeu Vizoso wrote: >> On Wed, Jul 1, 2009 at 11:31, Aleksey Lim wrote: >> > On Wed, Jul 01, 2009 at 11:11:30AM +0200, Tomeu Vizoso wrote: >> >> On Tue, Jun 30, 2009 at 04:55, Lucian Branescu >> >> wrote: >> >> > While adding the bookmarklet functionality to Browse, I realised that >> >> > the toolbox API is hard to work with if your toolbars change. For >> >> > example, set_current_toolbar() takes the index of the toolbar as a >> >> > parameter, something which you can't really know if your toolbars move >> >> > around. >> >> > >> >> > Tomeu suggested I propose to extend the toolbox API with a >> >> > get_toolbars() method. This method returns a list of the actual >> >> > Toolbar objects, in the order they currently have in the gtk.Notebook. >> >> > This method allows for things like if toolbar in >> >> > toolbox.get_toolbars() or toolbar_index = >> >> > toolbox.get_toolbars().index(toolbar), giving a lot more flexibility >> >> > in manipulating toolbars. >> >> > It could also kill off the ugly _TOOLBAR_FOO globals in Browse. >> >> > >> >> > I've made toolbox.toolbars a property for get_toolbars(). >> >> > >> >> > I have attached a patch to toolbox.py, in the sugar.graphics package. >> >> >> >> Could you please follow >> >> http://wiki.sugarlabs.org/go/Development_Team/CodeReview#Patch_guidelines >> >> ? >> >> >> >> I would also like to hear from the activity team (Gary?) if they have >> >> any objection to this API addition (I would like to see sugar-toolkit >> >> changes being driven by them at some point in the future). >> > >> > In my case(writing activities for 0.82+) it doesn't make any sense to have >> > this patch in sugar-toolkit because its 0.86 feature. Moreover I did >> > similar thing in sugar-port(and use sugar-port wrapper instead of using >> > sugar-toolkit directly) >> > http://git.sugarlabs.org/projects/sugar-port/repos/mainline/blobs/master/activity.py#line312 >> >> How that line of code relates to the toolbar patch? > > It was just an example, the idea is - adding new features to > sugar-toolkit API leads activity developers to write 0.86+ code > but having these features in libraries like sugar-port let them write > 0.82+ code. Sure, I have no problem with activity developers using sugar-port or whatever they find appropriate. We need to add new features to sugar-toolkit for the activity authors that need new stuff. If sugar-toolkit is not going to keep being improved, then people would be better off not using sugar-toolkit and just using sugar-port or whatever. If they use sugar-port and it is installed at the system-level, then we have something that is exactly the same as sugar-toolkit. If it is copy-pasted inside every activity, then sugar core developers won't be able to help activity authors debug issues in their activities and the first step to develop sugar activities will be a bit higher. I would say it's up to activity authors, though distro packagers might be also bothered to have to package duplicated code. But I think that activities shouldn't be packaged by distros anyway. Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Tue, Jun 30, 2009 at 19:02, Gary C Martin wrote: > On 30 Jun 2009, at 00:32, Michael Stone wrote: > > -- big snip from old thread --- > >>> - Better Anything toolbar filter palette (use a grid layout to >>> minimise scrolling) >> >> How do you think >> >> http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars >> >> would work out here? > > An 'Anything' filter button opening a palette with a grid layout of > filter options could work as is right now. It could be a relatively > small and contained code change, for a relatively large improvement in > usability. I guess (in Ebens toolbar mock-ups) a pop-up row could be > filled with the same filter options, but it would need to cope with > multi row layouts as the number of filter options grows over time > (i.e. as more Activities are installed). > > More generally regarding the toolbar mock-ups, some points needing > clarification: > > - Stop button must be visible at ALL times, none of these mock-ups > show a stop > - Activity collaboration control has disappeared, assume this should > be a primary icon > - No solution yet for textual names/labels (inventing unique and clear > icons is going to get real tough, real fast, and many Activity authors > already struggle creating decent activity icons). > - Activity title has disappeared from toolbar is that intentional to > rely on the naming dialogue every-time? Yup, I guess one more refining step would be needed to move forward. > Being Mr ActivityTeam at the moment, I do really worry about the > amount of work this is going to be to get Activities updated and > complying to a large toolbar redesign. Supporting both toolbar API > styles will help, but I think we'll end up with multiple toolbar > styles in different Activities for perhaps 6 months to a year or more. > That's a bad backward step for usability. Just look at the amount of > time/effort it is taking to migrate Activities over to SL > infrastructure, let alone making anything but minor maintenance code > changes to them. True, so what do you suggest here? Thanks, Tomeu >>> - Perhaps a Tag toolbar filter palette (could be a mini tag cloud) >> >> What do you think of Scott's journal2 design here? > > Technically? A massive redesign requiring a rock-star lead developer > and a long-term commitment to refine, debug, and stabilise over > several Sugar platform release cycles. There are nice ideas in there, > I particularly like the idea of turning directory paths into tags as a > way to access the file system. But, a much simpler option would be to > let a user type something like "/usr/local/..." in the existing > Journal search and have the Journal display a basic folders/files > view, typing just "/" would show the root level and a user could > navigate old school style from there. Copy/paste could be extended to > move content between Journal/file-system views, and external devices > could show the file-system view by default so a USB key or SD card > could be more easily managed. > > Regards, > --Gary > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Enhancing Activity updator
On Mon, Jun 29, 2009 at 17:35, Aayush wrote: > Due to large size of EPaath activity we r having trouble updating it, it > takes almost 15-20 min to update it using current updating technique > what we want to implement is , only download the changed portion of the > activity comparing the crc32 value > > and we are able to do that and significantly reduce the updating time ( > 3 min ) when we simulate updating outside sugar > > we r having trouble integrating that method into current sugar activity > update mechanism > > we want any of u to guide us where should we change in current > (Controlpanel -> Model -> updator.py) and place our code to implement > our ides > > i think > def download_selected_updates(self, progress_cb=(lambda n, row: None), > dir=None): in (Controlpanel -> Model -> updator.py) > is where i should satrt doing my thing ... > > where could i find documentation about current sugar activity update process The only person I know to be familiar with that code is Scott, thus adding him to CC. My recommendation is that you get yourself familiar with the activity updater code before you try to implement your ideas in a definitive way. As a first, read the code as you have already done and identify the most interesting methods. Once you have a model of how approximately things work, add some logging.debug calls and verify your hypothesis by seeing at which point those methods get called and with which parameter values. Once you have some idea of what to change and where, do some first changes (don't try to implement everything at once), then see if the modifications work as expected. Then repeat. If you are patient and persistent, you will notice how things that seemed before impenetrable start making some sense. That may not be enough to get you where you want to be at first, but keep on with the process and I'm sure that you will succeed. Good luck, Tomeu > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal and filenames on USB disks - more leases.sig problems
On Tue, Jun 30, 2009 at 19:41, Martin Langhoff wrote:
> I am trying to get leases.sig from the XS to the USB stick. On 8.2.x,
> Browse.xo saves the file as
>
> File leases.sig from http://...
>
> ... two possible ways to move next.
>
> Copy and rename
>
> 1 - Insert (fat-formatted) USB stick, once mounted copy the file to
> the USB stick. Check on Terminal indicates that the file has the LFN
> we expect ("File leases.sig from http://...";).
>
> 2 - Switch to the 'USB disk' view of the Journal.
>
> 3 - Rename the file to leases.sig . A check from the commandline
> shows that the file has not been renamed. Oops?. The Journal only
> renames the metadata. Bug?
>
> Rename and copy
>
> 1 - Rename the file in the Journal to 'leases.sig'
>
> 2 - Insert (fat-formatted) USB stick, once mounted copy the file to
> the USB stick. The Journal reports that the file is called lease.sig.
> From terminal I can see that the file is called lease.sig.txt . Bug?
>
> Is there a better way to do this?
If you go through the archives, you will find that this was discussed
some weeks ago, I think it was Tony Forster who started the
discussion.
And we have tickets in trac as well.
Regards,
Tomeu
> cheers,
>
>
>
> m
> --
> martin.langh...@gmail.com
> mar...@laptop.org -- School Server Architect
> - ask interesting questions
> - don't get distracted with shiny stuff - working code first
> - http://wiki.laptop.org/go/User:Martinlanghoff
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse.xo -- preserving a downloaded filename?
On Wed, Jul 1, 2009 at 12:02, Martin Langhoff wrote: > On Tue, Jun 30, 2009 at 7:46 PM, Martin > Langhoff wrote: >> We need a file manager IMHO. > > Michael asks about this specific statement, as it is fairly broad. > Let's keep it in the context of "it is worth fixing bugs that mangle > filenames" so the Journal can indeed double up as a passable (if > limited) file manager :-) > > "We need to do some file management sanely". > > Not an easy line to walk, but doable. As I just said in another thread, please check for the current plan in the archives and let's move from there so we don't have to repeat everything again. We'll also need people who want to carry the plan forward instead of just shouting "OMG! Sugar developers stole my filesystem!" Michael's suggestion is quite practical, and we also have Browse and control panel extensions where to place code to deal with the download and the installation of lease files. Regards, Tomeu > cheers, > > > m > -- > martin.langh...@gmail.com > mar...@laptop.org -- School Server Architect > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [API proposal] toolbox.get_toolbars()
On Wed, Jul 1, 2009 at 15:18, Lucian Branescu wrote: > Sorry about that. I've attached another patch which follows the guidelines. > > I'm not sure I should be opening a ticket about this, though. I've had > a chat with Walter last night and he said that since the toolbar will > get a re-haul in 0.86, it's a chance to improve the API as well. If we really manage to implement that feature for 0.86 (the design is not agreed on as of yet), the API will have to be a separate addition because we'll need to keep both the old tabs-based toolbox and the new one as not all activities will be able to move to the new one at the same time. That said, your patch seems clean enough to be added now and the fact this API is going to get deprecated makes it easier to add API to it. Regards, Tomeu > 2009/7/1 Tomeu Vizoso : >> On Tue, Jun 30, 2009 at 04:55, Lucian Branescu >> wrote: >>> While adding the bookmarklet functionality to Browse, I realised that >>> the toolbox API is hard to work with if your toolbars change. For >>> example, set_current_toolbar() takes the index of the toolbar as a >>> parameter, something which you can't really know if your toolbars move >>> around. >>> >>> Tomeu suggested I propose to extend the toolbox API with a >>> get_toolbars() method. This method returns a list of the actual >>> Toolbar objects, in the order they currently have in the gtk.Notebook. >>> This method allows for things like if toolbar in >>> toolbox.get_toolbars() or toolbar_index = >>> toolbox.get_toolbars().index(toolbar), giving a lot more flexibility >>> in manipulating toolbars. >>> It could also kill off the ugly _TOOLBAR_FOO globals in Browse. >>> >>> I've made toolbox.toolbars a property for get_toolbars(). >>> >>> I have attached a patch to toolbox.py, in the sugar.graphics package. >> >> Could you please follow >> http://wiki.sugarlabs.org/go/Development_Team/CodeReview#Patch_guidelines >> ? >> >> I would also like to hear from the activity team (Gary?) if they have >> any objection to this API addition (I would like to see sugar-toolkit >> changes being driven by them at some point in the future). >> >> Thanks! >> >> Tomeu >> >>> ___ >>> Sugar-devel mailing list >>> Sugar-devel@lists.sugarlabs.org >>> http://lists.sugarlabs.org/listinfo/sugar-devel >>> >>> >> > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Wed, Jul 1, 2009 at 15:43, Eben Eliason wrote: > On Tue, Jun 30, 2009 at 3:43 PM, Simon Schampijer wrote: >> Hi, >> >> in this week we want to talk about the Journal and datastore [1] >> improvements planned for 0.86. The Library activity [2] has shown some >> interesting concepts as well. What are the common goals, how to move >> forward, where to invest? >> >> All the people involved - please attend, would be awesome if UI >> designers would attend too. > > I'd love to join, though I'm not sure how much attention I can give > the meeting while at work. I'll try to peek in. During this weekend would work fine for me, as well. Alternatively, if we take good minutes we can have a productive thread on the mailing list afterwards. Regards, Tomeu > Eben > >> Regards, >> Simon >> >> [1] http://wiki.sugarlabs.org/go/Version_support_for_datastore/Proposal >> [2] http://wiki.sugarlabs.org/go/Activities/Library >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel >> > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Sugar Digest 2009-07-01
On Wed, Jul 1, 2009 at 18:21, Walter Bender wrote: > > 10. Fred Grose continues to keep watch over > [http://wiki.suagrlabs.org]. It remains a navigable site despite our > growth in content and diversity over the past year. > > 11. Thomas C Gilliard has added a Sugar VM > [http://www.vmware.com/appliances/directory/216653] to the Virtual > Appliance Marketplace. In the last weeks I have been impressed at Fred's and Thomas' work, big kudos! Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HelloWorld documentation in sugarlabs wiki
On Thu, Jul 2, 2009 at 10:13, Simon Schampijer wrote: > Hi, > > do we have those resources available on the sugarlabs wiki already? > > http://wiki.laptop.org/go/Activity_tutorial > http://wiki.laptop.org/go/Making_Sugar_Icons > > And I guess would be cool to get the hello-world example as well in git. If we are asking, I would also like to have these ones: http://wiki.sugarlabs.org/go/Low-level_Activity_API http://wiki.laptop.org/go/Python_Style_Guide Regards, Tomeu > Regards, > Simon > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Sugarcamp - November 7th-12th 2009 ?
On Wed, Jul 1, 2009 at 17:38, David Farning wrote: > On Wed, Jul 1, 2009 at 6:41 AM, Simon Schampijer wrote: >> On 07/01/2009 12:49 AM, David Farning wrote: >>> >>> On Tue, Jun 30, 2009 at 5:45 PM, Simon Schampijer >>> wrote: On 06/29/2009 10:09 PM, David Farning wrote: > > On Mon, Jun 29, 2009 at 9:55 AM, Simon Schampijer > wrote: >> >> Hi, >> >> the SFScon 2009 will be held in Bolzano [1]. As part of that the TIS[2] >> would be willing host a Sugarcamp. The camp would be part of the free >> software week [3], where a GNOME Hackfest will happen as well. >> >> It fits quite well in our release cycle (0.88 planning/hacking) and >> having the GNOME Hackfest next door would create nice synergies. We >> would start on a weekend to have better chances on getting (students >> and >> people who have to work during the week) everyone a chance to attend. >> >> How does that sound? > > Sounds good. > > Any one in mind to champion the event? > Do you have a point of contact with event organizers so we can start > working on the admin? >>> >>> I'll help. But based on LinuxTag you seem to have event organization >>> pretty much figured out. >>> >>> david >> >> The Sugarcamp will be a different event than Linuxtag. Linuxtag was a show >> where you have to setup gear and get promotion material together, the camp >> is more planning what you want to discuss during those days. > > Having participated in SugarCamp Paris and some FudCons. How do you > feel about the participant led format of the event? As long as we depend on individuals doing their work in an autonomous way, that's the best format IMO. The day we see it's not practical any more because we are too many people, I would like to see our community gathering in smaller, more local events instead of moving to big events in a very hierarchical way. Regards, Tomeu > FWIW, SugarCamp Paris was intentional in it's lack of pre-organization > to break from the 'Sage on Stage' broadcasting to the unwashed masses > nature of previous Sugar Labs meetings. > > Caroline and I have been working with http://www.aspirationtech.org/ , > one of the leaders in non-profit events. They have been a great help > is asses what we have been doing right and what we can improve in > upcoming meetings. > >> That time we have local help from the freesoftwareweek people, that I guess >> take care of the rooms etc. The actual work is then staying in contact with >> them regarding our needs, setting up a wiki, getting in contact with the >> GNOME organizers... >> >> I would like someone else to champion that (better two people so they can >> discuss things) - as I want to focus on 0.86. Should not be too time >> consuming, maybe a nice way to start contributing to the project. > > I'll start the admin stuff. > >> Thanks, >> Simon >> >> >> > > > > -- > David Farning > Sugar Labs > www.sugarlabs.org > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] customizing activity launch (was Re: [IAEP] View Slides an alternative to PowerPoint?)
On Thu, Jul 2, 2009 at 15:26, Bert Freudenberg wrote: > (moving to devel-list) > > Yes indeed, but we still have no obvious technical solution for this > in Sugar. > > Adding a pre-made project to the Journal might work, but currently it > would be resumed regularly and modified on stopping. It would need to > be marked as a template so that when keeping it, a copy is saved by > default. However, finding this template in the Journal would be hard. > > Making it into a separate activity bundle seems somewhat pretentious > to me, it would just be Etoys under a different name, right? And it > would suffer from the same resume-by-default problem like Etoys, in > that the Sugar UI makes it not easy enough to launch a fresh instance. Isn't this very similar to the site-specific-browser thing? Regards, Tomeu > Ideas welcome. > > - Bert - > > On 02.07.2009, at 14:51, Walter Bender wrote: > >> I still wish there was a >> launch-this-project-and-we'll-have-taken-care-of-steps-1–5-below-for- >> you >> Etoys bundle kicking around that we could just ship with the Journal. >> >> -walter >> >> On Thu, Jul 2, 2009 at 6:31 AM, Bert >> Freudenberg wrote: >>> Since this does not seem to be obvious: It's really simple to create >>> nice presentations in Etoys, there is not even scripting involved: >>> >>> 0. Start a fresh Etoys copy (in Strawberry, right-click the Etoys >>> icon >>> and choose "start" rather than resuming the latest project) >>> 1. click "new project" >>> 2. From the "supplies" box in the toolbar, drag out a "book". >>> 3. Use the top-left button to toggle more book controls >>> 4. Use the "+" button to add pages >>> 5. Place text on a page by dragging out a Text from the "supplies" >>> box, resize after right-clicking by dragging the yellow handle >>> 6. Import images either via the clipboard or directly from the >>> Journal >>> (using the Journal icon in the top right) >>> 7. Add annotations using the paint tool >>> 8. Add visual and sound effects for turning pages in the book's menu. >>> 9. Play with the options in the book's menu (like "view pages full >>> screen") etc. >>> >>> ... and of course you can place scripted objects / animations on the >>> pages too if you like. >>> >>> Also, the Etoys QuickGuides (accessible from the left-most button in >>> the toolbar) have an entire section on Books. >>> >>> - Bert - > > > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Datastore API changes (was: Re: Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting)
On Thu, Jul 2, 2009 at 15:10, Bert Freudenberg wrote: > > On 02.07.2009, at 14:52, Sascha Silbe wrote: > >> On Thu, Jul 02, 2009 at 11:52:01AM +0200, Bert Freudenberg wrote: >> [1] http://git.sugarlabs.org/projects/versionsupport-project/repos/mainline/blobs/master/datastore-redesign.html >>> How do you intend transfer of file ownership to be handled? >> >> checkout: >> * data store hardlinks entry into target directory >> * files read-only and directories read-write for activity (=> >> ensure link-breaking) >> >> Commit is similar, now mentioned in the document as well. > > That means the activity is responsible for deleting the file it > committed once the DS is finished? That's a burden on activity > developers the previous DS did care of. If at all possible, cleaning > up should be left to the DS. Also copying a file can be quite expensive, specially on the XO-1. If we are going to have a slow commit operation, we may need a way to get progress so we can expose it in the UI. Regards, Tomeu > Also "activities should not submit new entries while the previously > submitted one hasn't been fully committed yet" would be another > burden. If an activity needs to store a couple of items it would have > to queue the write commits and issue them one by one? That would be a > silly requirement, in particular since the DS needs to work on commits > simultaneously anyway (because two activities might commit at the same > time). > > - Bert - > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SoAS Testing with XS
On Thu, Jul 2, 2009 at 17:37, Greg Smith wrote: > Hi All, > > > > Has anyone tried testing Sugar on a Stick, Strawberry release with > collaboration? That is, are there any examples of SoAS computers seeing > other SoAS computers in the Network Neighborhood and then sharing > Activities? Hi Greg, this generally works but I'm pretty sure there are bugs in the Sugar layer that affect presence reliability. I want to work on this since a long time, hopefully this weekend will tackle it. > I’m interested in Jabber examples (on XS or other Jabber server) and “local” > examples where computers are on the same L3 network. Any links to > documentation or test cases is appreciated. > > > > This looks to be an important topic for the Gardner School deployment. > Caroline has already uncovered a bug in this area > http://dev.sugarlabs.org/ticket/1014 If anyone is up for working on it, we > can get more details and background on the bug report. That also interests me, will ask for more information when I get to it. Thanks, Tomeu > > > Thanks, > > > > Greg S > > > > > > > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Thu, Jul 2, 2009 at 06:08, Sascha Silbe wrote: > On Tue, Jun 30, 2009 at 09:43:38PM +0200, Simon Schampijer wrote: > >> in this week we want to talk about the Journal and datastore [1] >> improvements planned for 0.86. > > I really hope to make it (my GSoC work depends on it - there's a lot of > stuff to talk about and some decisions to make) but am not sure I can > (especially given how flakey internet access is ATM). Would be great to at > least be able to read the meeting logs afterwards (as usual). > > [1] contains my thoughts on a VCS based datastore rewrite - a bit fleshed > out now, but still not finished. The most important part for now is that I'd > like to change the find() API call to take two parameters instead of one. > Right now, the single parameter is a mixture of a query (giving key-value > pairs that entries must match to be returned) and of output options (sorting > order etc.). As we need to change API for version support anyway I'd like to > seize that opportunity to fix this mess (no offense intended). > > While the document currently mentions the index backend quite often I might > actually skip it at first and use only the database backend instead. Xapian > (an Information Retrieval system used by the current datastore to provide > simple metadata search) is very interesting and could be quite useful for a > future FindMyData activity - but IMO with a new API focussing on > probabilistic information retrieval, including spell checking and partial > queries (Xapian "term"s seem to correlate quite well with Sugar "tags", > BTW). The basic attribute search stuff currently used is IMO best done using > a database, not an IR system. > > The document is largely a braindump, not a design document yet. So please > overlook the rough edges and the fact that I'm proposing a full rewrite - I > might end up recycling a large part of the current code base, but thinking > of it as a "new" thing helps me see things more clearly. > > > [1] > http://git.sugarlabs.org/projects/versionsupport-project/repos/mainline/blobs/master/datastore-redesign.html There's lots of interesting stuff in there, will ask some questions today in a separate thread. Regards, Tomeu > CU Sascha > > -- > http://sascha.silbe.org/ > http://www.infra-silbe.de/ > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQEcBAEBAgAGBQJKTDKsAAoJELpz82VMF3Da9j4IAKPAS8n/UAOn2Anqoq+RqtHF > Ez1g5CUG+3q4yS5bwpwBGRWu1pEvT+GIrr+lXLsloSGtidApfopIhVIOmNR3wGHn > F3cPLPjcsdoosqWAMdEC+TWpXAwNlLS5mSk4T8o/podUTqnaBnRT7W09DUaPF2L9 > 2oAfme73dyHpFplf9qARIZeWqFGEiDDN3H9tN6yQxY0laozLnTTwDn8OCqIzHcqR > VitMO8s979xO7MYsJzLC+4dXwcADKlPQQOqObcJyxfR7zb29ShkSl/W7Tv+AuAiD > S23qscIoT6/BAcxRdAlrczvxJtc500VwikzRDy1tuFVKHjpJxdOYROuFOqhRg8Q= > =sRau > -END PGP SIGNATURE- > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Questions about GConf and ORBit.
2009/7/3 Michael Stone :
> Dear sugar-devel, (and Tomeu and Simon in particular),
>
> I decided to spend a few hours this evening investigating the state of
> rainbow+sugar.
>
> My current results are based on tests performed in a Debian Squeeze chroot
> constructed according to the procedures I wrote down at
>
> http://wiki.sugarlabs.org/go/Development_Team/Chroot
>
> Today, these procedures wound up installing
>
> education-desktop-sugar 0.837
> python-sugar-0.84 0.84.1-1
> python-sugar-toolkit-0.84 0.84.4-3
>
> and a variety of other things.
>
> I then installed rainbow according to the source code installation
> instructions
> at
>
> http://wiki.laptop.org/go/Rainbow/Installation_Instructions
>
> and installed the sugar and sugar-toolkit patches:
>
> curl
> 'http://dev.laptop.org/git/users/mstone/sugar/patch/?id=71df9fadd59ea5cc08a414f5d25a0135395533e5'
> | patch /usr/share/pyshared/jarabe/view/service.py
> curl
> 'http://dev.laptop.org/git/users/mstone/sugar-toolkit/patch/?id=a65c8d2148ba5028437114049027e594238f2ed8'
> | patch /usr/share/pyshared/sugar/activity/activityfactory.py
>
> that Sascha and I wrote a few months ago.
>
> Then I ran
>
> touch /etc/olpc-security
>
> to tell sugar to try to use rainbow.
>
> Then, after commenting out a few lines in /usr/bin/rainbow-sugarize, (notably,
> handling of XAUTHORITY, .sugar/config, and TMPDIR), I ran into the following
> persistent activity-launch failure:
>
> (See attached log for full details; the interesting bit is excerpted below.)
>
> ---
> ...
> about to execve
> argv: ['sugar-activity', 'pippy_app.Chat', '-b', 'org.laptop.Chat', '-a',
> '5fb7b60ee4635e7e67161464dab772656c660274']
> env: {'SUGAR_BUNDLE_PATH': '/usr/share/sugar/activities/Chat.activity',
> 'SUGAR_SCALING': '100', 'LM_DEBUG': 'net', 'LOGNAME': 'sugar', 'USER':
> '10012', 'PATH':
> '/usr/share/sugar/activities/Chat.activity/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games',
> 'HOME': '/var/spool/rainbow/2/uid_to_home_dir/10012', 'DISPLAY':
> 'localhost:1', 'LANG': 'en_US.UTF-8', 'TERM': 'xterm', 'SHELL': '/bin/bash',
> 'TZ': 'UTC', 'SESSION_MANAGER':
> 'local/heat:@/tmp/.ICE-unix/21077,unix/heat:/tmp/.ICE-unix/21077', 'SHLVL':
> '2', 'ICEAUTHORITY':
> '/var/spool/rainbow/2/uid_to_home_dir/10012/.ICEauthority', 'SUDO_USER':
> 'root', 'USERNAME': 'root', 'SUDO_UID': '1000', 'SUGAR_ACTIVITY_ROOT':
> '/var/spool/rainbow/2/uid_to_home_dir/10012', 'SUGAR_LOGGER_LEVEL': 'debug',
> 'GTK2_RC_FILES': '/usr/share/sugar/data/sugar-100.gtkrc', 'SUGAR_BUNDLE_ID':
> 'org.laptop.Chat', 'DBUS_SESSION_BUS_ADDRESS':
> 'unix:abstract=/tmp/dbus-Yk6Co1qS9e,guid=fce2be94a630405102e085bc4a4d6a08',
> 'SUDO_COMMAND': '/usr/sbin1246589388.964848 DEBUG root: *** Act
> 5fb7b60ee4635e7e67161464dab772656c660274, mesh instance None, scope private
> 1246589388.975903 DEBUG root: Creating a jobject.
> Traceback (most recent call last):
> File "/usr/bin/sugar-activity", line 21, in
> main.main()
> File "/usr/lib/python2.5/site-packages/sugar/activity/main.py", line 140, in
> main
> create_activity_instance(activity_constructor, activity_handle)
> File "/usr/lib/python2.5/site-packages/sugar/activity/main.py", line 34, in
> create_activity_instance
> activity = constructor(handle)
> File "/usr/share/sugar/activities/Chat.activity/pippy_app.py", line 54, in
> __init__
> super(Chat, self).__init__(handle)
> File "/usr/share/sugar/activities/Chat.activity/activity.py", line 22, in
> __init__
> super(ViewSourceActivity, self).__init__(handle)
> File "/usr/lib/python2.5/site-packages/sugar/activity/activity.py", line
> 556, in __init__
> icon_color = client.get_string('/desktop/sugar/user/color')
> glib.GError: Failed to contact configuration server; some possible causes are
> that you need to enable TCP/IP networking for ORBit, or you have stale NFS
> locks due to a system crash. See http://projects.gnome.org/gconf/ for
> information. (Details - 1: Server ping error:
> IDL:omg.org/CORBA/COMM_FAILURE:1.0)
> 1246589389.150681 DEBUG root: _cleanup_temp_files
> Activity died: pid 21590 condition 256 data
> 5fb7b60ee4635e7e67161464dab772656c660274
>
> ---
>
> Based on this traceback and a quick round of Googling, it seems likely to me
> that at least one of gconf or orbit is assuming that human operators have only
> one uid.
>
> Hence two questions:
>
> 1. Do you know anything about such an assumption?
No, but I don't see that in the logs. What I see is one process trying
and failing to access GConf. Is there a GConf daemon running? Either
using Orbit or D-Bus? If so, what's the mechanism used by clients to
contact the daemon? Maybe an env var is missing?
> 2. Are more bleeding-edge versions of Sugar still using gconf-over-orbit?
Sugar is a normal GConf client in this regard. My understanding is
t
Re: [Sugar-devel] Questions about GConf and ORBit.
On Fri, Jul 3, 2009 at 16:06, Michael Stone wrote:
> Tomeu,
>
> Thanks for the prompt reply.
>
>>> Do you know anything about such an assumption?
>
>> No, but I don't see that in the logs.
>
> True.
>
>> What I see is one process trying and failing to access GConf.
>
> Agreed. Do you have any advice on how I might extract a better error message
> from it?
Nope :/
> (Or on what symbols I should breakpoint in gdb so that I can see what's
> happening?)
Have never needed to resort to that, but I would look at the GConf
code first, then breakpoint in the interesting funcs.
>> Is there a GConf daemon running?
>
> Yes, but it's running under the credentials of the owning user ("sugar")
> rather
> than the requesting user. (Hence my suspicions.)
Is a good suspicion, maybe something orbit or corba related? Though it
would weird to find such limitation at that level without a mechanism
to workaround it.
The message hints at TCP/IP for orbit, in that case the client and the
server may not even live on the same machine.
>> Either using Orbit or D-Bus?
>
> How can I tell?
See if the server process executable is in /usr and if so, which .deb
is installed.
>> If so, what's the mechanism used by clients to contact the daemon?
>
> Again, how can I tell?
See which .so links the client and if it's in /usr, which .deb is installed.
>> Maybe an env var is missing?
>
> Seems eminently plausible. Do you know of any env-vars that gconf-and-deps pay
> specific attention to?
Nope.
>>> 2. Are more bleeding-edge versions of Sugar still using gconf-over-orbit?
>
>> Sugar is a normal GConf client in this regard. My understanding is
>> that if it links to the D-Bus client library, it will use D-Bus. Orbit
>> otherwise.
>
> Okay, thanks. I guess I'll just have to dig out the source code.
Yeah, I think I would do that at this point.
Regards,
Tomeu
> Thanks,
>
> Michael
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Thu, Jul 2, 2009 at 03:40, Gary C Martin wrote: > On 1 Jul 2009, at 10:54, Tomeu Vizoso wrote: >> >> On Mon, Jun 29, 2009 at 18:14, Gary C Martin wrote: >>> >>> - Showing tags under the title would be great (Tomeu, I will help where I >>> can) >> >> Hope to push my work on the journal treeview soon, then you can take >> it and do whatever graphics modifications you want. > > Fab. > >>> - Batch entry modification (FWIW, don't like the tick box, that feels >>> like >>> an old school html web form hack) >> >> Any alternative? > > I see multi selection Journal operations as a more advanced (occasional use) > feature, so it would be OK not being directly visually exposed. So, no tick > box column (save all that space for useful information), instead use a shift > key modifier so that when clicking an entry its selection state is toggled > on/off (grey backing fill of the entry row). When hovering over (or right > clicking) a multi selected entry, display a new palette with just the > features that function on a multiple selection. "Erase" being the obvious > multiple selection command asked for in the past; the other useful multiple > selection function would be drag and drop for copying a batch of Journal > entries to and from external media (i.e. teacher comes back from the city > with a USB stick full of downloaded ebooks). gtk.TreeViews have multiple selection support. Would be very cool if someone could play with the several options and report back: http://www.pygtk.org/docs/pygtk/class-gtktreeview.html#method-gtktreeview--set-rubber-banding Some tweaking of the gtk theme may be needed to make it look right. >>> - Better Anything toolbar filter palette (use a grid layout to minimise >>> scrolling) >> >> Yeah, that will be great. I think Walter already submitted a patch to >> move the file types up. > > Yea, saw the patch from Walter, that alone should help even if we stall on > doing more. > > I have a mock-up I was experimenting with grid layouts, still tinkering, and > I can't think of a good 'filter' icon for the replacement button (a common > one seems to be a funnel shape) :-) > > The Journal filters for 'Anything', 'Anytime', the proposed 'Anyone', and my > below 'Tag' filters can all become toolbar icons (not text). This saves a > heap of toolbar space, and allows room for a couple more buttons on the far > right for 'Grid' and current 'List' view. Awesome, have high hopes about that. Regards, Tomeu >>> - Perhaps a Tag toolbar filter palette (could be a mini tag cloud) >> >> Could you draw a quick napkin mockup to illustrate that? > > > Sure, but don't think I'll have anything in time for the dev meeting. > > Regards, > --Gary > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] On datastore object IDs
On Thu, Jul 2, 2009 at 19:20, Martin Langhoff wrote: > On Thu, Jul 2, 2009 at 6:35 PM, Benjamin M. > Schwartz wrote: >> We've been talking a lot about how datastore version 3 (?) should be >> structured. I'd like to propose (purely to initiate discussion) that it >> be structured as follows: > > Slightly OT: Sascha mentioned a plan in the git list of using git as a > backend. I pointed out a few (serious IMHO) limitations in git. Even if git is not appropriate, I have found the following doc about git's design very useful in clarifying some aspects of versioned data repositories: http://www.newartisans.com/2008/04/git-from-the-bottom-up.html Regards, Tomeu > My general comment is: > > - apps will want to work on files larger than memory > - apps will want to mmap files > - apps will want to create/edit multi-file projects (ie: creating websites) > > those are complex constraints, but should be considered. > > > > cheers, > > > martin > -- > martin.langh...@gmail.com > mar...@laptop.org -- School Server Architect > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] On datastore object IDs
On Thu, Jul 2, 2009 at 19:23, Benjamin M. Schwartz wrote: > Walter Bender wrote: >> Use case: I send you a presentation that refers to objects in the >> datastore. I need to send you those objects too, but I would not like >> to have to use some additional layer of reference. > > Heh. We don't support inter-object dependencies. It's amazing how we > keep having the same discussion over and over, though: > > http://lists.laptop.org/pipermail/sugar/2007-April/002210.html > > Maybe this time we will come to the other conclusion? I'm still leaning in favour of self-contained bundles for both activities and journal entries. Both options have ups and downs but I think that the complexity of dealing with broken links/dependencies conflicts with our goal of simplicity. Regards, Tomeu > --Ben > > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] On datastore object IDs
On Thu, Jul 2, 2009 at 20:44, Eben Eliason wrote: > On Thu, Jul 2, 2009 at 2:21 PM, Benjamin M. > Schwartz wrote: >> Eben Eliason wrote: >>> On Thu, Jul 2, 2009 at 1:40 PM, Benjamin M. >>> Schwartz wrote: Eben Eliason wrote: If editing a Document's metadata produces a new Document, as befitting our Copy-on-Write model of versioning, then the process of editing the "associated_actions" field produces a new version. Therefore, every time an Action adds a Document to itself, the process of adding the back-reference would produce a new version of the Document, so only one Action would ever end up referring to one version of the a Document. >>> >>> Metadata is attached to the version, I believe. I don't think we >>> should be versioning metadata, so I don't think that it makes sense to >>> create a new version when changing the metadata. >> >> I don't see such a big distinction between the data and metadata. In >> fact, Activities whose state is easily represented as key:value pairs can >> put their entire state into the metadata, instead of storing it in a blob. > > Hmm, I do see a distinction, actually. Though Perhaps it depends on > the the type. As an example: > > 1. I make an image. > 2. I make several changes to this image over time, resulting in new versions. > 3. I decide that one of these intermediate images was meaningful in > some way, and desire to tag it accordingly. > > I definitely don't want changing the description, or the tags, on some > previous version to inadvertently a) make a new version and b) make > that new version the most recent (and therefore most exposed) version. > > Perhaps we need to bite the bullet and consider having both versioned > and unversioned metadata... I think so. I definitely see part of the state of an activity stored in the metadata (current page, current paint tool, etc). But we have also some metadata properties that are bits of info about that particular entry: author, title, tags, 'keep', etc. I think that we should be able to modify those ones without creating a new version. In fact, Ben's versioned prototype had all the blob and metadata versioned and we needed to make some properties non-versioned because of the intended user experience. Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Fri, Jul 3, 2009 at 11:01, Martin Langhoff wrote: > On Fri, Jul 3, 2009 at 5:29 AM, Gary C Martin wrote: >> Aleksey was keen to see any Journal mock-up work in progress I had, >> early as possible, so here's where I'm at :-) There's plenty to do >> still, images are intended to help bounce ideas about, poke at the >> grey matter between our ears, and get a feel for how things could (or >> not) be done: >> >> >> http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tollbar_and_palettes > > Very cool. I do agree the filter is very culture-dependent. > > On a similar vein, the 'tag' icon has no visual association with the > many tags on screen. If they had a similar shape, then it'd be easy to > connect, for users who don't recognise a "tag" and the (somewhat odd) > use of "tag" to mean "a bit of metadata on a digital resource". > > Wishlist: "show files by size" filter or option? I think that's a good idea. Could we have a ticket for it? And maybe also a shorter term one to display the file size somewhere? Thanks, Tomeu > If the Uruguay > experience is any indicator, a fact of life is that users after all > *will* hit: > > - problems with fitting files (large and small) in USB disks > > - problems with their Journal taking too much space > > - problems with installed Activities taking too much disk space > > cheers, > > > > m > -- > martin.langh...@gmail.com > mar...@laptop.org -- School Server Architect > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [Marketing] netbook as terminology
On Fri, Jul 3, 2009 at 18:03, Frederick Grose wrote: > On Fri, Jul 3, 2009 at 10:36 AM, Walter Bender > wrote: >> >> ... >> >> I don't know that we should decide to push a name change on the market. >> >> >> >> ... >> >> >> >> Even in the "developed" world, the Internet is not everywhere, e.g., most >> classrooms, and as much as it has been good for the service providers to >> pitch it as true, the cloud is not right solution to every problem. > > When we speak of netbooks, we can highlight Sugar's intrinsic ability to > network and collaborate without the Internet; so, not Internet-book, but > network-book! > > XO-1s do this by default, we should push this capability into any Wi-Fi > enabled device running Sugar. Getting there! http://blog.tomeuvizoso.net/2009/05/ad-hoc-wireless-networks-in-sugar.html Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Communicating project goals and Roadmap
On Fri, Jul 3, 2009 at 19:00, Frederick Grose wrote: > > On Fri, Jul 3, 2009 at 9:27 AM, Tomeu Vizoso wrote: >> >> 2009/7/2 Sean DALY : >> > I don't know Tomeu, what do you think? >> >> I sincerely don't know but I hope that someone will explain what they >> need from the development team to succeed. > > The idea is that *all* of Sugar Labs needs to think deeply about how we > develop the next stage of Sugar and Sugar Labs. What is most important to > refine and advance, and what important pieces need to be added. > > This seems to be a followup to the call for *Champions* to advocate for the > features needed to better serve our communities. Champions that can > integrate with the Design, Development, Activity, Education, Deployment, > Marketing, and other Teams. > > For example, see this discussion thread on the 'netbook' as terminology, > http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg05906.html, > and the suggestion to push ad-hoc wireless networking into a native feature > of Sugar. This would give Sugar a large, advantageous multiplier effect for > creating more pervasive networking to take advantage of our core feature, > collaboration. > > Powerful ideas please step forward... That's a good example, someone (several people?) have expressed in the past that creating ad-hoc networks would be of great value, and at some point I found some time and implemented it. Development being driven by the development team doesn't mean that only gets done what fancies us, we are always asking for feedback and can be convinced to spend our time on other people's ideas. Regards, Tomeu > --Fred > > > > ___ > IAEP -- It's An Education Project (not a laptop project!) > i...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Get Internet Archive Books Activity source code
On Sat, Jul 4, 2009 at 02:25, Jim Simmons wrote: > Version 2 of Get Internet Archive Books was released this morning. I > like this one a lot better than my first effort; it should be good > enough to use, not just criticize. I have put the source code tar.bz > on shell.sugarlabs.org in /upload/honey/GetIABooks, for anyone wanting > to package it up for distributions. What about asking the testing group in NZ to give it a try and report back? And after that would be cool to think about a deployment that can report further feedback. Regards, Tomeu > Thanks, > > James Simmons > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Sat, Jul 4, 2009 at 05:19, Eben Eliason wrote: > > It sounds like you're describing a NOT filter (eg. kind:text NOT > activity:terminal), though, which the current UI doesn't support, as > all of the filter options are combined with an AND. I think adding > boolean AND/OR/NOT controls to the filter UI would definitely > complicate things too much, but we could again support these kinds of > queries within the search field. Btw, we currently support this query format: http://xapian.org/docs/queryparser.html Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Fri, Jul 3, 2009 at 20:29, James Zaki wrote: > Perhaps this is a late reply, (I am yet to read the last 6 or so digests of > to 20+ that were in my inbox) > But I am always sensitive of little incremental additions that seem like it > would be useful. Totally agreed. We had to start with something before Sugar was in the hands of children, but now that it's widely used, we should avoid changing whole parts of it without user feedback. > I always try to think about the first time I used sugar. In particular, what > helped by being very simple. We see sugar evolving, and perhaps forget what > it was like that first time. Perhaps we should harass some friends and > families' kids who've not seen it, and get their feedback. SoaS is making very easy to start pilots anywhere, so I trust developers are going to have very good feedback in a short time. Simon is already using SoaS with kids in Berlin, for example. > If a child new to the sugar interface (XO or otherwise) feels bombarded with > options, it could make things harder. > Just my two cents I always voice on this. Yeah, we have had already feedback about the benefits of Sugar's "clarity". We shouldn't let those people down by indulging ourselves in featuritis. By this I don't mean that we should limit ourselves in improving Sugar, we know that there's a ton of stuff to improve and new features to implement, but if we try hard we are going to find ways to add those features without cluttering the UI. I'm very happy to read these recent threads because we are making enormous progress in devising how to expose powerful new features without raising the bar for new users. Thanks! Tomeu > In particular to the pictures, apart from the two identical cloud icons, > there are lots of activities in that dropdown. Has that always been so big? > To me that would be intimidating for the first user experience. > > James. > > >> >> Date: Fri, 3 Jul 2009 04:25:54 + >> From: Aleksey Lim >> Subject: Re: [Sugar-devel] Journal feature request--more data in main >> display >> To: Gary C Martin >> Cc: Sugar Devel >> Message-ID: <20090703042553.ga15...@antilopa-gnu> >> Content-Type: text/plain; charset=us-ascii >> >> On Fri, Jul 03, 2009 at 04:29:47AM +0100, Gary C Martin wrote: >> > On 2 Jul 2009, at 02:40, Gary C Martin wrote: >> > >> >> On 1 Jul 2009, at 10:54, Tomeu Vizoso wrote: >> >>> On Mon, Jun 29, 2009 at 18:14, Gary C Martin >> >>> wrote: >> >>>> - Better Anything toolbar filter palette (use a grid layout to >> >>>> minimise >> >>>> scrolling) >> >>> >> >>> Yeah, that will be great. I think Walter already submitted a patch to >> >>> move the file types up. >> >> >> >> Yea, saw the patch from Walter, that alone should help even if we >> >> stall on doing more. >> >> >> >> I have a mock-up I was experimenting with grid layouts, still >> >> tinkering, and I can't think of a good 'filter' icon for the >> >> replacement button (a common one seems to be a funnel shape) :-) >> >> >> >> The Journal filters for 'Anything', 'Anytime', the proposed 'Anyone', >> >> and my below 'Tag' filters can all become toolbar icons (not text). >> >> This saves a heap of toolbar space, and allows room for a couple more >> >> buttons on the far right for 'Grid' and current 'List' view. >> > >> > Aleksey was keen to see any Journal mock-up work in progress I had, >> > early as possible, so here's where I'm at :-) There's plenty to do >> > still, images are intended to help bounce ideas about, poke at the grey >> > matter between our ears, and get a feel for how things could (or not) be >> > done: >> > >> > >> > http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tollbar_and_palettes >> >> Some thoughts: >> >> * what about adding ultra compact list view for objects(not actions) >> like list view in Library[1] >> the purpose is, if user has lots of objects it could be useful idea to >> show as much as possible objects on one screen >> >> * having several column/grid layouts >> for example its very useful for books to have columns for author, >> genre, date; so, user can see the whole valuable info at once and sort >> objects by these columns; and so separate layouts for video audio >> etc. files >> >> * additional types
Re: [Sugar-devel] Datastore API changes
On Sat, Jul 4, 2009 at 13:09, Sascha Silbe wrote: > On Thu, Jul 02, 2009 at 03:10:44PM +0200, Bert Freudenberg wrote: > >> That means the activity is responsible for deleting the file it committed >> once the DS is finished? > > That's an open question: > > * TODO: who deletes the activity "copy" of the entry? > >> Also "activities should not submit new entries while the previously >> submitted one hasn't been fully committed yet" would be another burden. > > Looks like I need to define should/must/etc. for the final version of the > document. It's an advice, not a requirement. The intention is to avoid > having an ever-increasing backlog because the activity saves faster than the > datastore can process. > > BTW, tomeu: How does the current API signal an error like running out of > disk space? Is it just an unspecific "DBus call failed", resulting in an > unspecific "Keep Error" or is there some code in place I haven't seen yet > that handles special cases? The client side can know which python exception was raised in the server side and do whatever it can to best handle it. In all cases I know, that's just informing the user that some error happened while trying to save the work. What the shell does is monitor from time to time the amount of disk space free and notify the user of this condition when it gets below some threshold. Regards, Tomeu > CU Sascha > > -- > http://sascha.silbe.org/ > http://www.infra-silbe.de/ > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQEcBAEBAgAGBQJKTziAAAoJELpz82VMF3Dav9YH/R7jLLCKRylCs5E2AuBld5+Q > S2UFxtFJRTaVLivUPbg7b77yBABJojfjxKGfsCvAB+7tmVd4LPcyRCi1NVfG5UXS > 6LWX0l63QJoEaSNyE4Dk1YGPxshExfRtACYZuJpSVQsaW4DI4mceSKW1EYe7asBX > as2eujpH+YIXwcoTkMKaBD34BMeZzCrbtNzHp1H8iAMQbybJzc+h8/LvOgdF4uzM > gcsPFTFk+CLeHWjX9kRha5zzoMJwsf5RE9IBg82mYTP7vlkm660q2GSjXoH5Vvbq > 0rG+HJU2ScitmcGf4S5NNHmD124lHELNkiY8yH+l1wZxBlto4MEhq/wYkD3sKis= > =sjI4 > -END PGP SIGNATURE- > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Datastore API changes
On Sat, Jul 4, 2009 at 13:15, Sascha Silbe wrote: > On Thu, Jul 02, 2009 at 04:14:36PM +0200, Tomeu Vizoso wrote: > >> Also copying a file can be quite expensive, specially on the XO-1. > > That's the reason for these requirement: > > * data should be provided on the same FS as the Journal (for hardlinking) > * activities must not modify the entry they submit to data store before it > has been commited (and the activity notified about that) > * Python API may copy file if activity indicates it doesn't fulfill > this requirement > * activities must not modify the entry they received from datastore > * Python API may copy file if activity indicates it doesn't fulfill > this requirement > * VCS backend must not modify files that have been provided as input (for > commit) or checked out => link-breaking > * if the VCS doesn't support this, the backend needs to implement it > by copying Sounds good, it's pretty similar to what we have now other than transfer_ownership goes to the DS which then copies the file if it is false. I'm not sure there's much benefit to have the python API do the copy because the gio API already makes quite easy async I/O, so activities that cannot transfer ownership of the file could copy it before passing it to the DS and report the progress to the user themselves. I'm happy we are reviewing the API with Bert because he has giving this some thought already and because the current API was hacked to support these optimizations along the way. > I'm going to make extensive use of hardlinking. While a two-edged sword (if > the activity retains a directory entry to the file it can potentially change > the in-datastore "copy") it can also greatly reduce the amount of copying to > be done. Another risk could be leaking inodes if we get a too complex hard-link structure. Regards, Tomeu > CU Sascha > > -- > http://sascha.silbe.org/ > http://www.infra-silbe.de/ > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQEcBAEBAgAGBQJKTznBAAoJELpz82VMF3DakpcH/Asi25tyQ9CwMIoaOUKyO3Wi > dvWoUEXPQPbG6zYDPgAxXNEJ3vtPdEy5YVZhtzSsjHyBka2Cw8jRnpP1LWfoQr8E > 1k7lqr3QEmcMIGF6PAbPLukCc1ftG8VIJzWkH/P0A0D+qmd1MsGSeOEBHrvV7gSf > Q7KbWvA/qsc8HsE2T9Yt3vyZRlAPj8IiiHv/UUlg4adOe9WAke8eDtOaIUX6CbpZ > BBnK6Z0WXqX+L5pHKSn8hoH82pP5bEpLS5OO0+jRG0cS33E/ji5Cnphs7ENVXJzd > +dV1HeGrWQ8UQZYgPTpIrWJ+O2gPAwoFRE6H+X/0i9aoCZSywnx5O5qOsZIaxWw= > =6PRj > -END PGP SIGNATURE- > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] soas strawberry sha1sum?
On Sat, Jul 4, 2009 at 20:27, Sameer Verma wrote: > On Fri, Jul 3, 2009 at 1:32 PM, Sean DALY wrote: >> Sameer, in my experience sticks are not nearly as reliable as CDs in >> terms of loading a bootable image, apparently due to internal firmware >> and chip differences >> >> I believe Caroline was getting some failures even with identical make >> & model sticks in the Nexcopy mass loader. >> >> Sean >> >> > > Bummer! > > There are a few people here in Jamaica, who are interested in getting > Sugar onto computers in some of the richer/private schools. I was > hoping to do a SoaS demo. I'll try to CD route for now. More later... Not sure that's what you meant, by just in case would like to note that the reliability issues of some USB sticks doesn't mean that it's not a viable solutions in some scenarios. You may need a bit of luck with the usb stick model and the host computer hardware and BIOS, though. Regards, Tomeu > cheers, > Sameer > -- > Dr. Sameer Verma, Ph.D. > Associate Professor of Information Systems > San Francisco State University > San Francisco CA 94132 USA > http://verma.sfsu.edu/ > http://opensource.sfsu.edu/ > > >> On Fri, Jul 3, 2009 at 8:09 PM, Sebastian Dziallas wrote: >>> Sameer Verma wrote: I'm getting 41b08c93a65cc1e38286b9f8980f51528a36761d is this correct? I tried a usb stick, but keep getting bad or damaged partition at boot time. sameer >>> >>> Yup, it is: http://download.sugarlabs.org/soas/releases/SHA1SUM >>> >>> Bad or damaged partition errors? Maybe your USB key is broken? >>> >>> You could try burning the .iso image to a CD to see if it works there... >>> >>> --Sebastian >>> ___ >>> Sugar-devel mailing list >>> Sugar-devel@lists.sugarlabs.org >>> http://lists.sugarlabs.org/listinfo/sugar-devel >>> >> > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Marketing] [SoaS] The next Step: v2 Roadmap
On Sun, Jul 5, 2009 at 15:53, Martin Dengler wrote: > On Sun, Jul 05, 2009 at 12:51:22AM +0200, Sebastian Dziallas wrote: >> Hi everybody, >> >> so here it is, the Sugar on a Stick v2 Roadmap: >> >> http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Roadmap#Roadmap >> >> Feedback is appreciated, and as we've just entered brainstorming phase, >> please go ahead and shoot your ideas! :) More to come... > > For F12 (not beyond), what is the advantage of using RPMs to > distribute Fructose[1], given OLPC is not[2]? +1 to stop distributing activities as RPMs. Though we may need a RPM that when being installed downloads and installs some .xo files. Regards, Tomeu >> --Sebastian > > Martin > > 1. > http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Roadmap#Fructose_modules_.28F11.29 > > 2. http://www.mail-archive.com/de...@lists.laptop.org/msg19673.html > > ___ > Marketing mailing list > market...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/marketing > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Read Activity question (single page view)
On Sun, Jul 5, 2009 at 22:16, Gary C Martin wrote: > Hi Sayamindu, > > Saw some of your Read roadmap items today, and just wanted to ping and > ask how viable you think it would be for Read to support a single page > by page view for PDFs (rather than current continuous scrolling mode)? I think it should be pretty easy. Check out 'pydoc evince' for properties, methods, etc. > I've been thinking it would be better for memory consumption > (continuous scrolling has to have both pages rendered in memory as you > scroll over page boundaries), Not sure, I think evince pre-renders and caches several pages around the current one. One of the issues is that it caches the whole pages as pixmaps, and if the page is zoomed, that can mean huge pixmaps. See "Tile based rendering" in http://live.gnome.org/Evince/Roadmap . Regards, Tomeu > and also would be better for page by > page reading for many books, presentations (Sameer Verma mentioned > this in an IAEP mail today), and I'm working on some pdf materials > like the old adventure book stories, where you traverse different > pages in a non-linear way (works a bit like a point and click > adventure/escape-the-room type thing). > > Does evince support single page render mode? > > If you think it's viable, but don't have the time yourself, let me > know and I'll see if I can get something working here (never used > evince myself so wanted to check with you first before I head off down > a blind alley). > > Regards, > --Gary > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Background Screen Color for SoaS Activity
On Mon, Jul 6, 2009 at 06:19, Art Hunkins wrote: > The default color for the Sugar Activity screen seems to be set to light > gray. I'd like mine to be white. > > Is there any way to change this in my activity script? That looks good to me, perhaps ibox contains some other widget that is covering it completely? Regards, Tomeu > I tried: > > import gtk > > win = csndsugui.CsoundGUI(self) > ibox = win.box(False) > ibox.modify_bg(gtk.STATE_NORMAL, gtk.gdk.Color(0x, 0x, 0x)) > > where ibox = the entire screen. > > However this changed nothing. > > Anything fairly straightforward I could try? > > Art Hunkins > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Sat, Jul 4, 2009 at 17:55, Gary C Martin wrote: > On 4 Jul 2009, at 09:56, Tomeu Vizoso wrote: > >> On Sat, Jul 4, 2009 at 05:19, Eben Eliason wrote: >>> >>> It sounds like you're describing a NOT filter (eg. kind:text NOT >>> activity:terminal), though, which the current UI doesn't support, as >>> all of the filter options are combined with an AND. I think adding >>> boolean AND/OR/NOT controls to the filter UI would definitely >>> complicate things too much, but we could again support these kinds of >>> queries within the search field. >> >> Btw, we currently support this query format: >> http://xapian.org/docs/queryparser.html > > Hey cool thanks for the link – I didn't realise how much was silently > supported! The most I had been using was the occasional phrase search with > double quotes. > > Just to confirm; I take it that Xapians prefix maps haven't been used so far > in the Journal index implementation (i.e. title:Paint, description:meeting, > or tags:homework)? Point me at rep Sugar source if that's quicker (not sure > where to look to check this). That's not implemented as of yet, though I don't see any hurdle right now. What I should warn about is that the more information we give to xapian, the more sophisticated stuff it can do; but it will have a cost in disk space usage and may slow some operations. Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Mon, Jul 6, 2009 at 10:51, Sascha Silbe wrote: > On Sat, Jul 04, 2009 at 04:55:57PM +0100, Gary C Martin wrote: > >> Just to confirm; I take it that Xapians prefix maps haven't been used so >> far in the Journal index implementation (i.e. title:Paint, >> description:meeting, or tags:homework)? Point me at rep Sugar source if >> that's quicker (not sure where to look to check this). > > You're right on spot. The only prefixes used (but not defined for the query) > are: > > _PREFIX_UID = 'Q' > _PREFIX_ACTIVITY = 'A' > _PREFIX_ACTIVITY_ID = 'I' > _PREFIX_MIME_TYPE = 'M' > _PREFIX_KEEP = 'K' > > I.e. to search for all documents of type text/plain you can use the query > string "Mtext/plain", but not "mime_type:text/plain". Not quite, the association from mime_type: to M is doing when constructing the query: http://xapian.org/docs/apidoc/html/classXapian_1_1QueryParser.html#dfd545b4ac739adc2e4171169a500f33 And, from the docs, it does more than just appending M to the query string, as it can do things like author:"charles dickens" and title:(mice men). So to support that we just need to call add_prefix on the QueryParser for every field prefix. Regards, Tomeu > See [1]. > > I'd like to expose a better IR search facility in the future, but not within > 0.86 timeframe (there are several open, hard problems). > > > [1] > http://git.sugarlabs.org/projects/sugar-datastore/repos/mainline/blobs/master/src/carquinyol/indexstore.py > > CU Sascha > > -- > http://sascha.silbe.org/ > http://www.infra-silbe.de/ > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQEcBAEBAgAGBQJKUbsrAAoJELpz82VMF3DaRTAH+QFWfnGvagCl5Vw3ujZceInp > v4D7PKANidrP8+8GShMaeeXbN1eS7xO4pxEmcQsHqCpEnziS9LM6XGHuuHv67Ab9 > BNg+2FMSZbwnBvhK0ZHBclOKxzQZt20uNJywAb5DU4AkyqqGbAR6+KCrKWb4rpH9 > EjvZEQqTGVVrrj4HNMmHU7C7co++ftAlrTLK3jQs1qw0HHvxBZZgU5Y4SBjqPtM2 > v7c/Nb+NfP4wD5TZAonb9d4eCMf0dqWkgprWTzJ0/q0qLF8hh2bhHMbdF2jZC+YE > +cPPg6NLSiPcFkuHbTLkI5nuOervWpgV9anf6Wh/bXy33nMEjciHf2JtOL4AMcA= > =DwBt > -END PGP SIGNATURE- > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Marketing] [SoaS] The next Step: v2 Roadmap
On Mon, Jul 6, 2009 at 11:03, Peter Robinson wrote: Hi everybody, so here it is, the Sugar on a Stick v2 Roadmap: http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Roadmap#Roadmap Feedback is appreciated, and as we've just entered brainstorming phase, please go ahead and shoot your ideas! :) More to come... >>> >>> For F12 (not beyond), what is the advantage of using RPMs to >>> distribute Fructose[1], given OLPC is not[2]? >> >> +1 to stop distributing activities as RPMs. >> >> Though we may need a RPM that when being installed downloads and >> installs some .xo files. > > That sounds like a horrible hack to me. The whole point of RPMS is > that you can see before you install them exactly what your getting and > when you remove them you know that everything goes with them, I don't > know how its going to be possible to properly clean up something like > that on removal. I think there has to be a use of one or the other, or > a combination of the two where core activities are packaged as rpms, > or Activities that include binary bits that need to be compiled so > that its easy to support on various platforms. Yeah, I'm not 100% happy on that, but this seems to be a situation where the least evil needs to be found. The binary bits issue needs to be solved anyway on .xos (some of them are already multi-architecture), so only the scenario of an user trying out Sugar on fedora remains. About cleanup, .xos are expected to be self-contained so when packaged as .rpm shouldn't need any cleanup. If people want to package and maintain those as .rpms, I don't see any problem with that. But if we don't have enough hands for that, the alternative I proposed might be worth it (is actually what SoaS does when creating an image). Regards, Tomeu > Peter > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Datastore redesign
On Sun, Jul 5, 2009 at 22:32, Sascha Silbe wrote: > Hi! > > After reading the recent threads about Journal / data store and the IDs used > by them the big picture is much more clear now, thanks! > I've adjusted by datastore redesign proposal [1] accordingly and would like > to submit it for review now. > It's not clear a full redesign is The Right Thing to do now, but I'd rather > like to specify what it should look like, not what steps to take next > towards it. Agreed. I have to say that your proposal is excellent, congratulations! > There's an important design decision that's still open: > > Is the asynchronous API design useful enough to warrant more complex > implementation? I'm not sure, but I think that whatever decision we take should be made based on actual usage of the DS. What about proposing an example of how an existing activity would be modified to use the new API? > - DBus operations can be run asynchronously so UI responsiveness shouldn't > be > an issue > - For save() calls activity needs to wait for result (containing new > version_id) before it can invoke save() again for the same object > which can take quite some time if save() is sync - especially if other > activities are saving at the same time. What about having a separate call that returns synchronously a new tree_id and/or version_id? > Making the API fully asynchronous is the cause for much of the complexity of > my proposal, but if we eliminate the queueing the response times for write > accesses and checkout() can be very long even for unrelated operations. Why for unrelated operations? > [1] > http://git.sugarlabs.org/projects/versionsupport-project/repos/mainline/blobs/master/datastore-redesign.html Some comments and questions: # do we want an optimized way to determine (only) the branch HEADs of a given tree_id? This depends on the intended UI. My opinion is that if we branch at every interesting modification (triggered by the activity detecting an interesting change or by the user clicking on the Keep button), we would like to display in the object list all the HEADs of each branch in each tree_id. In that case yes, we need a way to retrieve that list that is fast on both the client and the server side. # using symlink instead of hardlink for "incoming" queue since we want to support directory trees, not just files What justifies this new requirement? I agree it would be nice to have, but I would prefer to start with the basics then grow step by step. We have had (several) cases before of overpromising datastores that failed to provide the bare minimum. # since an index rebuild can take a lot of time we need to provide UI feedback while doing that Any I/O operation can potentially take a lot of time, but with the current version of the DS rebuilding an index with a few thousands of entries is not so slow on the XO. We should never need to rebuild the index, so this new requirement might not be justified (given the current resources, all the other work we need to do, etc). # detecting identical files across objects isn't as important since duplicates are mostly expected to occur as versions of the same object Based on how current activities are using the DS, this isn't like that. The most common case I have heard from the field are children downloading a PDF for reading several times. An alternative to the current method for detecting duplicates is moving this task to activities, is that what you suggest? About the benefits of differential compression I would like to note that if you analize a real world journal, the biggest files are videos, mp3, pdfs, etc., so files in formats not easily editable with the activities we currently have. With that I don't mean is not an interesting challenge or something that we won't need in the future, just that it has a relatively low impact as of today. # activities should not submit new entries while the previously submitted one hasn't been fully committed yet Why so? # version_id and parent_id Have you thought about version_id being of the form of '2.1.4'? That would make parent_id unneeded because we could refer to the parent as (tree_id, 2.1.3). And would also allow us to identify the HEAD of each branch. # creator What is it for? # activity saves data to a disk, ensuring it has been committed (sync) and proper access rights for data store By sync you mean written to disk? Why activities need to worry about this? #Changes the (unversioned/version-specific) metadata of the given object to match metadata. Fully synchronous, no return value. How do we know which properties are version-specific and which aren't? # Remove (all versions of) given object from data store. Fully synchronous. Doesn't return anything, emits signal Deleted(tree_id). Do we have any operation in the UI that matches this? # Get/Got Maybe should we make it a bit more verbose? Like GetData? # Prefixing a key name with '!' inverts the sense of matching Is this us
Re: [Sugar-devel] [Marketing] [SoaS] The next Step: v2 Roadmap
On Mon, Jul 6, 2009 at 11:31, Peter Robinson wrote: > On Mon, Jul 6, 2009 at 10:13 AM, Tomeu Vizoso wrote: >> On Mon, Jul 6, 2009 at 11:03, Peter Robinson wrote: >>>>>> Hi everybody, >>>>>> >>>>>> so here it is, the Sugar on a Stick v2 Roadmap: >>>>>> >>>>>> http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Roadmap#Roadmap >>>>>> >>>>>> Feedback is appreciated, and as we've just entered brainstorming phase, >>>>>> please go ahead and shoot your ideas! :) More to come... >>>>> >>>>> For F12 (not beyond), what is the advantage of using RPMs to >>>>> distribute Fructose[1], given OLPC is not[2]? >>>> >>>> +1 to stop distributing activities as RPMs. >>>> >>>> Though we may need a RPM that when being installed downloads and >>>> installs some .xo files. >>> >>> That sounds like a horrible hack to me. The whole point of RPMS is >>> that you can see before you install them exactly what your getting and >>> when you remove them you know that everything goes with them, I don't >>> know how its going to be possible to properly clean up something like >>> that on removal. I think there has to be a use of one or the other, or >>> a combination of the two where core activities are packaged as rpms, >>> or Activities that include binary bits that need to be compiled so >>> that its easy to support on various platforms. >> >> Yeah, I'm not 100% happy on that, but this seems to be a situation >> where the least evil needs to be found. > > :-) > >> The binary bits issue needs to be solved anyway on .xos (some of them >> are already multi-architecture), so only the scenario of an user >> trying out Sugar on fedora remains. > > The issue there is that Fedora could be x86 or ppc, 32 or 64 bit > excluding some of the other secondary arches. Probably not too much of > an issue at the moment but with cheap arm based netbooks starting to > hit the market it could be something that needs to be addressed sooner > or later. Agreed, I think it was Aleksey who converted some activities to contain binary blobs for several architectures and choosing the right one at runtime. >> About cleanup, .xos are expected to be self-contained so when packaged >> as .rpm shouldn't need any cleanup. > > If they're proper rpms it should be fine but if there's a single rpm > that pulls .xos from somewhere I don't see how it can know how to > clean up given that after its installed there's nothing to say they > can't be updated manually or through the control panel. Hmm, true. It would need to check that it deletes only the versions it installed. >> If people want to package and maintain those as .rpms, I don't see any >> problem with that. But if we don't have enough hands for that, the >> alternative I proposed might be worth it (is actually what SoaS does >> when creating an image). > > I think its worth packaging the core activities as rpms such as > read/write/record/speak etc to allow easy testing upstream to make it > easy for testing regressions like we discussed at Fudcon. For the rest > of the activities it might be worth looking at something like an > activity bundle rpm or something similar. Yeah, I like that one as well, I guess a script could make it quite easy to update. Regards, Tomeu > Peter > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Jaunty up and running
On Sun, Jul 5, 2009 at 20:25, James Michael DuPont wrote: > Sascha, > It build and installed all according to the instructions. > I dont have this all here at the moment as I said. If you have any > questions, you can see my build snapshot, that contains everything. > I have put 2 days of work and finally got it running on ubuntu, you can see > the patches. > > You can find many bug reports of sugar on ubuntu and others. I dont know of > anyone who sugar works. Everyone who tried the packages complained of > problems. > > How come this is so difficult? How come you guys dont test the packages > yourself? > Installing ubuntu takes about 30 minutes. You can run it it on a virtual > machine. There was a team of people working on Sugar on Ubuntu, but they didn't had the needed resources and stalled before the 9.04 release. I don't know if getting something packaged for Ubuntu is very hard but Aleksey has packaged Sugar 0.84 for several distros by himself: http://wiki.sugarlabs.org/go/Development_Team/Packaging Could you update that table with your opinion on the Ubuntu status? > Can you tell me of sugar working on any distro out of the box? > are there any success stories? By that table, all distros except Arch Linux and maybe Debian are working, but maybe we need people to actually try them out and update the Status column? > I really cannot find anything on ubuntu except wiki pages that are out of > date. > Sorry, but this is very frustrating. It's also frustrating for me that my work is not available in such a popular distro as Ubuntu, but work won't get done until someone rolls up her/his sleeves. Regards, Tomeu > thanks > mike > > On Sun, Jul 5, 2009 at 6:20 PM, Sascha Silbe > wrote: >> >> On Sat, Jul 04, 2009 at 05:43:38PM +0200, James Michael DuPont wrote: >> >>> The report is with jhbuild on debian jaunty. I built it from scratch. >>> Started with jhbuild run >> >> I guess you mean Ubuntu Jaunty. How did you build? Can you give the exact >> commands you used to build and run, please? What does "./sugar-jhbuild >> depscheck" say? >> >> >> CU Sascha >> >> -- >> http://sascha.silbe.org/ >> http://www.infra-silbe.de/ >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.9 (GNU/Linux) >> >> iQEcBAEBAgAGBQJKUNK5AAoJELpz82VMF3DaLTEH/16qsq91tQXDkjEXqDZNyZ64 >> vtVfD/4qw2DYLQXrXyAnnTyng0JiS7jUGrktPeD2bh5K+pGWuMv+K7f9wEP1l8t8 >> lztCXwx/bquw/5h3N7my/ERPNa4pCyiflwLNuHSnnFNv39WEt49Jazfz3eGZFOJp >> 3g7dk+Aw1NVW32Sxk4obvy7ZzEBK78kuDdgd9pe8PcXkQ4js58GDjKWVgYeWu257 >> FNnrPsJQtCaPLamdmHmcznExO/NAJCBp1X9/fqDTcc6cQ5xGpbIxCEug0Op/qaM3 >> 4/gp7CLPDVmV5uJdeycAO1J2CrpMCSqGZGhzclTcOixA0NbBXysg3u7ei67NMrI= >> =0g20 >> -END PGP SIGNATURE- >> > > > > -- > James Michael DuPont > Founding Board Member > Free/Libre Open Source Software Kosova > FLOSSK > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] issues showing Activities for OLPC 8.2.x from a.sl.o.
On Sat, Jul 4, 2009 at 05:17, S Page wrote: > > Many thanks, I hope my comments are useful. > Who thought of using the addons.mozilla.org codebase for a.sl.o? > Stroke of genius! The earliest reference in my inbox is in an email from J5 (John Palmieri) on March 2007. Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] issues showing Activities for OLPC 8.2.x from a.sl.o.
On Mon, Jul 6, 2009 at 13:23, Walter Bender wrote: > I spoke to Chris Blizzard (Mozilla, formerly Red Hat) about our using the > AMO codebase. He seemed pretty pumped up about it. I am sure he can > facilitate any navigation within the AMO team if necessary. That's cool, though from my observer POV seems like Aleksey is doing pretty well for now. What worried me for a bit is the maintenance of PyXPCOM, which is fundamental for hulahop and Browse. Though seems like the people at ActiveState are going to be taking maintenance in the near future. We may need help at unstucking the process, though. Will report back later. Regards, Tomeu > -walter > > On Mon, Jul 6, 2009 at 6:55 AM, Tomeu Vizoso wrote: >> >> On Sat, Jul 4, 2009 at 05:17, S Page wrote: >> > >> > Many thanks, I hope my comments are useful. >> > Who thought of using the addons.mozilla.org codebase for a.sl.o? >> > Stroke of genius! >> >> The earliest reference in my inbox is in an email from J5 (John >> Palmieri) on March 2007. >> >> Regards, >> >> Tomeu >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel > > > > -- > Walter Bender > Sugar Labs > http://www.sugarlabs.org > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Mon, Jul 6, 2009 at 13:56, Sascha Silbe wrote: > On Mon, Jul 06, 2009 at 11:08:21AM +0200, Tomeu Vizoso wrote: > >>> You're right on spot. The only prefixes used (but not defined for the >>> query) >>> are: >> >> Not quite, the association from mime_type: to M is doing when >> constructing the query: [...] >> So to support that we just need to call add_prefix on the QueryParser >> for every field prefix. > > Which is exactly what I meant: we don't call add_prefix() currently, so we > don't define prefixes for the query. Got it. I thought you were saying it was more complex than that so couldn't be done for 0.86. Regards, Tomeu > CU Sascha > > -- > http://sascha.silbe.org/ > http://www.infra-silbe.de/ > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQEcBAEBAgAGBQJKUeaAAAoJELpz82VMF3DavuUH/jNQ/aEXWyTXM0cn9mJNsDM3 > Ge7DylaRKjq0/BzEAE65Yes//nSZW8HSSAjdcKnwg4LhRA8MEGAkqIG/eEwiltEV > Z80cjgbgws6z+H+ZSE8TgrKam139CryY6foCgglgbkU4qyA6FTrwKmFdbDwPPd44 > Ad9kz9Fd246Xh/dYmToRcYMqCCUScklCOmoX7hU/x5WPDvTrEYuMcmvAYiqThEmg > 5hC85LQL8ybl8xxpqh1dXawlT1Zsw7JBLxq90KTITqX2uBVeO67DeNKVsu9xuHT0 > hS8Cd111bK73nnToMknv1b/py51HmhUHjiWDMggUbAZrwwcfBX+W5syZX0NPGD0= > =eFVO > -END PGP SIGNATURE- > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Marketing] [SoaS] The next Step: v2 Roadmap
On Mon, Jul 6, 2009 at 16:01, Greg Smith wrote: > Hi Sebastian, Fred, and Caroline, > > This looks like a very useful thread on the Sugar Roadmap and I like the > focus on "Customer" requirements. > > How do we get the GPA Sugar goals Caroline enunciated on to the main > Roadmap? > > I added a link on the GPA page to the Fred's Sugar on a Stick Goals page. > Hopefully we can find a place to collect a "Backlog", as they say in Agile. > > http://wiki.sugarlabs.org/go/Gardner_Pilot_Academy#Sugar_Feature_Requests > > It would be great to flesh out each GPA item with use cases and work flows, > then software design proposals and eventually links to source code. The > features should also be parsed down to smaller tasks ala Agile. > > FYI, Last year, S Page built and I populated a Semantic Wiki Roadmap > Collection and Prioritization tool for the XO. See: > http://wiki.laptop.org/go/Feature_roadmap > > I'm not sure if the Semantic Wiki format can be moved to the Sugar wiki or > if there is interest in tracking the Sugar roadmap that carefully. The > Semantic format was a huge time saver once it was implemented. > > IMHO its critical to minimize the coordination overhead and maximize the > coding time. That said, discussion of what is important and why goes a long > way to making better releases. > > I'll try to chip in by picking up items Caroline marks Priority A, adding > details to them, tracking them on the roadmap and looking for programmers to > come up with options for implementation. Hi Greg, Simon is working on adapting Fedora's feature process to Sugar, what do you think of it? http://wiki.sugarlabs.org/go/Features/Policy Regards, Tomeu > Thanks, > > Greg S > > > > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Feature proposal for 0.86
On Thu, Jul 2, 2009 at 13:33, Simon Schampijer wrote: > Dear Community, > > I created a Feature Template [1]. Please move your proposals in the > Roadmap[2] and follow the process [3] for inclusion in the release. The > process is based on the Fedora Feature policy - just (hopefully) > simplified a bit. Please have in mind that this release cycle is rather > short, so get your proposals in :) I hope that we can track down better > the status of each feature and make our cycle even more successful. My first one: http://wiki.sugarlabs.org/go/Features/Tabs_In_Browse Regards, Tomeu > Thanks, > Simon > > [1] http://wiki.sugarlabs.org/go/Features/Feature_Template > [2] http://wiki.sugarlabs.org/go/Development_Team/Release/Roadmap/0.86#Ideas > [3] http://wiki.sugarlabs.org/go/Features/Policy > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Background Screen Color for SoaS Activity
On Tue, Jul 7, 2009 at 04:46, Art Hunkins wrote: > Tomeu, > > I've had no luck modifying background color for anything except buttons. > > No boxes, even when the box is completely empty. > > Does anyone know how to change the color of the entire screen, or of a box? I have done it routinely, can you share the whole code of your activity class? Regards, Tomeu > Art Hunkins > > - Original Message - From: "Tomeu Vizoso" > To: "Art Hunkins" > Cc: > Sent: Monday, July 06, 2009 4:26 AM > Subject: Re: [Sugar-devel] Background Screen Color for SoaS Activity > > >> On Mon, Jul 6, 2009 at 06:19, Art Hunkins wrote: >>> >>> The default color for the Sugar Activity screen seems to be set to light >>> gray. I'd like mine to be white. >>> >>> Is there any way to change this in my activity script? >> >> That looks good to me, perhaps ibox contains some other widget that is >> covering it completely? >> >> Regards, >> >> Tomeu >> >>> I tried: >>> >>> import gtk >>> >>> win = csndsugui.CsoundGUI(self) >>> ibox = win.box(False) >>> ibox.modify_bg(gtk.STATE_NORMAL, gtk.gdk.Color(0x, 0x, 0x)) >>> >>> where ibox = the entire screen. >>> >>> However this changed nothing. >>> >>> Anything fairly straightforward I could try? >>> >>> Art Hunkins >>> >>> ___ >>> Sugar-devel mailing list >>> Sugar-devel@lists.sugarlabs.org >>> http://lists.sugarlabs.org/listinfo/sugar-devel >>> > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Marketing] [Server-devel] [SoaS] The next Step: v2 Roadmap
On Sun, Jul 5, 2009 at 15:53, Rodolfo D. Arce S. wrote: > Hello all: > > I'm actually not working solely with Sugar, but with the OLPC > deployment and the XS.. > > The feature that i found to be more important is the re-installing of > the operative systrem, beacuse the whole platform is still a little > unstable, the OS reinstall is very usefull.. but the restore of the > journal is very VERY complicated > > Daniel Drake made a couple of scripts that were very usefull, which > restores a journal to a temp folder.. and when booting looks for that > temp folder in order to restore > > If i tryed to do it manually.. is very long and complicated process.. > do-able, but if i think of a 9 year old doing it.. well.. it could be > to hard > > So I think that is someting that we shloud be aiming at.. simple > journal backup and restore.. and not only in an OLPC, or XS > envoiroment for that matter.. so even in places without XS (for > backup) or where reinstall is a fast and easy way to get a system up > again.. the journal is the only place where all things are stored Hi Rodolfo, have you already thought about the ideal user experience for that? Thanks, Tomeu > cheers.. R > > On Sat, Jul 4, 2009 at 8:47 PM, Caroline Meeks wrote: >> Hi, >> I am going to try to answer this, or actually I hope start a brainstorming >> session that will get us towards a feature list. >> I am going to try to use the Customer Role of an Agile process. That means >> I'm going to try to talk as much about the result I want to see as I can and >> as little as I can about how to get to it. I do know that some of this is >> in the works. I also know that some of it will require the heavens to >> deliver us yet another genius programmer with a new skill set to accomplish >> by September. But the job of the role of Customer is my mind is to talk >> about what I'd like to see, what the business case for it is and what the >> priority is. I hope other people will join me in this role as i think its >> crucial information for the technical team to have. >> Solid Collaboration - Priority A for GPA Project. - Defining what this looks >> like and how we get there is an important discussion and i don't have all >> those answers. This encompasses local and jabber collaboration. >> Straightforward Teacher "Assignment" -> Student -> Teacher >> workflow. Priority B for GPA For example. Teacher creates a template >> to scaffold student writing. Students do the writing assignment and the >> teacher "collects" them. Maybe this happens with Moodle or maybe its done >> all in Sugar? >> Straightforward Sugarization - By this I mean that a programmer who has >> created a game for linux or the web could look at our documentation and >> examples and tell his/her boss, "yes I see how we can make this available >> for Sugar and it will be a better experience for kids in a classroom through >> Sugar." Sugarizing should not mean giving up aggregating data for the >> teacher. It should be a better user experience because: automatic saving, >> cooler collaboration, easier installation and more consistent performance, >> easier for teachers to find, available to the million kids with XOs. >> .Priority A for Sugar. >> Sugar on SoaS and Netbooks backs up and restores with XS - Priority A for >> GPA, >> Sugar Live CD - Boothelper - USB Creator all in one - Priority B for SoaS >> Sugar on a Stick works with a VM - Priority B for GPA - it still has to >> boot on its own also. >> A Sugar machine can also run a SoaS - Priority C - Use case. Say you are in >> a 1-1 Netbook deployment. Your netbook breaks and it'll be a week till its >> repaired. It would be cool to burn a Stick for that kid from the XS backup >> and they could then use a teacher's netbook or some kid who is in Gym that >> period's netbook and still get to participate in the lesson. >> Sugar works on preIntel Macs - Priority C for GPA, Priority B for Sugar. >> Sugar works on lesser hardware, say Pentium III 256M. - Priority C for SoaS >> Don't let the user keep opening activities until the machine crashes or is >> driven to its knees - Priority C for GPA >> Less cluttered, more consistent neighborhood view - Priority C for Sugar >> I am copying the Server list because I think many of the things I think are >> the most important next steps for Sugar require interfacing with, and >> improvements in the XS. >> Priorities are my current opinions and I tried to not bias them with how >> hard I think the tasks are. They are about how important I think they are, >> in my opinion, with my customer hat on, to either the GPA pilot, Sugar and >> its marketing, and partnerships and adoption, or the Sugar on a Stick >> project. I don't think for a second that things should be done in priority >> order. >> So I hope everyone else sticks their necks out and says what features they >> want, what the use cases are and what they think their relative importance >> are. Then we can narrow our focus back do
Re: [Sugar-devel] Backup and Restore Feature added to Wiki
On Tue, Jul 7, 2009 at 16:05, Greg Smith wrote: > Hi All, > > I created a Feature request for backup and restore here: > http://wiki.sugarlabs.org/go/Features/Back_Up_and_Restore Shouldn't this be already working in SoaS 0.84 with XS 0.6? May be waiting for someone to give it a tray. CC'ing Martin and Dave who may have already tried it. Regards, Tomeu > I'm still not sure how to "tie" it to GPA or a release or pile of > pending feature requests. If anyone knows the right wiki markup to do > that, please go ahead. I'll watch what you do and use it for the next > one. > > I made myself the "owner" but it should probably be someone smarter > than me and able to program, maybe Martin...? > > Any comments or questions on the feature are welcome. It occurred to > me as I was writing it that this problem must have been solved already > in Linux. If anyone knows a good solution there, lets take it! That > will solve most of the problem leaving us with the special case of the > DataStore/Journal. > > Comments on format and more accurate filling out of the template also > appreciated. > > From this list http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Goals, > I'll work on "collaboration" next. That is such a tough nut that I may > fill in a few priority B items too for practice. > > HTHs. > > Thanks, > > Greg S > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Questions about GConf and ORBit.
On Wed, Jul 8, 2009 at 05:32, Michael Stone wrote: > Tomeu, > > I dug through the gconf, libbonobo, and orbit2 source code and discovered some > interesting things. Most relevant for this discussion: > > * ORBit2, on Linux, defaults to sending messages over unix sockets in > directories > like /tmp/orbit-$USER* which it carefully creates with mode 0700. There are no > configuration options for changing these permissions. > > * it's easy to get orbit2 to use other transports with either per-user or > system-wide configuration. > > Just run something like > > cat >> $CHROOT/etc/orbitrc < ORBIIOPIPv4=1 > ORBLocalOnly=1 > ORBIIOPUSock=0 > EOF > > and you'll be good to go. (With the obvious authentication consequences.) > > Regards, > > Michael > > P.S. - I also pushed patches into > > http://dev.laptop.org/git/users/mstone/security > > which cause rainbow-sugarize to configure the activity root well enough to > launch Browse, Chat, Pippy, and Calculate and which comment out its > $XAUTHORITY > processing since that logic isn't correct for unauth'd Xephyrs like the one > that I'm testing in. > > This means that you can now test rainbow+sugar-0.84 in squeeze chroots and > perhaps in other settings well enough to launch several activities and to > collect interesting tracebacks. (Baby steps.) That's awesome! I would love to see a customized SoaS image that allowed us testing Rainbow in 0.84. I guess the next steps are: - package rainbow in Fedora and build it also for F11, - build locally rpms of sugar patched to use the new rainbow, - add to the .ks file the Orbit hack, - create a new soas image with these two packages. Anything missing? I'm adding fedora-olpc to the CC in case someone there wants to give a hand. Thanks, Tomeu > P.P.S. - Packaging, anyone? > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar on a Stick - and Csound
On Tue, Jun 30, 2009 at 03:48, Aleksey Lim wrote: > On Mon, Jun 29, 2009 at 08:14:26PM -0400, Art Hunkins wrote: >> Does anyone have insight concerning this response from Victor Lazzarini of >> the csound-devel listserv? (Victor wrote the csndsugui activity for Sugar >> and is responsible for the Csound 5.08.91 rpm package.) >> >> My USB drive has nothing on it but Sugar, and we've no idea what module >> Python is trying to load that might be absent. >> >> Thanks for any ideas. (Of course, when Csound 5.10 appears as a Sugar >> update, I'll be installing it to see if this helps.) > > just an option, > rebuild _csnd module in soas environment and it should fix problem anyway Have filed https://bugzilla.redhat.com/show_bug.cgi?id=510423 about this. Regards, Tomeu > -- > Aleksey > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] prep for an article
On Thu, Jul 9, 2009 at 02:57, Eduardo H. Silva wrote: > 2009/7/8 Jeff Elkner : >> Ann, >> >> Luke tells me that: >> >> 1. The chats are stored in the journal, but we don't know if there is an >> easy way to move them to a flash drive (Luke is trying as I type). > > Chat entries in the journal can be opened with Write.. Or any other text editor. You can put them into a usb stick by dragging the journal entry to the stick icon in the bottom. Regards, Tomeu >> >> 2. Alt-1 puts a screen shot in the journal. We can drag it to a USB stick >> from there. >> >> Good questions... Thanks! >> >> jeff >> >> On Wed, Jul 8, 2009 at 4:42 PM, a k wrote: >>> >>> Jeff, >>> Two quick questions: >>> 1) can we capture the text of the chats the students are having? (I'd like >>> to do a linguistic analysis--ESPECIALLY if they chat after class--WILL THEY >>> DISCUSS Scratch procedures? >>> 2) can we capture a "photo" (a still) of a Scratch screen? (to illustrate) >>> hasta manana, >>> aa >> >> >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel >> >> > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Datastore redesign
On Mon, Jul 6, 2009 at 16:02, Sascha Silbe wrote: > On Mon, Jul 06, 2009 at 12:29:53PM +0200, Tomeu Vizoso wrote: > >> Agreed. I have to say that your proposal is excellent, congratulations! > > Thanks, I'm flattered. :) > > >>> Is the asynchronous API design useful enough to warrant more complex >>> implementation? >> >> I'm not sure, but I think that whatever decision we take should be >> made based on actual usage of the DS. What about proposing an example >> of how an existing activity would be modified to use the new API? > > OK, will work on one. > > >>> - For save() calls activity needs to wait for result (containing new >>> version_id) before it can invoke save() again for the same object >>> which can take quite some time if save() is sync - especially if other >>> activities are saving at the same time. >> >> What about having a separate call that returns synchronously a new >> tree_id and/or version_id? > > Interesting idea, need to think about it. As we're going to use UUIDs not > using requested versions shouldn't be an issue (for other version number > schemes like the one you propose below "holes" in the numbering could be > troublesome). The issue I see with this is the actual creation or update operation failing, thus further operations on that uuid would be invalid. I guess activities will need to be able to notice that the creation failed and do something accordingly. >>> Making the API fully asynchronous is the cause for much of the complexity >>> of >>> my proposal, but if we eliminate the queueing the response times for >>> write >>> accesses and checkout() can be very long even for unrelated operations. >> >> Why for unrelated operations? > > Because we're serializing VCS operations. They are IO bound (more > specifically: disk bound) and parallelisation would only lead to IO > starvation, especially for HDDs. What's the scenario in which starvation would happen and with which consequences? >> # do we want an optimized way to determine (only) the branch HEADs of >> a given tree_id? >> >> This depends on the intended UI. My opinion is that if we branch at >> every interesting modification (triggered by the activity detecting an >> interesting change or by the user clicking on the Keep button), we >> would like to display in the object list all the HEADs of each branch >> in each tree_id. In that case yes, we need a way to retrieve that list >> that is fast on both the client and the server side. > > My imagined usage of branches was to create them automatically upon altering > a non-HEAD version. > A user basing off an old version could mean the newer version is "broken" > (in that case promoting the new version to the HEAD of the current branch > makes more sense) or that (s)he uses the older version as a kind of template > to create derivates (so creating a branch would make most sense). > But I'm open to alternative suggestions. We'd most likely need a way to > explicitly create branches then. I actually would do a branch at every resume, even if it's the current HEAD. >> # using symlink instead of hardlink for "incoming" queue since we want >> to support directory trees, not just files > >> What justifies this new requirement? > > That it's > a) of use to activities (IIRC some of them use ZIP files right instead now), > b) easy enough to achieve with the new design and > c) leads to better delta compression and thus disk space effiency. That's fine, but I think we should first address present needs, once we are done we can try to anticipate new ones. We are already planning to do very big changes in one single go and would be very unfortunate to have to back up those because of some peripheral requirements that were added because they seemed easy enough at the time. I tell you this because of my experience in releasing broken datastores. Would be good if we could learn from the past. >> # since an index rebuild can take a lot of time we need to provide UI >> feedback while doing that >> >> Any I/O operation can potentially take a lot of time, but with the >> current version of the DS rebuilding an index with a few thousands of >> entries is not so slow on the XO. We should never need to rebuild the >> index, so this new requirement might not be justified (given the >> current resources, all the other work we need to do, etc). > > OK, good to know index rebuilding is fast. So the simple, boolean API I > proposed (check_ready() / Ready()) suffices. Well, that's the index as implemented in th
Re: [Sugar-devel] Datastore redesign
On Mon, Jul 6, 2009 at 16:33, Eben Eliason wrote: > On Mon, Jul 6, 2009 at 10:02 AM, Sascha > Silbe wrote: >> On Mon, Jul 06, 2009 at 12:29:53PM +0200, Tomeu Vizoso wrote: >> >>> Agreed. I have to say that your proposal is excellent, congratulations! >> >> Thanks, I'm flattered. :) >> >> >>>> Is the asynchronous API design useful enough to warrant more complex >>>> implementation? >>> >>> I'm not sure, but I think that whatever decision we take should be >>> made based on actual usage of the DS. What about proposing an example >>> of how an existing activity would be modified to use the new API? >> >> OK, will work on one. >> >> >>>> - For save() calls activity needs to wait for result (containing new >>>> version_id) before it can invoke save() again for the same object >>>> which can take quite some time if save() is sync - especially if other >>>> activities are saving at the same time. >>> >>> What about having a separate call that returns synchronously a new >>> tree_id and/or version_id? >> >> Interesting idea, need to think about it. As we're going to use UUIDs not >> using requested versions shouldn't be an issue (for other version number >> schemes like the one you propose below "holes" in the numbering could be >> troublesome). > > I think "holes" can be expected, so we should definitely be prepared for them. > >> >>>> Making the API fully asynchronous is the cause for much of the complexity >>>> of >>>> my proposal, but if we eliminate the queueing the response times for >>>> write >>>> accesses and checkout() can be very long even for unrelated operations. >>> >>> Why for unrelated operations? >> >> Because we're serializing VCS operations. They are IO bound (more >> specifically: disk bound) and parallelisation would only lead to IO >> starvation, especially for HDDs. >> >> >>> # do we want an optimized way to determine (only) the branch HEADs of >>> a given tree_id? >>> >>> This depends on the intended UI. My opinion is that if we branch at >>> every interesting modification (triggered by the activity detecting an >>> interesting change or by the user clicking on the Keep button), we > > I don't think we need to branch in these instances. These events > should create new versions, but not necessarily new branches. In my proposal, branch is not a concept directly exposed to the user. Is just an artefact that allows the journal to display the relevant info to an user. If we branch at the following events, displaying only HEADs of branches in the journal list view makes sense for the user: - new tree_id, - resume entry, - keep button, - after a big change in the activity model (user deletes the whole drawing, etc). There are other ways to manage what we want, but this approach made it very easy to implement. Just to make sure I'm understood, I see why using branches this way may seem conceptually wrong, it's not how we would work in a VCS or CMS. But by creating new branches at those points and displaying only HEADs of branches in the list view is the simplest way I found of displaying the relevant entries in a robust way (resisting activity crashes). >>> would like to display in the object list all the HEADs of each branch >>> in each tree_id. In that case yes, we need a way to retrieve that list >>> that is fast on both the client and the server side. >> >> My imagined usage of branches was to create them automatically upon altering >> a non-HEAD version. > > This makes sense to me, personally. > >> A user basing off an old version could mean the newer version is "broken" >> (in that case promoting the new version to the HEAD of the current branch >> makes more sense) or that (s)he uses the older version as a kind of template >> to create derivates (so creating a branch would make most sense). >> But I'm open to alternative suggestions. We'd most likely need a way to >> explicitly create branches then. >> >> >>> # using symlink instead of hardlink for "incoming" queue since we want >>> to support directory trees, not just files >> >>> What justifies this new requirement? >> >> That it's >> a) of use to activities (IIRC some of them use ZIP files right instead now), > > This has its own merits, though. Encapsulating the related files as a > single archive makes transporting the file around, or sendi
Re: [Sugar-devel] Nobody understands "Keep"
On Thu, Jul 9, 2009 at 12:29, Martin Dengler wrote: > On Thu, Jul 09, 2009 at 11:22:16AM +0100, Daniel Drake wrote: >> On Thu, 2009-07-09 at 10:45 +0100, Martin Dengler wrote: >> > On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote: >> > > Nobody in the world seems to understand the Keep button. People think >> > > it's for regular saving and you should do it before you close or switch >> > > away from your activity. >> > >> > That's not far from the truth, right? At least in any work-losing or >> > surprising way... >> >> It's far from the truth in that it's not normally what you want to >> do. > > My quoting-foo is bad, so I've caused confusion (in myself, too :)). > >> To save your work, simply click the Stop button or change so that >> another activity has focus. If you click Keep, you'll end up with 2 >> copies - one from when you clicked Keep, and one from when you clicked >> Stop (or focused on another activity). >> >> As far as I understand it, Keep is useful for these types of scenarios: >> - you've done a lot of work but now it's time to refactor/reorganize the >> whole thing. However you want to keep a copy of the rough version you >> have now, as "insurance" or perhaps for reference while you re-mangle >> the work. >> - you've made a template for something, now you want to save that >> template (as a blank template) before starting on a version where you >> fill in the content. > > This is a great explanation -- it should be in the HIG or something. But the biggest problem is how do we explain this to users without them having to read the HIG (or manual)? Should be called "Keep a copy"? Regards, Tomeu >> Daniel > > Martin > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar on a Stick - and Csound
On Thu, Jul 9, 2009 at 17:29, Peter Robinson wrote: > Hi, > >> Does your action on Tomeu's filing mean that this Python bindings issue is >> now fixed? > > No it doesn't, its just what I suspect is the issue. I don't currently > have time to investigate it further so I put the note on the bug so if > anyone else has the time it might provide direction for them. I unfortunately also don't have time now, but from the look of it I think Peter is on the right track. >> If so, any idea: >> 1) when an SoaS update might be available? >> 2) when it would be incorporated into Strawberry? > > I can't answer either of those. You should get into contact with the SoaS team, I'm forwarding it again to sugar-devel. Please keep conversations on-list so everybody benefits from this info. Regards, Tomeu >> I'm anxious to test it. >> >> Thanks to both of you for your help. >> >> Art Hunkins > > Peter > >> - Original Message - From: "Tomeu Vizoso" >> To: "Aleksey Lim" >> Cc: "Art Hunkins" ; >> Sent: Thursday, July 09, 2009 4:16 AM >> Subject: Re: [Sugar-devel] Sugar on a Stick - and Csound >> >> >>> On Tue, Jun 30, 2009 at 03:48, Aleksey Lim wrote: >>>> >>>> On Mon, Jun 29, 2009 at 08:14:26PM -0400, Art Hunkins wrote: >>>>> >>>>> Does anyone have insight concerning this response from Victor Lazzarini >>>>> of the csound-devel listserv? (Victor wrote the csndsugui activity for >>>>> Sugar >>>>> and is responsible for the Csound 5.08.91 rpm package.) >>>>> >>>>> My USB drive has nothing on it but Sugar, and we've no idea what module >>>>> Python is trying to load that might be absent. >>>>> >>>>> Thanks for any ideas. (Of course, when Csound 5.10 appears as a Sugar >>>>> update, I'll be installing it to see if this helps.) >>>> >>>> just an option, >>>> rebuild _csnd module in soas environment and it should fix problem anyway >>> >>> Have filed https://bugzilla.redhat.com/show_bug.cgi?id=510423 about this. >>> >>> Regards, >>> >>> Tomeu >>> >>>> -- >>>> Aleksey >>>> ___ >>>> Sugar-devel mailing list >>>> Sugar-devel@lists.sugarlabs.org >>>> http://lists.sugarlabs.org/listinfo/sugar-devel >>>> >> >> > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Add ability to record to Speak?
On Fri, Jul 10, 2009 at 06:22, Aleksey Lim wrote: > On Thu, Jul 09, 2009 at 11:50:20PM -0300, Muriel de Souza Godoi wrote: >> Hi all, >> >> I've been away from Sugar for a long time... but keep reading the mailing >> lists :) >> >> I will be on vacation until July 20th, but after that I can face this as a >> new effort to help Sugar >> >> What about a different approach? Add the speak capability to memorize... >> >> Can memorize just use the speak library and pronounce the cards? >> What do you think? > > I'm sure thats the way to go: > > * adding record feature to Speak can increase complexity of Speak UI > * using speak synth feature in Memorize means not using extra resources > for storing audio files > * and Caroline is right, speaking faces will look really funny +1 Welcome back, Muriel! Regards, Tomeu > Thanks > > -- > Aleksey > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Nobody understands "Keep"
On Fri, Jul 10, 2009 at 05:41, Eben Eliason wrote: > On Thu, Jul 9, 2009 at 7:55 PM, Eduardo H. Silva wrote: >> 2009/7/9 Tomeu Vizoso : >>> On Thu, Jul 9, 2009 at 12:29, Martin Dengler >>> wrote: >>>> On Thu, Jul 09, 2009 at 11:22:16AM +0100, Daniel Drake wrote: >>>>> On Thu, 2009-07-09 at 10:45 +0100, Martin Dengler wrote: >>>>> > On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote: >>>>> > > Nobody in the world seems to understand the Keep button. People think >>>>> > > it's for regular saving and you should do it before you close or >>>>> > > switch >>>>> > > away from your activity. >>>>> > >>>>> > That's not far from the truth, right? At least in any work-losing or >>>>> > surprising way... >>>>> >>>>> It's far from the truth in that it's not normally what you want to >>>>> do. >>>> >>>> My quoting-foo is bad, so I've caused confusion (in myself, too :)). >>>> >>>>> To save your work, simply click the Stop button or change so that >>>>> another activity has focus. If you click Keep, you'll end up with 2 >>>>> copies - one from when you clicked Keep, and one from when you clicked >>>>> Stop (or focused on another activity). >>>>> >>>>> As far as I understand it, Keep is useful for these types of scenarios: >>>>> - you've done a lot of work but now it's time to refactor/reorganize the >>>>> whole thing. However you want to keep a copy of the rough version you >>>>> have now, as "insurance" or perhaps for reference while you re-mangle >>>>> the work. >>>>> - you've made a template for something, now you want to save that >>>>> template (as a blank template) before starting on a version where you >>>>> fill in the content. >>>> >>>> This is a great explanation -- it should be in the HIG or something. >>> >>> But the biggest problem is how do we explain this to users without >>> them having to read the HIG (or manual)? >>> >>> Should be called "Keep a copy"? >> >> +1 >> For a while, in the pt_PT translation of Sugar I did, I named the Keep >> button as Keep a copy. > > I urge again that "keep a copy" is not what is intended, in the long > run. Without proper versions, of course, this is effectively how it > behaves. Therefore, it's no surprise many saw it this way. But with > versions, the "keep" button is actually a "keep new version" button. > As mentioned before, a "new version" retains the tree_id, whereas a > true "copy" does not. But are you meaning that we should name the current one "Keep a copy" and when we have versions add "Keep"? Regards, Tomeu > Since versions are on the way, we should make sure to clarify the distinction! > > Eben > > >>> >>> Regards, >>> >>> Tomeu >>> >>>>> Daniel >>>> >>>> Martin >>>> >>>> ___ >>>> Sugar-devel mailing list >>>> Sugar-devel@lists.sugarlabs.org >>>> http://lists.sugarlabs.org/listinfo/sugar-devel >>>> >>>> >>> ___ >>> Sugar-devel mailing list >>> Sugar-devel@lists.sugarlabs.org >>> http://lists.sugarlabs.org/listinfo/sugar-devel >>> >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel >> > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Nobody understands "Keep"
On Fri, Jul 10, 2009 at 16:25, Eben Eliason wrote: > On Fri, Jul 10, 2009 at 10:05 AM, Martin > Dengler wrote: >> On Fri, Jul 10, 2009 at 10:01:19AM -0400, Eben Eliason wrote: >>> On Fri, Jul 10, 2009 at 5:28 AM, Tomeu Vizoso wrote: >>> > But are you meaning that we should name the current one "Keep a copy" >>> > and when we have versions add "Keep"? >>> >>> No, no. I'm urging that we name it "Keep new version" now if we rename >>> it, so that it's meaning doesn't change down the road when versions >>> are introduced. >> >> "Keep new version" seems a lot closer to a description of the >> implementation than of the user-desired result. Unless this "new >> version" becomes the active one (i.e., the one upon which the user >> continues to work, assuming they don't close the application), isn't >> the result of the button press better called "Keep[ing of a] backup >> version"? > > I'm happy to entertain other terminology. All I'm really trying to get > across is that, technically, this action is strictly not what I > interpreted as "keep a copy" in the presence of versions, and I don't > want to confuse the terminology later by mixing up the terms. > > I'd be equally satisfied, I think, by finding a better term for what > I'm presently describing as "keep a copy", wherein a brand new tree_id > is assigned to the copy, detaching it from the history (and > collaboration scope) of the original. The fundamental issue is whether > or not version/collaboration history is retained with the action, so > let's ensure that we name both of these types of copy operations at > the same time, even if we only have one of them for now, so that it > can be extended later. > > Ben's suggestion of "checkpoint" could work. Perhaps "Keep checkpoint" > would be better to retain the action. You're right that it's more like > "keep backup version"that is, the keep operation which retains the > tree_id basically writes the current state of the activity as a > version (the "just-now-previous" one), and allows you to continue > working in the "most current" one. No branching, in the traditional > sense, happens here. Should we discuss this in sugar-devel? Why not asking any of the teachers in IAEP what is more natural for them? Regards, Tomeu > Eben > >>> > Regards, >>> > >>> > Tomeu >>> >>> Eben >> >> > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-toolkit-0.85.1
== Source ==
http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit/sugar-toolkit-0.85.1.tar.bz2
== Fixed tickets ==
* #757 telepathy_room_handle unused and unusable
* #610 Journal Palette does not manage too many characters for a title correctly
* #635 bundlebuilder.list_files drops first character of file names if base_dir
has trailing slash
* #428 connect('map') to activity widow not to current canvas
* #428 connect('map') to activity widow not to current canvas
* #647 git-ls-files does not work with newer Git
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] hulahop-0.5.0
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/hulahop/hulahop-0.5.0.tar.bz2 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
On Sat, Jul 11, 2009 at 03:44, Gary C Martin wrote: > Hi Aleksey, > > On 10 Jul 2009, at 16:19, Aleksey Lim wrote: > >> Hi all, >> >> http://git.sugarlabs.org/projects/sugar-toolkit/repos/toolbars >> there is simle example in examples/toolbar.py >> >> Does it satisfy mockups? > > Sugar-jhbuild is broken for me just now so can't look/test :-( Is this > toolbar example work for the Journal, Browse (tabs treatment), or the > main system wide Sugar toolbars (BTW: I'm making some new mock-ups of > them just now)? Hi Gary, Walter just added some comments to the jhbuild instructions: http://wiki.sugarlabs.org/go/Development_Team/Jhbuild#Other_commands I'm guessing you are finding the same errors he found and you need to pass the -a --clean flags. Regards, Tomeu > Any chance of a screen shot or two? :-) > > Regards, > --Gary > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] SJH_DISTRIBUTION
Hi, all fedora users need to set up that env var now? Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SJH_DISTRIBUTION
On Sat, Jul 11, 2009 at 11:08, Tomeu Vizoso wrote: > Hi, > > all fedora users need to set up that env var now? Forget, just read in http://wiki.sugarlabs.org/go/Development_Team/Jhbuild/Fedora about yum install redhat-lsb. Regards, Tomeu > Regards, > > Tomeu > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
On Sat, Jul 11, 2009 at 11:12, Simon Schampijer wrote: > On 07/11/2009 03:44 AM, Gary C Martin wrote: >> Hi Aleksey, >> >> On 10 Jul 2009, at 16:19, Aleksey Lim wrote: >> >>> Hi all, >>> >>> http://git.sugarlabs.org/projects/sugar-toolkit/repos/toolbars >>> there is simle example in examples/toolbar.py >>> >>> Does it satisfy mockups? >> >> Sugar-jhbuild is broken for me just now so can't look/test :-( Is this >> toolbar example work for the Journal, Browse (tabs treatment), or the >> main system wide Sugar toolbars (BTW: I'm making some new mock-ups of >> them just now)? > > for reference: http://wiki.sugarlabs.org/go/Features/New_Toolbar_Design > eben's mockups: http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars > > I had a brief look at the code. Looks like a great start and proof of > concept. What I think we should do now is (in the order): > > a) DESIGN: discuss the design further and get some mockups together, one > question that came up is: do we always have a one line secondary tool > bar? How would more complex widgets like the color chooser look like > http://wiki.sugarlabs.org/go/File:ColorToolButton.png ? Or would they > open from the secondary palette? Maybe we should step through some of > the activities and just remodel them to see what would work and find out > about the edge cases (think gary is already working on that) > > b) API: we need a rock solid API. This is public API and will be used by > all the activity authors, so very important to get this right - so we do > not need to change it again afterwards > > c) IMPLEMENTATION: we have the proof of concept, we should check if we > would be easier to create a custom widget, see what parts can be moved > to the theme so we do not have to work around issues in the code > > Sounds good? Comments? Sounds very good! Another possibility is having Aleksey working on converting Write to the new toolbar and getting frequent feedback about it. Suggesting Write here because it has a crowded toolbar, could be the journal as well because we already have mockups. Regards, Tomeu > Thanks, > Simon > > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SJH_DISTRIBUTION
On Sat, Jul 11, 2009 at 11:46, Sascha Silbe wrote: > On Sat, Jul 11, 2009 at 11:30:27AM +0200, Tomeu Vizoso wrote: > >> Forget, just read in >> http://wiki.sugarlabs.org/go/Development_Team/Jhbuild/Fedora about yum >> install redhat-lsb. > > Out of curiousity, is this on a fresh install from CD? Or did Fedora drop a > dependency on redhat-lsb now? Installed from the live cd. redhat-lsb brings qt plus lots of unneeded stuff :( https://bugzilla.redhat.com/show_bug.cgi?id=472633 Regards, Tomeu > CU Sascha > > -- > http://sascha.silbe.org/ > http://www.infra-silbe.de/ > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQEcBAEBAgAGBQJKWF99AAoJELpz82VMF3Dar3gIAJ/RVRJLaFK5TQ/c9NjTsl7i > YNRhfO4jPMU8IcB9STvkZCz69Dvcj6u+pS4jSA9OE6LszgK0t/SQmIV0Rejmz/Nu > zhB0j9sKHTC7E8+IkZBhEPVUEJmbAF/Rv7Hz9LhH0TPciC8iYHx8chA/NRe4TGvh > wQwLa5KOCd9ERsCOaT1SxAak/Q+0xA6FtzXD+rKVL0KbHB4xtvmoIumAcPles+WF > ZDN0KTtYosgB6VKQJMUoesvO3/IS3PZIpVwpYU1xcgdsR+j/7T9MdBKUfqT3AlQg > QXxijfIGvcpfJFiwvkVIgMa8WKGjKQKhrT118F/acgK2iINaUmp3HK3UOGkfP6k= > =whkz > -END PGP SIGNATURE- > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Initial implementation of toolbars design
On Sat, Jul 11, 2009 at 16:53, Eben Eliason wrote: > On Sat, Jul 11, 2009 at 10:23 AM, Gary C Martin wrote: >> On 11 Jul 2009, at 14:40, Aleksey Lim wrote: >>> On Sat, Jul 11, 2009 at 11:12:31AM +0200, Simon Schampijer wrote: a) DESIGN: discuss the design further and get some mockups together, one question that came up is: do we always have a one line secondary tool bar? >>> >>> Do you mean hiding sub-toolbars like palettes? >>> I'm using new toolbar in Memorize, and should say - its much useful to >>> have persistent sub-toolbar(and not auto-hiding them like palettes) >> >> Ebens designs describe both interaction methods: >> >> 1). If you hover over one of the new tab replacement buttons the >> palette appears (over the top of the canvas) and will auto-hide if you >> move the mouse way (just like any normal palette) >> >> 2). If you click one of the new tab replacement buttons the palette >> appears (and shifts the canvas down the screen) and is locked in >> place. Clicking the button a 2nd time unlocks it so it behaves like a >> regular palette again. > > Yup, that's the idea. I think it should be up to the activity, by the > way, to decide if any of the secondary toolbars are "locked in" when a > new activity instance is created. For instance, Paint might decide > that making the colors available by default is the wise choice. > > We should also institute policy for retaining toolbar state in the > metadata for a given activity entry in the Journal, so that resuming > restores that context. Perhaps this is something that the toolkit can > do so that activity doesn't have to think about it. > How would more complex widgets like the color chooser look like http://wiki.sugarlabs.org/go/File:ColorToolButton.png ? Or would they open from the secondary palette? >>> >>> I'm personally, +1 for >>> http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars#11 > > Just to be clear, this new toolbar design is in no way intended to > replace palettes in general. Instead, it's provided as a unique > alternative to tabs that allows palette-like interaction, but also > allows these secondary toolbars to be locked in place persistently, > which can be of great usefulness. Therefore, we needn't ask ourselves > "how does look/work in the new toolbar design?" at all. > We should be asking "which of " would work better > functionally as a secondary toolbar?". > > I think that Paint, for instance, would gain heaps of usability if the > colors were a secondary toolbar, and that were shown by default. That > doesn't mean that Write, for instance, necessarily needs to replace > the current color chooser palette. It's should be up to activities to > decide what parts of the UI are best suited to the two modes. > > Both primary and secondary toolbars can have as many normal "palette > buttons" as desired. > >> I guess one unanswered question is do you allow the stacking of more >> than 2 rows of toolbar... And, how much work is going to be needed on > > This is something we tossed around a little bit while designing them. > I think the answer is no, personally, since it adds a lot more > complexity to the UI, and also begins to consume too much of the > screen. I'm hoping that [primary toolbars > secondary toolbars > > palettes] are sufficient for most use cases here; we don't want to > wind up with MS Word-like feature complexity! > > That said, if we do support it, I think the rule is basically that > closing any parent toolbar hides all of its children, and reopening a > parent toolbar that had child toolbars open when it was last hidden > should reveal all those same children open as they were. But again, > I'd much rather just support one level of secondary toolbars. > >> all the Activities if you start hand redesigning and customising each >> edge case. I think the current colour palette in Write would work as > > Yup. > >> is, at least that's how I was going to show it in a mockup, Activity >> bar -> text bar below -> existing drop down colour palette from its > > One advantage of this design is that the primary toolbar is always > visible, and secondary toolbars can be shown or hidden as needed. The > mockups of Browse and Paint try to illustrate how useful this can be > in defining a set of "core tools" that are always—or nearly > always—applicable to interacting with the activity. In the case of > browse, the forward and back buttons, address bar, and bookmarking > button are always available in the primary toolbar. In Paint, some of > the core painting tools are surfaced. > > So, the idea here is to define a primary toolbar which contains a) the > "core" set of tools/controls and b) toolbar buttons for the secondary > sets of tools/controls. > > In the case of Write, I'd expect some of the basic text editing > controls (bold, italic, underline, font-size, font, for example) to be > surfaced in the primary toolbar, while tables, images, paragraph > formats, and other secondary feature
[Sugar-devel] attention packagers: several fixes after 0.85.1
Hi, both sugar and sugar-toolkit contain some fixes that improve significantly the experience. So if you were considering packaging Sugar 0.85.1 for your favorite distro, consider packaging instead git snapshots. For your convenience I have uploaded them here: http://shell.sugarlabs.org/~tomeu/sugar-0.85.1.git05405976ad.tar.bz2 http://shell.sugarlabs.org/~tomeu/sugar-toolkit-0.85.1.git8d21a6d884.tar.bz2 Please notice that Sugar depends now on Metacity, instead of Matchbox. We could do a release if a packager really needs it. Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] attention packagers: several fixes after 0.85.1
On Sun, Jul 12, 2009 at 16:47, Jonas Smedegaard wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On Sun, Jul 12, 2009 at 04:14:19PM +0200, Tomeu Vizoso wrote: >>both sugar and sugar-toolkit contain some fixes that improve >>significantly the experience. So if you were considering packaging >>Sugar 0.85.1 for your favorite distro, consider packaging instead git >>snapshots. >> >>For your convenience I have uploaded them here: >> >>http://shell.sugarlabs.org/~tomeu/sugar-0.85.1.git05405976ad.tar.bz2 >>http://shell.sugarlabs.org/~tomeu/sugar-toolkit-0.85.1.git8d21a6d884.tar.bz2 >> >>Please notice that Sugar depends now on Metacity, instead of Matchbox. >> >>We could do a release if a packager really needs it. > > What is the benefit of _not_ issuing a new release? It takes a bit more of time and both maintainers need to be involved for releases. Regards, Tomeu > > - Jonas > > - -- > * Jonas Smedegaard - idealist og Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQIcBAEBCgAGBQJKWfeKAAoJECx8MUbBoAEht2UP/3N2bzkPCc0EWkO67toL8VfA > uj7VHCu1AiCoGxQSuG0+OJvU6p6sO8FyRwHqgr+402RsqOx5koNxNJAyc05O/DAA > oHXVKd5S+EBx7tsD3oFMLMH441KzR8Z4/NOxst3WC8ddufwjyXZSW3d8ptV6Q4Bo > 8xkPyK+WrVlxNZqXAyqpLVmLXFJaDHk7yw2oq+uo7Ytv3jNU3a/AGOgCG+aMPGrV > cIteDjnUZTjcHpIDk0pzgGQHF4pFxApyZyjB7Kd0TNdyusAZCa0hd4GfBCjIg3wm > WVw8Ol2T9tJYCoz+HKOX7YCm1YWFTATu0g6NHdzVHKivkzBwZFpJblj0HcVWGmPl > QXO2rl4V86wRhniLPZ8Cljm+up+A/ved+h0PKP/4oz73uHiJsMeHGrji8SF5ZiVF > N31BMu9FuXjSFwUeoMivnCpeupfKkz849V8oxkuFIP2cIJlg3jxPig+2Oq0S5TFC > bbofUnS8TP3fn2IARznYTrO6slTeLW8hoMkafoeK2Ea3QRQQndvk3uY0Jx8kysL/ > A6d1Gp9ZOfPD0dDZQ+hC8lwbX3rK/JNIBC2Ba24Odn2qc8MV2SYWINv0TsWHdLea > TSqwBfMqUkujfSQlSaTQTKlVJTsczjfbqVvecI9TNyCHEuf9WSH2tpjlbWfBwj5v > +vdPflqIV/s/g85HV1D0 > =W6lc > -END PGP SIGNATURE- > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] attention packagers: several fixes after 0.85.1
On Mon, Jul 13, 2009 at 00:54, Simon Schampijer wrote: > On 07/12/2009 04:14 PM, Tomeu Vizoso wrote: >> >> Hi, >> >> both sugar and sugar-toolkit contain some fixes that improve >> significantly the experience. So if you were considering packaging >> Sugar 0.85.1 for your favorite distro, consider packaging instead git >> snapshots. >> >> For your convenience I have uploaded them here: >> >> http://shell.sugarlabs.org/~tomeu/sugar-0.85.1.git05405976ad.tar.bz2 >> >> http://shell.sugarlabs.org/~tomeu/sugar-toolkit-0.85.1.git8d21a6d884.tar.bz2 >> >> Please notice that Sugar depends now on Metacity, instead of Matchbox. >> >> We could do a release if a packager really needs it. >> >> Regards, >> >> Tomeu > > Awesome, thanks for that work. Especially for taking care of the event > timestamp in the keyhandler. > > You only missed a little argument, but spotting those is my part of the game > ;p So we can drop pylint from jhbuild! Tomeu > http://git.sugarlabs.org/projects/sugar/repos/mainline/commits/5f88a8437f6b49cb97ce87eacacee3f68fb880d3 > > Cheers, > Simon > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Feedback on installing the Windows sugar stick
(just received this email today, what's going on with the lists?) On Thu, Jun 25, 2009 at 23:15, Sean Daly wrote: > Many thanks Klaas for reporting the error and proposing a workaround! > > Mathieu, could you or someone you know get this info to the LiveUSB > Creator people? Here is the link to their bug tracker: https://fedorahosted.org/liveusb-creator/ Would be good to search if the issue is already tracked and enter a new one if it isn't. Regards, Tomeu > Sebastian, do you think we should update the wiki with this workaround? > > thanks > > Sean > > > On Thu, Jun 25, 2009 at 10:08 PM, klaas langhout wrote: >> Quick feedback: >> - using >> http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Strawberry#Windows_Users >> - did: Download the latest version of Fedora LiveUSB Creator from >> http://fedorahosted.org/liveusb-creator/ and extract it; >> >> The instructions didn't match the current LiveUSB creator. In specific, >> when I launched the app, no option to format existed but, the download for >> Sugar on a Stick was already there. It failed to create and, in looking at >> the log file it was because of a UNC path usage that was invalid on Windows >> 7 >> >> Z:\liveusb-creator-3.7[1]\liveusb-creator-3.7>type liveusb-creator.log >> tools\7z.exe x "soas-strawberry.iso" -x![BOOT] -y -oE: >> 'liveusb-creator-3.7[1]\liveusb-creator-3.7' >> CMD.EXE was started with the above path as the current directory. >> UNC paths are not supported. Defaulting to Windows directory. >> The system cannot find the path specified. >> >> I had to manually invoke as: 7z.exe x "..\soas-strawberry.iso" -x![BOOT] -y >> -oE: >> >> Cheers, thanks for puttting this together. >> > ___ > IAEP -- It's An Education Project (not a laptop project!) > i...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Cs-dev] Sugar on a Stick - and OLPCsound/Csound
On Sun, Jul 12, 2009 at 21:19, Art Hunkins wrote: > Mike Gogins, a Csound developer, has taken care of the Scons issue with > Csound5.10, as discussed below. > > I'd be overjoyed if one of you Sugar developers could take it from there so > that we can have SoaS with a Csound that works with python2.6. SoaS is based on Fedora, so I'm adding fedora-olpc to CC. I think we need someone to read the thread your forwarded and update the Fedora ticket with an explanation of what's going on and what's the suggested way forward: https://bugzilla.redhat.com/show_bug.cgi?id=510423 Regards, Tomeu > If I can help in any non-technical way, please let me know. I'm much obliged > to all your help. > > Art Hunkins > > - Original Message - > From: "Michael Gogins" > To: "Art Hunkins" ; "Developer discussions" > > Sent: Sunday, July 12, 2009 11:20 AM > Subject: Re: [Cs-dev] Sugar on a Stick - and OLPCsound/Csound > > >>I patched SConstruct as suggested in the thread below. Somebody needs >> to update SConstruct from Csound CVS, rebuild Csound 5.10 using this >> patched SConstruct for Python 2.6, and then you need to install this >> new build. >> >> Hope this helps, >> Mike >> >> 1/09, Art Hunkins wrote: >>> Mike, >>> >>> Sorry, I'm technically way over my head here. I'm referring to the thread >>> below. >>> >>> Sugar on a Stick includes Csound5.10 and Python2.6. The >>> incompatibilities, >>> apparently relating to Scons, are cited below. I'm not building anything; >>> I >>> just need the SoaS download or update to handle my Python script with >>> Csound5.10 correctly. >>> >>> 5.10 doesn't work with a Python2.6 script currently. (I need 5.10 to be >>> able >>> to use multiple MIDI controllers.) >>> >>> I don't know how to explain any better, and also don't know where (else) >>> to >>> turn. Should I be looking elsewhere? (I feel really stuck currently.) >>> >>> Art Hunkins >>> >>> Mike G. wrote: >>> Art - the Python version is controllable in Sconstruct. It works with >>> 2.3, 2.4, 2.5, and 2.6 at present. Which version of Python do you need >>> Csound to work with, and how do you obtain or build Csound? >>> >>> - Original Message - >>> From: "Michael Gogins" >>> To: "Art Hunkins" ; "Developer discussions" >>> >>> Sent: Tuesday, July 07, 2009 3:13 PM >>> Subject: Re: [Cs-dev] Sugar on a Stick - and OLPCsound/Csound >>> >>> He says SConstruct has a bug, which he has patched. I think he's probably right, and I will patch SConstruct accordingly. The bug makes the installation not know the right name (soname) for the csnd extension module shared library. Regards, Mike On 7/6/09, Art Hunkins wrote: > Victor and Mike G. (especially) - > > You're familiar with my problems getting Csound5.10 working on SoaS. > > Aleksey, one of the Sugar developers, sent me the "solution" (below) to > this > problem (a Scons issue apparently). > > I don't know what to do with it, and look to you for either > implementation > or explanation. > > I'm really interested to get 5.10 working with Sugar. > > Art Hunkins > > - Original Message - > From: "Aleksey Lim" > To: "Art Hunkins" > Cc: ; ; > > Sent: Monday, July 06, 2009 3:37 AM > Subject: Re: [Sugar-devel] Sugar on a Stick - and OLPCsound/Csound > > >> looks like its a SConstruct issue >> https://sourceforge.net/tracker/index.php?func=detail&aid=2817271&group_id=81968&atid=564599 >> >> this patch fixed "import csnd" in my case >> http://git.sugarlabs.org/projects/jhconvert/repos/mainline/blobs/master/patches/csound-2817271-soname.patch >> >> On Sun, Jul 05, 2009 at 05:49:23PM -0400, Art Hunkins wrote: >>> As mentioned by a member of the sugar-devel list, it seems that a >>> csound >>> (5.10) install (yum install csound), does not install several crucial >>> site-specific and library packages (csnd, _csnd, libcsnd and perhaps >>> libcsound). >>> >>> Having to erase olpcsound before installing csound deletes these >>> files >>> and they don't get restored/reinstalled. >>> >>> So, to the procedures described below, before erasing olpcsound, I >>> saved >>> the above-listed files (there were 5 or 6), and once csound was >>> installed, added them back where they came from. >>> >>> This crude procedure didn't work, and the following error log is >>> quite >>> like the one I started with: >>> >>> >>> /usr/lib/python2.6/site-packages/sugar/util.py:25: >>> DeprecationWarning: >>> the sha module is deprecated; use the hashlib module instead >>> >>> import sha >>> >>> Traceback (most recent call last): >>> >>> File "/usr/bin/sugar-activity", line 21, in >>> >>> main.main() >>> >>> File "/usr/lib/python2.6/site-packages/sugar/activity/main.py", line >>> 105, >>
Re: [Sugar-devel] Latest release of Read Etexts, some questions
On Sat, Jul 11, 2009 at 14:39, Jim Simmons wrote: > I took the week off and spent a great deal of it in my basement > working on an improvement to Read Etexts which should be available > soon on ASLO. The new feature is annotations, where I let you add > notes to individual pages of a book, plus make as many bookmarks as > you like, using a UI modelled on what the latest Read has. Unlike > Read, I store this information in a Zip file along with the book, > which means that when you share a book the notes and annotations go > with it. > > Another thing I did was to put the title metadata in this file, > because that seemed to be the only way that I could make sure that > when someone shared this file the received file in the Journal would > get some title better than Read Etexts Activity. That part isn't > working at the moment. I need a way to know that a file has been > received from a sharing user and not opened any other way, because > only then do I want to check the annotations file for a title. If > anyone has any ideas I'd like to hear them. When you say that the file is shared, what do you mean exactly? > I'm thinking of adding keyboard shortcuts for the bookmarks. Any > suggestions on what keys to use would be welcome. > > The next feature to be added will be highlighting, probably with > underlines. If there is a passage in a book that is important you can > underline it for emphasis. You should be able to underline multiple > passages per page. > > Finally, I updated one of my development boxes to Fedora 11. It > doesn't look like the gstreamer espeak plugin is included in that > distribution, and unfortunately that box is the one I use for testing > text to speech. Is there an RPM for Fedora 11 that I could install? The gstreamer plugin isn't packaged yet for Fedora, unfortunately. Though Aleksey might have a .rpm that you can install. Regards, Tomeu > James Simmons > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Choosing to merge: a mockup
On Tue, Jul 7, 2009 at 20:12, Benjamin M. Schwartz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Mockup: > http://dev.laptop.org/~bemasc/merge_share_selection_mockup.png > > Idea: > If I resume an Activity session from my Journal, and there is already a > session in progress with the same activity_id, and the Activity in > question supports automerge, then Sugar will show me the above screen, > asking me whether I want to merge my work with the shared session, or to > work alone. This is enough to enable basic asynchronous collaboration. > > The screen simply has two buttons. One is the image of the shared session > in question, identical to the one shown in the Neighborhood View. The > other is an image of my XO icon. The text below each button explains its > purpose, and also gives the name of the shared session and the local > session, as these may have diverged. Knowing the names may help the user > to decide whether or not to merge. > > As I understand it, the current activity architecture requires an activity > to know if it is a joining a shared session as soon as initialization > begins, so activity startup cannot proceed until the user makes a choice. Perhaps we should review this. Is providing the choice in the launcher screen our best option user experience-wise? Or would be better to leave it entirely in the activity's hands if it was possible? Regards, Tomeu > A rounded-corner highlight box indicates the currently selected button, in > a manner consistent with the rest of the UI, hopefully enabling simple > keyboard shortcuts. The default selection may be based on a heuristic to > predict whether the user is likely to join the shared session. For > example, the default selection may be to merge if the local copy is the > latest local version, and to remain separate if it is not. > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.11 (GNU/Linux) > > iEYEARECAAYFAkpTkBUACgkQUJT6e6HFtqT8XACbBAa91c6oIvZvQYfJQvmIe6ht > LdIAoJfmeKU0VWvuK8gjeHvNbK8yKmur > =8W9M > -END PGP SIGNATURE- > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Cs-dev] Sugar on a Stick - and OLPCsound/Csound
2009/7/13 David Schönstein : > Hi Tomeu, > > Could we add the details of this thread to > http://wiki.sugarlabs.org/go/Development_Team/Sound ? Sure, feel free to do so. Currently I'm not working on anything related to sound, so would be great if other people that are interested in this subject organize themselves and the info they want to share. Thanks, Tomeu > Thanks > > David > > 2009/7/13 Tomeu Vizoso >> >> On Sun, Jul 12, 2009 at 21:19, Art Hunkins wrote: >> > Mike Gogins, a Csound developer, has taken care of the Scons issue with >> > Csound5.10, as discussed below. >> > >> > I'd be overjoyed if one of you Sugar developers could take it from there >> > so >> > that we can have SoaS with a Csound that works with python2.6. >> >> SoaS is based on Fedora, so I'm adding fedora-olpc to CC. I think we >> need someone to read the thread your forwarded and update the Fedora >> ticket with an explanation of what's going on and what's the suggested >> way forward: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=510423 >> >> Regards, >> >> Tomeu >> >> > If I can help in any non-technical way, please let me know. I'm much >> > obliged >> > to all your help. >> > >> > Art Hunkins >> > >> > - Original Message - >> > From: "Michael Gogins" >> > To: "Art Hunkins" ; "Developer discussions" >> > >> > Sent: Sunday, July 12, 2009 11:20 AM >> > Subject: Re: [Cs-dev] Sugar on a Stick - and OLPCsound/Csound >> > >> > >> >>I patched SConstruct as suggested in the thread below. Somebody needs >> >> to update SConstruct from Csound CVS, rebuild Csound 5.10 using this >> >> patched SConstruct for Python 2.6, and then you need to install this >> >> new build. >> >> >> >> Hope this helps, >> >> Mike >> >> >> >> 1/09, Art Hunkins wrote: >> >>> Mike, >> >>> >> >>> Sorry, I'm technically way over my head here. I'm referring to the >> >>> thread >> >>> below. >> >>> >> >>> Sugar on a Stick includes Csound5.10 and Python2.6. The >> >>> incompatibilities, >> >>> apparently relating to Scons, are cited below. I'm not building >> >>> anything; >> >>> I >> >>> just need the SoaS download or update to handle my Python script with >> >>> Csound5.10 correctly. >> >>> >> >>> 5.10 doesn't work with a Python2.6 script currently. (I need 5.10 to >> >>> be >> >>> able >> >>> to use multiple MIDI controllers.) >> >>> >> >>> I don't know how to explain any better, and also don't know where >> >>> (else) >> >>> to >> >>> turn. Should I be looking elsewhere? (I feel really stuck currently.) >> >>> >> >>> Art Hunkins >> >>> >> >>> Mike G. wrote: >> >>> Art - the Python version is controllable in Sconstruct. It works with >> >>> 2.3, 2.4, 2.5, and 2.6 at present. Which version of Python do you need >> >>> Csound to work with, and how do you obtain or build Csound? >> >>> >> >>> - Original Message - >> >>> From: "Michael Gogins" >> >>> To: "Art Hunkins" ; "Developer discussions" >> >>> >> >>> Sent: Tuesday, July 07, 2009 3:13 PM >> >>> Subject: Re: [Cs-dev] Sugar on a Stick - and OLPCsound/Csound >> >>> >> >>> >> >>>> He says SConstruct has a bug, which he has patched. I think he's >> >>>> probably right, and I will patch SConstruct accordingly. >> >>>> >> >>>> The bug makes the installation not know the right name (soname) for >> >>>> the csnd extension module shared library. >> >>>> >> >>>> Regards, >> >>>> Mike >> >>>> >> >>>> On 7/6/09, Art Hunkins wrote: >> >>>>> Victor and Mike G. (especially) - >> >>>>> >> >>>>> You're familiar with my problems getting Csound5.10 working on SoaS. >> >>>>> >> >>>>> Aleksey, one of the Sugar developers, sent
[Sugar-devel] SugarCamp Bolzano 2009
Hi, added a topics section and some ideas about hacking to the wiki: http://wiki.sugarlabs.org/go/Marketing_Team/Events/Sugarcamp_Bolzano_2009#Topics http://wiki.sugarlabs.org/go/Marketing_Team/Events/Sugarcamp_Bolzano_2009#Hacking_ideas So feel free to add what you think it's important. Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [API proposal] Source editor and widget
On Mon, Jul 13, 2009 at 18:09, Lucian Branescu wrote: > I'm proposing the addition of sugar.graphics.sourceedit.SourceView. It > would be similar to what can be found in jarabe.view.viewsource. Exact > names of classes and/or module are up for debate. May be better if you first code your new stuff and then we discuss about merging it in the sugar-toolkit? viewsource.py doesn't add too much around gtksourceview2.View itself, so you may end up with more differences than similarities with viewsource.py. Regards, Tomeu > I'm also thinking of adding a FileView class in there, but I'm not > sure about it. > > > I've already seen almost the exact same code in Pippy and > viewsource.py; now I'm writing almost the same code in my branch of > Browse and it could be a base for the proposed Clipboard text editor > (http://wiki.sugarlabs.org/go/Features/Edit-panel-on-Frame). Thus, I > believe it's a common enough need. > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Decoupling of Sucrose (was Re: Initial implementation of toolbars design)
On Sat, Jul 11, 2009 at 19:42, Aleksey Lim wrote: > On Sat, Jul 11, 2009 at 06:15:21PM +0200, Tomeu Vizoso wrote: >> On Sat, Jul 11, 2009 at 16:53, Eben Eliason wrote: >> > On Sat, Jul 11, 2009 at 10:23 AM, Gary C Martin >> > wrote: >> >> On 11 Jul 2009, at 14:40, Aleksey Lim wrote: >> >>> On Sat, Jul 11, 2009 at 11:12:31AM +0200, Simon Schampijer wrote: >> >>>> a) DESIGN: discuss the design further and get some mockups >> >>>> together, one >> >>>> question that came up is: do we always have a one line secondary tool >> >>>> bar? >> >>> >> >>> Do you mean hiding sub-toolbars like palettes? >> >>> I'm using new toolbar in Memorize, and should say - its much useful to >> >>> have persistent sub-toolbar(and not auto-hiding them like palettes) >> >> >> >> Ebens designs describe both interaction methods: >> >> >> >> 1). If you hover over one of the new tab replacement buttons the >> >> palette appears (over the top of the canvas) and will auto-hide if you >> >> move the mouse way (just like any normal palette) >> >> >> >> 2). If you click one of the new tab replacement buttons the palette >> >> appears (and shifts the canvas down the screen) and is locked in >> >> place. Clicking the button a 2nd time unlocks it so it behaves like a >> >> regular palette again. >> > >> > Yup, that's the idea. I think it should be up to the activity, by the >> > way, to decide if any of the secondary toolbars are "locked in" when a >> > new activity instance is created. For instance, Paint might decide >> > that making the colors available by default is the wise choice. >> > >> > We should also institute policy for retaining toolbar state in the >> > metadata for a given activity entry in the Journal, so that resuming >> > restores that context. Perhaps this is something that the toolkit can >> > do so that activity doesn't have to think about it. >> > >> >>>> How would more complex widgets like the color chooser look like >> >>>> http://wiki.sugarlabs.org/go/File:ColorToolButton.png ? Or would they >> >>>> open from the secondary palette? >> >>> >> >>> I'm personally, +1 for >> >>> http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars#11 >> > >> > Just to be clear, this new toolbar design is in no way intended to >> > replace palettes in general. Instead, it's provided as a unique >> > alternative to tabs that allows palette-like interaction, but also >> > allows these secondary toolbars to be locked in place persistently, >> > which can be of great usefulness. Therefore, we needn't ask ourselves >> > "how does look/work in the new toolbar design?" at all. >> > We should be asking "which of " would work better >> > functionally as a secondary toolbar?". >> > >> > I think that Paint, for instance, would gain heaps of usability if the >> > colors were a secondary toolbar, and that were shown by default. That >> > doesn't mean that Write, for instance, necessarily needs to replace >> > the current color chooser palette. It's should be up to activities to >> > decide what parts of the UI are best suited to the two modes. >> > >> > Both primary and secondary toolbars can have as many normal "palette >> > buttons" as desired. >> > >> >> I guess one unanswered question is do you allow the stacking of more >> >> than 2 rows of toolbar... And, how much work is going to be needed on >> > >> > This is something we tossed around a little bit while designing them. >> > I think the answer is no, personally, since it adds a lot more >> > complexity to the UI, and also begins to consume too much of the >> > screen. I'm hoping that [primary toolbars > secondary toolbars > >> > palettes] are sufficient for most use cases here; we don't want to >> > wind up with MS Word-like feature complexity! >> > >> > That said, if we do support it, I think the rule is basically that >> > closing any parent toolbar hides all of its children, and reopening a >> > parent toolbar that had child toolbars open when it was last hidden >> > should reveal all those same children open as they were. But again, >> > I'd much rather just support
Re: [Sugar-devel] Initial implementation of toolbars design
On Mon, Jul 13, 2009 at 06:16, Aleksey Lim wrote: > On Mon, Jul 13, 2009 at 04:14:33AM +, Aleksey Lim wrote: >> On Sat, Jul 11, 2009 at 01:29:08PM +, Aleksey Lim wrote: >> > On Sat, Jul 11, 2009 at 11:42:19AM +0200, Tomeu Vizoso wrote: >> > > Another possibility is having Aleksey working on converting Write to >> > > the new toolbar and getting frequent feedback about it. Suggesting >> > > Write here because it has a crowded toolbar, could be the journal as >> > > well because we already have mockups. >> > >> > I've taken it >> >> New toolbars in Write >> http://git.sugarlabs.org/projects/write/repos/toolbars > > forgot to say, > this Write's clone needs > http://git.sugarlabs.org/projects/sugar-toolkit/repos/toolbars Here is a screencast showing Write with the new toolbars: http://shell.sugarlabs.org/~tomeu/toolbars_aleksey.ogv Excellent job! Will look at the code next, maybe tomorrow. Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] note about questions in #sugar
Hi, when someone asks a question in #sugar about a part of the project in which we aren't directly involved, it would be good to tell those people to try again at a later moment or send email to the mailing list. We have contributors from all around the world and the chances that the most appropriate person for replying that question is not around at a given time is quite high. It's ok with helping as much as any of us can, but I have seen several times that someone left the channel with well-intended but wrong instructions or with the impression that nobody in the SugarLabs community has that knowledge where it isn't like that. Thanks, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Background Screen Color for SoaS Activity
On Tue, Jul 14, 2009 at 04:21, Art Hunkins wrote:
> Gary -
>
> Thanks so much for these helpful suggestions.
At this point, I think it would be more efficient if you went through
the PyGTK tutorial. No need to do all of it, though.
http://www.pygtk.org/pygtk2tutorial/index.html
What is easy to do in some widget systems isn't as easy in others,
unfortunately.
Regards,
Tomeu
> With them I've been able to change the color of the basic Sugar display, and
> to create boxes of differing colors.
>
> Several major issues remain (which may not be surmountable?):
> 1) when text displayed on the basic screen (in no box) - that area reverts
> to gray;
> 2) importantly, nothing else displays in my colored boxes; this includes
> frames, other boxes, text and buttons.
>
> Can you guide me toward solutions here?
>
> I'm basically modifying Lazzarini's csndsugui.py. Here is the revised box
> code:
>
> def box(self, vert=True, colour=(0x, 0x, 0x), parent=None,
> padding=5):
> """creates a box
> vert: True, creates a vertical box; horiz.
> otherwise
> parent: parent box, None if this is a toplevel box
> padding: box padding
> returns the widget instance"""
> if vert:
> box = gtk.VBox()
> else:
> box = gtk.HBox()
> self.event_box = gtk.EventBox()
> self.event_box.modify_bg(gtk.STATE_NORMAL, gtk.gdk.Color(colour[0],
> colour[1], colour[2], 0))
> if parent:
> parent.pack_start(self.event_box)
> else:
> self.outbox.pack_start(self.event_box)
> self.window.set_canvas(self.outbox)
> self.boxes.append(box)
> self.event_box.show()
> box.show()
> return box
>
> I suspect that chaages in the last few lines are required (especially in the
> "boxes" line and probably the packing).
>
> And here is the current "text" code. I rather imagine if this could be
> gotten to display in a box with the box retaining its color, I might be on
> the way to success (but this may be the hard part; can other things be
> displayed "over" an event_box?). This code is straight from Lazzarini:
>
> def text(self, name, box=None,colour=(0,0,0)):
> """Creates a static text label
> name: text label
> box: parent box, None if text is to be placed toplevel
> colour: RGB values in a tuple (R,G,B)
> returns the widget instance"""
> label = gtk.Label(name)
> label.modify_fg(gtk.STATE_NORMAL,
> gtk.gdk.Color(colour[0],colour[1],colour[2], 0))
> if box:
> box.pack_start(label, False, False, 5)
> else:
> self.outbox.pack_start(label, False, False, 5)
> label.show()
> return label
>
> I very much appreciate your help. I, too, wonder if all this hassling over
> color is worth it. If only there were some simple way to make the overall
> display white instead of gray! I'm wanting the color change strictly for
> readability; I need more color contrast to read the text (which is
> unfortunately profuse in my project).
>
> Art Hunkins
>
> - Original Message - From: "Gary C Martin"
> To: "Art Hunkins"
> Cc: "Tomeu Vizoso" ;
> Sent: Tuesday, July 07, 2009 10:07 AM
> Subject: Re: [Sugar-devel] Background Screen Color for SoaS Activity
>
>
>> Hi Art,
>>
>> On 7 Jul 2009, at 03:46, Art Hunkins wrote:
>>
>>> Tomeu,
>>>
>>> I've had no luck modifying background color for anything except buttons.
>>>
>>> No boxes, even when the box is completely empty.
>>>
>>> Does anyone know how to change the color of the entire screen, or of a
>>> box?
>>
>> I can remember hitting my head on this when first playing with gtk. I
>> wanted a black area to place a moon image in. The trick seems to be using a
>> gtk.EventBox(). Have a look in moon.py at about line #114:
>>
>> http://git.sugarlabs.org/projects/moon/repos/mainline/trees/master
>>
>> Just quickly scraped out the lines I think might be interesting, does seem
>> quite a bit for just a black screen :-)
>>
>> # Create the main activity container
>> self.main_view = gtk.HBox()
>>
>> # Blackness
>> self.event_box = gtk.EventBox()
>> colormap = gtk.gdk.colormap_get_system()
>> self.black_alloc_color = colormap.alloc_color('black')
>> self.event_box.modify_bg(gtk.STATE_NORMAL, self.black_alloc_color)
>> self.main_view.pack_end(self.event_box)
>>
>> # Display everything
>> self.event_box.show()
>> self.main_view.show()
>> self.set_canvas(self.main_view)
>> self.show_all()
>>
>> Regards,
>> --Gary
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
