Re: [sugar] [support-gang] Microsoft
seth wrote: Of course. Sugar is not dead, just OLPC. That's why the fork occurred. Sugarlabs isn't a fork. The code bases are still the same and aren't going to change. It's more like upstream sources now. Or a forking of management, not code. devil's advocate: how would someone on the outside (of either OLPC, or sugarlabs) know that that is the case? all that has happened (from the public view of things) is that this new wiki has sprung up, claiming essentially that this is where sugar lives. there's been no announcement (that i've seen), and no corresponding announcement from OLPC, so an observer is sort of left to wonder what's going on. paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 57.4 degrees) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Log Viewer - View Log? (Was: [PATCH] Log Viewer overhaul)
marco pesenti gritti wrote: On Tue, May 13, 2008 at 9:31 AM, Morgan Collett [EMAIL PROTECTED] wrote: On Tue, May 13, 2008 at 5:46 AM, Eduardo H Silva [EMAIL PROTECTED] wrote: Forking the thread here, but I wonder if this activity could be renamed to something more closely following the verb standard, like View log(s)? Nitpick perhaps, but goes along my opinion that our dictionaries don't have enough verbs to exactly identify all activities that will appear, so adding a noun when necessary would improve things. How about Inspect or Diagnose? We have Analyze already, which is a separate activity. View Logs sounds good to me. Eben? since you bring it up, in my opinion Analyze suffers from incomplete naming as well. analyze what? though i know i've learned it twice before, to be honest i can't at the moment remember what it does -- all i can think of is that it's going to let me do some kind of science experiment. but it's something to do with system statistics or resources right? seems to me that names either have to be quite unrelated to preconceptions of their meaning (TamTam, Pippy), or fairly descriptive (Read, Browse, Calculate). and as eduardo points out, there aren't enough verbs to use verbs alone for descriptive names. paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 52.5 degrees) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
SJ wrote: SJ, who still wants the hand buttons to be mapped to the right and left mouse-clicks in addition to any other keymapping. can you explain this further? paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 43.7 degrees) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
eben wrote: The right button is going to be used solely to invoke palettes on objects/buttons (immediately, rather than on delay like rollover), which is nearly consistent with its use for contextual menus on other OSes, and should indeed be a time saver for more advanced users. I don't believe this actually works yet, unfortunately. having two buttons also greatly simplifies porting existing, non-sugarized, apps. again, that's mainly a benefit for advanced users, but it's a big one. paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 46.0 degrees) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
michael wrote: On Tue, Apr 29, 2008 at 01:42:04PM -0400, Paul Fox wrote: in the time i'd have otherwise wasted is free department, is there currently (or planned) a mechanism to always launch designated activities (either fixed choices, or choices based on recent journal entries) at startup? Personally, I have found extensible autostart mechanisms which process third-party data to be more useful to trojan authors than to users so I'm mildly inclined to consider such mechanisms to be a misfeatures really? i'm not sure where the third-party data comes into it. i suppose with browse, maybe, but my .xsession has started two xterms on my desktop for many years, and i've never considered it a security issue. just a time-saver. That being said, I'm quite interested in the tradeoff that you raise between finishing boot quickly so that the user can start doing what they want to do and extending boot with expensive precomputations so that (on average), the user gets to perform individual actions more quickly. the longer the boot time, the more it makes sense, because there's more chance that i'll be off getting coffee while it all happens, rather than waiting. (conversely, if boot time were very short, there would be little need for auto-start except as a convenience function, much like a function key is purely for convenience.) Also, where does hibernation fit in your taxonomy? i'd think that's pretty different -- coming out of hibernation should leave the system exactly as it was when it went in. (unless i'm misunderstanding.) paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 45.5 degrees) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
michael wrote: On Tue, Apr 29, 2008 at 02:15:54PM -0400, Paul Fox wrote: michael wrote: Personally, I have found extensible autostart mechanisms which process third-party data to be more useful to trojan authors than to users so I'm mildly inclined to consider such mechanisms to be a misfeatures really? i'm not sure where the third-party data comes into it. i suppose with browse, maybe, but my .xsession has started two xterms on my desktop for many years, and i've never considered it a security issue. just a time-saver. Depends. Any software you run can write to your .xsession, yes? Afterward, will you really notice an extra instance of 'bash', or 'kdmgd', or some other nonsense running in the background, capturing all your keystrokes, aliasing 'sudo', running 'xauth ++', setting up a spambot, or querying an IRC server for recent local root exploits? eek! time to retire. ;-) your point is well taken, but since any program i run manually can also write to lots and lots of things that i run, or use as config, i'm not sure why autostart makes a huge difference. and although i have little windows experience, i'd have to imagine the case is much the same vis a vis the Start directory. but perhaps there's a distinction i'm missing. Also, where does hibernation fit in your taxonomy? i'd think that's pretty different -- coming out of hibernation should leave the system exactly as it was when it went in. (unless i'm misunderstanding.) You understood correctly. It has been previously proposed that we should (more or less) always hibernate. I was curious if you had thought about the resulting system. if the system can yawn and wake up from hibernation appreciably faster than from a cold boot, clearly that will be a Good Thing. (for some reason this isn't noticeably the case on my current ubuntu (gutsy) laptop.) (this is wandering from sugar performance perceptions.) paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 45.0 degrees) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
michael wrote: On Tue, Apr 29, 2008 at 02:54:15PM -0400, Paul Fox wrote: michael wrote: Depends. Any software you run can write to your .xsession, yes? Afterward, will you really notice an extra instance of 'bash', or 'kdmgd', or some other nonsense running in the background, capturing all your keystrokes, aliasing 'sudo', running 'xauth ++', setting up a spambot, or querying an IRC server for recent local root exploits? eek! time to retire. ;-) your point is well taken, but since any program i run manually can also write to lots and lots of things that i run, or use as config, On an XO running a recent build (including 703), almost all activities are prevented from writing to interesting places like .xsession. We just invent new uids and gids (user ids and group ids) for them on demand. Also, there's plenty left to do to help control the current exceptions. this paragraph is an argument that autostart is okay on the XO -- not as dangerous as it is on my traditional workstation. i'm not sure why autostart makes a huge difference. i think i should have added ... from a security perspective. Avoiding autostart means that reboot is much more powerful - rebooting will actually have some chance of restoring your system to a workable state. It also gives you a small mischief diagnosis tool - you can do controlled experiments to determine whether your system does annoying things when you run specific activities. (We're thinking of trying to add some power usage monitoring and some network isolation that will further support this use.) Combined with a button or option on each activity that lets one wipe away cached state, this system will plausibly have achieved a new plateau of mischief resilience. i never considered that there wouldn't be a safe mode override for autostart. (just as you wouldn't implement hibernate without the ability to still do a true cold boot.) paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 46.2 degrees) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] State of Update.1, March 24, 2008
[EMAIL PROTECTED] wrote: On Mon, 24 Mar 2008, Michael Stone wrote: Folks, knowledge of Update.1 by updating tickets in Trac. Everyone else: get behind us, review these bugs, and help push out this release! See http://wiki.laptop.org/go/Test_setup_for_Update.1_builds for rough-cut instructions on how to try out update.1-70x builds. ... Then, the bad news: in a fascinating conversation with the support-gang (yay, support-gang!), it was made plain to me that recent Update.1 builds have received little or no testing by folks who aren't building them. In light of this datum, we should consider the question: who do we want to persuade to try out U.1 and what support do they need from us? well, depending on the answer to that question of who... the removal of the activities is still being sorted out. currently there is no straightforward way for a tester who previously could just do an olpc-upgrade to test the recent builds that have the activities removed. there are several scripts being developed to manage the activities, but no clear direction (or directions) in this area, just lots of people who seem to be working independantly. ...i'm one of the recent G1G1 recipients, having only gotten my machine in the last week or two. while that makes me less experienced with the hands-on workings of the laptop, it also means i have a lot less invested in customization, and i care less about the overall stability of the laptop at the moment. i suspect there are a lot of folks in my shoes -- even those who have had G1G1 units for months, for whom the major i'll lose my activities issue simply isn't that big a deal. in addition, i've done no updates at all yet (still running 656) partly waiting for the dust to settle, and partly because of the research i'll need to do to figure out how, and where, and what to upgrade _to_. so if trying update.1 were how i got my feet wet, that would be an impetus. if a Read This and Help! message went out on the forums (both laptop.org and olpcnews.com) that testing was needed, with explicit go here, click here, or type this instructions (the rough cut instructions linked to above are too rough, imho), i think G1G1 users would be happy to help test update.1 -- even though, as i understand it, it isn't planned as an auto-push until some later time. what _would_ be needed is some minimal completion (or perhaps, just documentation) of the pieces that david alludes to. i.e. i don't care if i lose all my current pre-installed activities, as long as someone gives me a bit of direction on where to find them again, even if it's a manual process. (preferably it would be _one_ manual process, and not one process per activity). of course, this all assumes that the added burden of supporting the G1G1 community in this effort wouldn't swamp the benefits of having them/us involved. i'm sure that's not a decision to be made lightly. :-) paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 30.0 degrees) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] icon assistance/validation
eben wrote: Do you think that making sugar-iconify a standard (and strongly recommended) step in creating proper sugar icons is a bad idea? What are your experiences actually using it so far? i think such a script is an excellent addition. as the OP of this thread, it would have helped me quite a bit. a few things, based on my experience writing my own (inferior) script the other day, and on using yours just now: - as cluttery as it feels, i think the script should create a backup (icon.svg~) of the original, by default, if it's going to overwrite the original. there could be an option to suppress this. - a guess behavior would be useful: rather than demanding the hex values for fill and stroke, the script could figure these out for itself, and either just go ahead, or confirm with the user first. this would also give an opportunity to warn if there are more than two values used for fill or stroke. (is this ever appropriate?) - does the script do anything at all with no options? i did this first, forgetting i probably needed -f and -s, and i then wasn't sure if anything had happened. if it nees options, then it should give usage() with none. many thanks for doing this... paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 32.5 degrees) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] icon assistance/validation
eben wrote: On Tue, Mar 18, 2008 at 10:38 AM, Paul Fox [EMAIL PROTECTED] wrote: - as cluttery as it feels, i think the script should create a backup (icon.svg~) of the original, by default, if it's going to overwrite the original. there could be an option to suppress this. Interesting point, and not a bad idea. Perhaps instead I could simply ask [y/n] at runtime if it is about to overwrite the old file (still with an option to suppress this prompt). that would be fine. - a guess behavior would be useful: rather than demanding the hex values for fill and stroke, the script could figure these out for itself, and either just go ahead, or confirm with the user first. this would also give an opportunity to warn if there are more than two values used for fill or stroke. (is this ever appropriate?) I hadn't thought about creating a guess algorithm. It doesn't, however, require passing the stroke and fill values -- it has a default of (#66, #FF) for (stroke, fill), which are the colors provided in the template icons, and probably the preferred look of the icons when listed on the wiki. oh yeah -- i forgot to mention the defaults. i don't think they're all that useful (hence my notion of guessing them), because there there are a lot of competing suggested values, none of which include #66, that i can find :-). bert said earlier that he uses: !ENTITY fill_color #CC !ENTITY stroke_color #00 a skim of the wiki search results for fill_color and stroke_color gives mostly fills of #ff and strokes of #00, and on the XO itself, i see the following: ==xo-14-83-DB,pgf(1) cd /usr/share/activities ==xo-14-83-DB,pgf(1) cat */activity/*svg | egrep 'ENTITY stroke' !ENTITY stroke_color #FF !ENTITY stroke_color #010101 !ENTITY stroke_color #00 !ENTITY stroke_color #010101 !ENTITY stroke_color #010101 !ENTITY stroke_color #00FF00 !ENTITY stroke_color #010101 !ENTITY stroke_color #010101 !ENTITY stroke_color #010101 !ENTITY stroke_color #d7e4f6 !ENTITY stroke_color #010101 !ENTITY stroke_color #010101 !ENTITY stroke_color #010101 !ENTITY stroke_color #010101 !ENTITY stroke_color #010101 !ENTITY stroke_color #010101 !ENTITY stroke_color #010101 !ENTITY stroke_color #010101 !ENTITY stroke_color #010101 !ENTITY stroke_color #00 !ENTITY stroke_color #010101 !ENTITY stroke_color #010101 ==xo-14-83-DB,pgf(1) ==xo-14-83-DB,pgf(1) cat */activity/*svg | egrep 'ENTITY fill' !ENTITY fill_color #FF !ENTITY fill_color #FF !ENTITY fill_color #FF !ENTITY fill_color #FF !ENTITY fill_color #FF !ENTITY fill_color #FF !ENTITY fill_color #FF !ENTITY fill_color #FF !ENTITY fill_color #FF !ENTITY fill_color #133c6d !ENTITY fill_color #FF !ENTITY fill_color #FF !ENTITY fill_color #FF !ENTITY fill_color #FF !ENTITY fill_color #FF !ENTITY fill_color #FF !ENTITY fill_color #FF !ENTITY fill_color #FF !ENTITY fill_color #FF !ENTITY fill_color #FF !ENTITY fill_color #FF !ENTITY fill_color #FF - does the script do anything at all with no options? i did this first, forgetting i probably needed -f and -s, and i then wasn't sure if anything had happened. if it nees options, then it should give usage() with none. It does indeed silently function, replacing the current icon, when no flags are passed. Of course, it does this by using ht e above mentioned defaults. Thinking about it, I may need better feedback in that case. I have a habit of always using the -v verbose flag, which makes it really easy to confirm that the entities were replaced properly. Perhaps the best feedback would be to count the number of entities replaced, and display a warning when none were replaced successfully. that would be good. paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 35.4 degrees) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] icon assistance/validation
kent wrote: On Saturday 15 March 2008 10:04:46 am you wrote: many thanks to gary and bert for their advice. i think i found the biggest issue with what i was doing: - inkscape lets you save your work as either a plain svg, or, by default, as an inkscape svg. don't save your work as an inkscape svg. in addition: - bert's suggestion of doing one's drawing in two colors (i.e., red and yellow) instead of gray and black, makes it easier somehow. It seems to me that Sugar uses color to signify the user, particularly when used through the mesh. I don't think it is an accident that all of the icons that are shipped with my XO are black and white. Have you had a different experience? no. but as far as i can tell, the colors specified in the SVG file are ignored by sugar, whether the icon is on the frame or on the ring, so which colors one chooses to draw with, or even ship with, seem to be immaterial. i think bert's (and then my) point was just that it can be easier to think about the design while drawing it if using colors, rather than black/grey. paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 32.9 degrees) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] spreading activity bundle contents across the filesystem?
bert wrote: On Mar 13, 2008, at 8:55 , Jani Monoses wrote: For emulation of sugar on regular boxes is there a way of scattering an activity instead of installing it under a single directory? The Debian policy for instance does not permit installing a .so under /usr/share and several activities come with prebuilt shared objects. I wonder if there's a simple enough change like an addition to a sugar-specific search path that would allow this with minimal disruption? I don't think so, since activity authors are free to structure the bundle any way they like. I'd rather suggest installing the bundles in, say, /usr/lib/sugar/activities. i'd think that requirements for a particular distribution, if they're not met by bert's suggestion, could usually be satisfied with symlinks pointing in one direction or the other. there are certainly examples of this -- qmail packages come to mind. paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 23.4 degrees) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] icon assistance/validation
i'm trying to design an icon for a new activity, and i'm having a heck of a time coming up with something appropriate. part of the problem is my inexperience with inkscape (the only svg tool that i think i have access to), but part of it's that i can't easily tell what the result will look like under sugar. (for instance, is there a way to turn the inkscape drawing background to black?) to really see the icon requires getting it onto my (emulated) XO, making it part of an activity, and restarting sugar. in other words, it's incredibly cumbersome. and then, i find that i did something new wrong for the Nth time, and have to repeat the process. (and in a scaled emulation, which i usually run because it's faster and usually more convenient, the icons don't throb or sometimes even display.) so, in no particular order, are there any linux tools to: - sugar validate an icon? i'm thinking of things like making sure all strokes are the same, all fills are the same (or unset), making sure that non-closed objects don't have a fill set, etc. - display sugary previews of the icon, in its various colored and b/w renditions, and various sizes? - automatically do the variable substitution required to make fill_color and stroke_color animatable? figuring out how to structure the icon by documentation isn't all that easy, either -- even though there are no fewer than 5 pages which describe parts of the process and guidelines. [ the rest of this message is a mild whine about the state of wiki with regard to icons. i know, i know -- i should spend my typing efforts fixing the problem, instead. but i had all this written before i realized that! ] http://wiki.laptop.org/go/Sugar_Activity_Tutorial this page includes some SVG header text, but doesn't say what one should do with it. the header text clearly assumes the rest of the icon has been written in a specific way. http://wiki.laptop.org/go/Sugar_Icon_Format this page repeats the header code snippets, but they're surrounded by in-line comments that question their accuracy. http://wiki.laptop.org/go/Making_SVG_Icons_for_Sugar has instructions on how to edit an existing SVG file to make it sugar-compatible. basically, it tells you how to make your SVG header look a little bit like the ones referred to by the above pages. but it assumes your icon already matches the guidelines. http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines/The_Sugar_Interface/Icons this is the meatiest of the pages, and talks about colors, and also a lot about sizes. however, it refers to S, M, L, XL as SVG icon sizes (Icons should be developed and saved at Standard (S) size), but in playing with inkscape i've seen no reference to these sizes, making the little chart in the middle of the page kind of useless. is everyone else using a different creation tool? http://wiki.laptop.org/go/Icon_Creation and finally, though it has the most promising name, this stub page contains absolutely nothing at all! i laughed when i found it. :-) failing to find any sort of real tutorial, or even a tips and tricks page, i went looking for a sample icon. other than a page offering to download over 800 non-sugar icons (no thanks -- i've already created a whole bunch of those ;-), i only found one sugar icon on the wiki. and it's unlabeled, and was apparently only uploaded as a wiki test: http://wiki.laptop.org/go/Image:IconRuler.svg (it's linked at the bottom of the Making page.) so. what have i missed? how is everyone else doing this icon creation thing? paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 30.4 degrees) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] how does an activity connect to the journal?
i wrote: where is the interface between activities and the journal documented? i'm not coming up with anything concrete when i search the wiki. (or alternatively, i'm coming up with too much to wade through.) two people have suggested (offlist, presumably to save me embarrassment ;-) that i look more closely at: http://wiki.laptop.org/go/Low-level_Activity_API certainly this page answers my questions about the X properties that are being set in the preload library. both referrers asked if there were things missing from that page. i'll try and comment on what i think could help someone like me. i do feel like that there could be more of a broad-brush overview, something like a Lifetime of an Activity section, that would describe the interactions of an activity with the various other sugar services, from start to finish. this would put the various piece parts of the api in context. i've looked (mostly via backlinks from this page) for such an overview, but haven't found it. maybe much of what i need is there and i'm just not seeing it. i get more from the wiki pages every time i read them, and i'm handicapped by not being a python guy -- remember that i'm porting an existing non-python, non-DBUS-aware app, and just trying to make it run the best it can. but i also think it's typical of a wiki that it concentrate on the details. the Dbus Methods section starts with An activity instance needs to create a DBus service, but there's no indication of why?. what specific user or system interactions will be enabled by creating this service? what specific things won't work if i don't? (also, a link to somehere describing how to [figure out how to] create this service for non-python activities might be useful here.) my activity starts (and terminates) okay, and anything it emits on stdout or stderr ends up in a log file under /home/olpc/.sugar (so some things are working), and it appears on the ring of running apps, but it doesn't show up in the journal. ah -- okay -- the Datastore section says my app must store its complete state in the datastore, to let it show up in the journal. but i'm not sure what complete state means -- that's pretty daunting, esp. for a program that already saves a lot of state in other ways. is there a minimum that i need to do / can do? and this is all accessed via DBUS? that's not completely clear from the page text. (and again, a pointer to how to figure out how to access the datastore/journal from non-python languages might be useful.) back to my logs: naively, i thought that since my messages were already being stored under ~/.sugar/default/logs/org.x.RoadMap-3.log, that i'd be able to access them without much trouble from the Journal. but apparently that's not the case? i guess this reminds me of something else -- for someone who's fairly new at this, the correspondence between the concepts of Datastore and Journal isn't obvious. the wiki pages all talk about the Datastore, but what the user sees is the Journal. (i think this hampered my initial searches, both when skimming pages and when actually entering searches on the wiki.) anyway -- thanks for the pointers -- i have a much better understanding of what needs to be done, even if i still don't know how to go about doing it. :-) i hope my comments have been helpful -- it should be pretty clear that i'm in no position to make additions or updates to the wiki myself, at this point. i'll try and help where and when i can, however. paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 16.7 degrees) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] how does an activity connect to the journal?
bert wrote: On Feb 28, 2008, at 15:10 , Paul Fox wrote: i do feel like that there could be more of a broad-brush overview, something like a Lifetime of an Activity section, that would describe the interactions of an activity with the various other sugar services, from start to finish. this would put the various piece parts of the api in context. i've looked (mostly via backlinks from this page) for such an overview, but haven't found it. Good point. I added an attempt to explain the life cycle of an activity to the Overview section. just took a look -- that helps a lot. thanks. maybe much of what i need is there and i'm just not seeing it. i get more from the wiki pages every time i read them, and i'm handicapped by not being a python guy -- remember that i'm porting an existing non-python, non-DBUS-aware app, and just trying to make it run the best it can. but i also think it's typical of a wiki that it concentrate on the details. That page is actually written by a non-python guy for fellow non- python guys. It only uses pseudo-code (although that pseudo-code is inspired by Python). i forgot to mention -- i'm also a non-Dbus guy. :-) the Dbus Methods section starts with An activity instance needs to create a DBus service, but there's no indication of why?. what specific user or system interactions will be enabled by creating this service? what specific things won't work if i don't? (also, a link to somehere describing how to [figure out how to] create this service for non-python activities might be useful here.) The Sugar shell will (try to) call the methods listed in that section. The rationale for each method is given there, too. okay. i guess i thought there might again be a higher level view. how do activate/passivate (nice word :-), screenshots, invitations, fit into the lifetime-of-an-activity view of things? For a basic understanding of what an activity is (in contrast to regular apps), you should read http://wiki.laptop.org/go/HIG yes, i certainly need to read that more completely. back to my logs: naively, i thought that since my messages were already being stored under ~/.sugar/default/logs/org.x.RoadMap-3.log, that i'd be able to access them without much trouble from the Journal. but apparently that's not the case? Logs have nothing to do with the Datastore. right. i think i've been misled by by my own preconceptions. having said that, is there a way to view the contents of ~/.sugar/default/logs outside of the terminal? paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 22.8 degrees) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] how does an activity connect to the journal?
tomeu wrote: On Thu, Feb 28, 2008 at 3:10 PM, Paul Fox [EMAIL PROTECTED] wrote: ah -- okay -- the Datastore section says my app must store its complete state in the datastore, to let it show up in the journal. but i'm not sure what complete state means All the data that your activity needs to restore its UI and underlying model as it was when it was closed. okay -- i'm beginning to understand the notion of instance more completely, and the notion of any past instance in time being resumable. i didn't get that before. -- that's pretty daunting, esp. for a program that already saves a lot of state in other ways. In which other ways? Can you elaborate? well, like many existing non-sugar programs, this program creates a subdirectory in $HOME and saves some state there. it's a mapping program, so things like current location on the map, current zoom level, name of of the GPS route being followed, the current GPS track, etc. also per-user configuration: personal landmarks, trips, previously saved tracks, etc. (this app is clearly a long way from being sugarized, and probably never will be.) is there a minimum that i need to do / can do? and this is all accessed via DBUS? that's not completely clear from the page text. (and again, a pointer to how to figure out how to access the datastore/journal from non-python languages might be useful.) Some activities have already done that. One that comes to my mind is eToys. You certainly don't need to implement state saving to the perfection. Having something working quickly and then keep improving would make sense. i'll take a look at eToys. clearly a minimum of where on the map was i? might be good state to be able to resume. that. The Journal is not supposed to access arbitrary data on the file system. If you explain what you want to do with the logs someone might be able to help. as i wrote in the other mail, it was more of an assumption that i made, that i should be able to see that data. (it's actually not very important, except to the developer. but that happens to be me. ;-) paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 22.5 degrees) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] how does an activity connect to the journal?
tomeu wrote: Yeah, it's a very important concept and perhaps it's not clearly stated in the wiki documentation. Do you have any idea about how to improve this? Perhaps the HIG should make this clearer? it may be there already. i need to spend some more quality time with the HIG document. -- that's pretty daunting, esp. for a program that already saves a lot of state in other ways. In which other ways? Can you elaborate? well, like many existing non-sugar programs, this program creates a subdirectory in $HOME and saves some state there. it's a mapping ... Would make sense if the file in the activity entry would be a zip file containing all other files? Or those files would be somewhere else in $HOME and the entry would contain only little bits of state? perhaps. paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 23.7 degrees) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] clarification of SUGAR_ACTIVITY_ROOT
bert wrote: On Feb 27, 2008, at 4:20 , Paul Fox wrote: - what if my activity might have larger data needs than can be accomodated on the root fs? what if i'd like to use space on a removeable device? is there a way to ... This is not possible in the current datastore design AFAIK. Removable devices are supported as mount-points in the datastore but cannot currently be used to create files there without an intermediate copy in the root fs. The datastore redesign is supposed to address this problem, e.g. to allow the Record activity to directly record movies onto a USB drive. okay -- thanks. that tells me what i need to do, for now at any rate. paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 33.4 degrees) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] how does an activity connect to the journal?
hi -- where is the interface between activities and the journal documented? i'm not coming up with anything concrete when i search the wiki. (or alternatively, i'm coming up with too much to wade through.) my activity starts (and terminates) okay, and anything it emits on stdout or stderr ends up in a log file under /home/olpc/.sugar (so some things are working), and it appears on the ring of running apps, but it doesn't show up in the journal. the app is an existing app that i'm sugarizing with the assistance of an LD_PRELOAD helper called libsugarize.so that i found via one of the forums. it seems to do some fixups on various X11 properties based on various SUGAR_XXX_ID variables found in the environment. (the author of this _might_ be Albert Cahalan, but the sources are unsigned.) in any case, i'd like to find some better docs in order to a) figure out why the activity doesn't appear in the journal, and b) to better understand these X properties that are being munged. any and all pointers or tips welcomed... paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 29.5 degrees) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] clarification of SUGAR_ACTIVITY_ROOT
hi -- newbie activity developer here. i'm trying to get an existing app working as an activity, and i'm trying to keep it well behaved i don't quite understand the SUGAR_ACTIVITY_ROOT variable. the wiki says that it's Writable space for the activity Activities are prohibited from writing anywhere else in the file system., and at http://wiki.laptop.org/go/Low-level_Activity_API#Security it refers to three virtual subdirectories, and describes the data, instance, and tmp directories. when i track down its value while my activity runs, it leads to three very un-virtual subdirectories somewhere beneath /home/olpc/.sugar. so... - what's the virtual part mean? can the directories referred to by SUGAR_ACTIVITY_ROOT move around? - what if my activity might have larger data needs than can be accomodated on the root fs? what if i'd like to use space on a removeable device? is there a way to manage this? the activity is a street mapping program, with the ability to download map data. map data always takes tens, if not hundreds, of megabytes. (i.e. all of texas takes 300M, all of rhode island takes 8M.) paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 32.4 degrees) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
