hi everybody, lets wait a moment i hope marcopg can make it too... hi erikos hi everybody hi folks * jedierikb (n=root@host242.155.212.201.conversent.net) has joined #olpc-meeting hello * _sj_ (n=sj_@wikipedia/sj) has joined #olpc-meeting benzea: great you can make it as well :) morning I'll need to reboot into a kernel that does not nuke xfs soon ;-) but yeah, I am here :-) hi all * sebastiansilva (n=sebastia@200.121.134.29) has joined #olpc-meeting * rwh (n=rwh@84.244.132.193) has joined #olpc-meeting while we're waiting I'll just post the agenda url, 3 items so far: http://wiki.laptop.org/go/Sugar_dev_meeting#Tuesday_March_4_2008_.28.22big.22.29 hi there added one more item hi rwh ok lets start then... bbiab as most of you have already seen eben posted the new design ideas for the sugar refactoring: http://wiki.laptop.org/go/Designs (in case someone has not seen this yet) implementation has started, but it's not too late to discuss it and propose changes tomeu: shall we discuss this now? erikos: not sure, anybody wants to? erikos: I wasn't referring to discussion in this meeting, but in general tomeu: looks like quite a bit of work again :) yeah, but it's going to be *so* much nicer :) rwh: yeah, but it's quite fun one thing which relates to the next item (me) is that activities will show up in both activity list and journal for consistency, I think they should have detail view (tags) accessible from activity list - that's not in the slide show. you can track new development in http://dev.laptop.org/git?p=users/tomeu/sugar;a=summary homunq: yeah, I'm not sure if that was left for a later milestone. eben_? ooh, may I add an agenda item? I'd love to know if anyone's been looking at the "faster" branch python speedups. I think they are awesome. cjb: sure free to add homunq: I'm not sure about that actually. I think if they do appear in both lists, it may be clearer to differentiate the spaces by reserving tagging/management for the Journal interface. cjb: I would say those optimizations are a must to get in soon rwh: cool, glad to hear homunq: We do, on the other hand, think it's worth exposing some common tags (such as version number, and other identifiers contained in .info) within the activity list. we can come back to this after the current agenda item, sorry. another request is to have the first 3-4 characters of a text clip show in the left frame eben_: does that mean that activity list search is not tag aware? homunq: see wiki.laptop.org/go/Specifications/Clipboard; there is extensive thought put into how the clippings should look. homunq: The search will be tag aware. I'm just unsure about embedding a button directly within the list view which transports one into a page of the Journal. (Or, contrary-wise, presenting a page that looks as though it's "torn from" the Journal within that view) I would vote for the latter ("torn from"), understanding that it is a trade-off and other opinions are valid _eben: Do you think the "make journal more part of the shell and less like an activity special case" is a dead end now (old wars)? Just wondered if anyone else feels it's odd having journal show as a special case activity. I think that there are arguments either way, but I do want to retain the icon, and I don't want to confuse the spatial zoom metaphor. also wrt clippings, I don't see on the page you referenced an argument why clip icons can't have titles. (love the "keep" option in the clip rollover, though) :-) ok that's a no, I'll step away from this one quietly. * mchua (n=mchua@cpe-66-108-80-238.nyc.res.rr.com) has joined #olpc-meeting The magnifying glass on the keyboard came from the opposite direction...thatkey had 3 other icons/uses in designs before that, and at some point a "search" key was thought to have potential use, and eventually (as it had none assigned) we made it jump into the Journal.... Well, it's not a strict "no", but I was a strong proponent of the very idea you're bringing up early in the redesign phase, and we tried a lot of options both ways...the current, we feel is still the best among them, though not perfect. :) ++ The search key is about the most used 'special' key for me, though that might drop off with the new designs as resume is the new norm behaviour. * mchua is now known as mchua|testing_aw * mchua|testing_aw is now known as mchua_test_away homunq: Clippings don't have "titles" because they don't come from a named object (eg. "shark.jpg" or "My story"). All clippings, however, should have a preview when possible; text clippings will reveal the first sentence or two, since that's the most meaningful preview for them. eben_: I understand the desire to have the frame purely iconic, but if you are working with text clippings you can be assumed to be literate... Currend GUI is poor for getting to Journal, you have to click Home, then click Journal in the ring (lots of slow flickering redraws). The new design also nicely fixes this too. homunq: It's a question of where the preview goes. There's very little space in the frame itself. We opted to include full previews, of text and images, in the palette for a clipping instead. just from my use case, having a clipboard stack is nearly useless if they are identical icons but would be great if there were some reminder of which is which. and having to go browse the rollovers is an extra step. as I said, 3 or 4 characters would be plenty. anyway, that's my vote. I don't want to tie up the meeting, though. ok any other thoughts about the redesign? - you can post on the ml or make it a subject for next week as well sugar-control-panel: let's hear it for the New Way! hip hip.... heh, which New Way? eben_: do you have mockups or gave it any thoughts? sorry I was just trying to find a way for us all to say "good job eben" erikos: There is a single screenshot attached to a ticket somewhere....hang on... http://dev.laptop.org/~erikos/controlpanel.png i thought about something like this as a first page I will say "good job, eben" when I don't see too much work in my platter ;) all the available options are placed on the canvas and by clicking on it you get to the detailed view like in the journal and maybe when we have more options we can make it tabs like (network, personal, system...) Here was a first pass: https://dev.laptop.org/attachment/ticket/6435/settings.png eben_: ok this is similar to the gnome one eben_: so is this fullscreen, no regular toolbar across the top (done at bottom rather than an exit at top) It's definitely fullscreen, akin to a modal alert. (In fact, it could be implemented with that API, once it exists.) eben_: and the frame could appear while the dialog is up? eben_: what happens when you click on the left groups (like network)? you will only display the group on the right? * mtd (n=martin@ops-13.xades.com) has joined #olpc-meeting tomeu: No, I think modal alerts will supersede the Frame. eben_: fullscreen is a bit similar to a zoom level, might be confusing erikos: It is organized into pages, where each tab corresponds to one page. Each page is broken into sections. erikos: We have a "better" design for modal alerts that would prevent this, but it requires compositing to work. I think that when we darken the screen around the panel, it will be clear what happened The ideas design is a box that fills the screen, minus a 75px border. This border would be dimmed, but leave the underlying context visible. aak, no frame? I can see a little kid getting stuck. How it this UI activated, just from some home menu? homunq: Well, that's in a way the point. Modal alerts require you to be stuck, and either confirm or cancel the actions. tomeu: even without darken it - if it is modal it is quite clear what happened i think OK well at least a check mark next to done to make it visibly keyboard-accessible. Esc will dismiss it, right? The home XO will have an option like "About my XO" from which these kinds of things can be adjusted. tomeu: esc will always be mapped to cancel....I question mapping it to a button with a confirmation, yet I see the desire to make that work. * bertf needs to drop out. sorry ... * bertf has quit ("Leaving.") tomeu: Another option is to offer both "cancel" and "confirm" buttons, so that you can undo any settings changes you made when leaving. Then the esc/enter mapping is clear. So when editing these settings you are blocked from using any other activities, so if your reading a web page about what setting you should tweak, you're screwed? yupe, that seems nice to me eben_: i mean if you click on network on the left, is then only network group displayed on the right, or highlighted and placed at the top erikos: only the network page would be shown. eben_: ok good eben_: at the moment we do ot have a lot of settings, so we then place them all on one page and make the code extensible for later? * homunq imagines search results filtering the list and highlighting in the page, but realizes that is not an urgent question. homunq: I'd like that too, for sure. :) This could still be rethought, too. It was a quick sketch. Something like the OSX dialog could work as well. Nicely iconic, nice search interface. I'm still worried about blocking the UI, it means you cant give instructions easily via online docs without making a kid write it all down first. I think I like more the design in trac rather than the one in osx * jgay (n=jgay@fsf/staff/jgay) has joined #olpc-meeting garycmartin-ff33 has a point eben_: what do we exactly win from making the dialog modal? * dwmw2 is now known as dwmw2_gone tomeu: Well, the basic dilemma is this: in our non-windowed environment, everything is either an activity, a zoom-level, or a dialog. * homunq wonders what dialog would ever need to be system-wide modal as opposed to activity-context modal. homunq: One example is that for changing channels on the mesh....doing so interrupts all shared activities. homunq: the system properties dialog ;) if "modal" only meant one context, this could take over home view but those examples don't mean that you can't keep doing unrelated things until you decide. But why modal, nothing happens until done is clicked I assume, this couldjust be a regular activity (but lets not go there ;-) I understand system-wide grabbing focus, what I don't understand is keeping it. homunq: yeah, I can see that point. homunq: Perhaps modal dialogs always pertain to the "place" they are invoked. Would that ever get us into trouble? eben_: well, I always thought that modal dialogs in activities would be local to that activity homunq: One example might be a modal dialog that says "Your battery is critically low." You wouldn't want to allow the kid to switch to an activity and ignore that. eben_: like the object chooser tomeu: Right, that's true. tomeu: OK, so we can make it home-modal, then. I don't really see a problem with that. eben_: why not? If they don't understand "OK", then they are either gonna respond to it or no, why tie their hands? eben_: you mean that only the home view is blocked but you can switch to another activity? tomeu: Yeah, that's fine. Let's make it home-modal only. We should just add a parameter that allows modal dialogs to be system-modal if we need it (for things like the low battery case). agree with homunq - it is only an alert about what is happening - but you are free to react as appropriate erikos: yeah * homunq has seen naive users say things like "this core dump dialog message always makes me crash, why don't you remove it" eben_: could be a technical problem... homunq: Heh, fair enough. I must say I can't think of a good reason for using a blocking UI - every other OS has been trying to remove modals for years. eben_: modal windows have a "parent window" eben_: for activities that's the activity window eben_: for the shell, that's the desktop window tomeu: I see. So for the battery case we're talking about a "top level window used as an alert" instead of a "modal dialog". OK. :) eben_: not sure how that would work for a totally modal window. marco will know for sure garycmartin-ff33: eben_ loves to do things unlike every other OS tomeu: The battery dialog is not unlike other OSes, is it? OSX, I believe, does (almost) exactly this. You can still interact with other windows, but the alert remains on top at all times and can't be dismissed. tomeu: is it bound to a parent window, when you have an alert up it is persistent over zoom levels eben_: haven't seen that, my last mac didn't had a battery ;) tomeu: yea I know and realy like the bravery involved, but modal anything just annoys or confuses many folks. What are users being prevented from doing that requires a modal to lock the up? erikos: all the zoom levels use the same window * bertf (n=bertf@p4FD59F12.dip0.t-ipconnect.de) has joined #olpc-meeting erikos: they are CanvasBox in one only HomeWindow tomeu: so we hide the alert window when we switch the zoom level tomeu: ok thanks garycmartin-ff33: yup OS X battery diag, yea you can dismiss it can carry on with life. garycmartin-ff33: We certainly tried at all costs to prevent modal dialogs where possible, and even tried to keep non-modal ones to slim, inline notices that don't obscure the activity. garycmartin-ff33: But I think there will be a handful of cases where they are necessary, if only because the contents of the dialog requires more space and would obscure most of the activity/view anyway. * homunq nominates erikos to facilitate. Since we don't have support for swapping window depths, it's clearer to center the content and grab focus until it's dismissed. homunq: ? homunq: you mean to go to next point in agenda? I mean you decide that. better than nobody deciding that. well yeah we should probably go to the next point :) OK that's me right? and keep this discussion on in the ma ml that was homunq: your time :) I have been working on develop, I've had to go into sugar in several places. eben_: yes I accept an activity can require being blocked by a modal in some cases (data chooser is a good example), but not for something system wide. The only one I can think of for OS X is a kernel panic, where you just have to rebood. bundlebuilder, activity, journal, and datastore, so far. most of that has to do with the fact that I'm using activity bundles as my native mime type (for obvious reasons) garycmartin-ff33: and battery! (but yes, I admit very few cases; I can think of no others) (sorry slow typing, onto develope) bundlebuilder needed refactoring anyway, I made it have a Bundlebuilder class with instances that live in a given directory instead of basing everything off of the working directory old calls still work activity had an init parameter called ?? create_jobject or something homunq: Yes, I agree with this. I think that every bundle should be treated as a regular "object" in the Journal. Some "special" bundles (ie. executable ones) can be run themselves, but all should be able to be opened by activities like Develop and Bundle, etc. if this was false, it set its jobject member to None but then soon crashed by trying to do things to None. I have mostly fixed that and will soon have it all better. Journal and datastore assumed that an activity bundle was a special case and there was only one thing to do with that homunq: create_jobject was intended only for the journal, as every other activity would have to create a journal entry of some kind this is what eben_ is taking about well, I was using it to delay creating a journal entry until I had a sane context since "develop" on nothing is meaningless, and if you hit "cancel" on the initial "what do you want to work on" dialog, there is no point in making a journal entry. .... homunq: well, shouldn't be there an entry in the journal because you have been using Develop? homunq: This is a more general problem, actually. the problem we have is that we are mixing actions ond objects, currently tomeu: We need activities to know when they are "dirty"....If I open an activity and don't DO anything, I don't need a blank file in the Journal. tomeu: With the object/action split, I *might* get an action entry which says I opened the activity, but I wouldn't get a corresponding object file. eben_: it still does not make much sense to record that eben_: hmm this is a problem indeed for example the terminal activity does not save or load anything but still take space in the journal homunq: I might be misunderstanding you, but it's not safe to say that just because one doesn't select an activity to edit that they can't be doing meaningful things (like making one from scratch) like if you accidentally laucnh an activity you would not want an entry bertf: Yeah, I agree, but I wanted to clarify the distinction in any case...it may be up to the activity to decide what's appropriate. my work on journal and datastore is not started yet, but they have a stack of "get_activities_for_mime_type" functions, if an activity bundle is no longer a special case and goes throught that stack, then the "start this activity" has to be part of the list that gets returned, I am not sure where in that function stack to insert this into the list (sorry I am listening to the dirty discussion but this is separate) bertf: It might, for instance, make sense to say "you looked at this photo album today" even if you took no new photos. erikos: well, it takes visual space, but perhaps the action is worth of being recorded? eben_: the two options are choose existing and make from scratch. but "cancel" is a third, or you can just kill the dialog. eben_: right about the dirty thing homunq: In the case of cancel, you just stop the activity? yeah homunq: I think I'd prefer to get the "dirty" stuff working and skip the cancel business. The options should be to edit one, or start clean; no cancel. They can just stop themselves through standard means, I think. OK I can remove the cancel button, but there is still the close activity button in the toolbar. yeah, dirty would mean "something worth recording has happened since start or since the last save" homunq: Right, we need to make that work sanely when nothing changes. tomeu: hmm maybe true - it is a tricky case - i am quite unhappy when i need to scroll yes because I need that too homunq: activity bundles don't need to be specialcased anyway because can be executed? when you start to edit an activity, I keep a copy of the initial state for safety so if you don't edit anything, I don't want to have to save. erikos: if the terminal never says it is dirty, perhaps no entry would be created for it? I was going to implement that as special logic, but if it fits in "dirty" all the better. tomeu: the only thing "special" about them is that they can "execute themselves" eben_: do you think that's not much? eben_: and from the code pov, they cannot be executed themselves, there are some other components that will execute them eben_: we are talking now about impl, I think tomeu: It's obviously makes them unique, but we shouldn't prevent basic properties of objects from applying to them. eben_: by preventing you mean not allowing other activities to act on them? * homunq confused, did we switch from "dirty" to "bundles"? They should have an icon, tags, description; they should be able to be opened (themselves, instead of with something else); the should be able to be sent; other things should be able to open *them*, etc. tomeu: or maybe there is an visual distinction between a made a change or i did not, not sure though _eben: all true except the latter right now. I mean eben_ eben_: yeah, sure. but all that happens right now erikos: Well, consider the mockup: http://wiki.laptop.org/go/Designs/Journal#01 eben_: bundles in the journal are like any other entry, only that they can only be launched and not resumed with another activity erikos: Look at the "wrote" and "read" lines for "HIstory of Thailand". homunq: the only thing missing in the journal for develop is that activities that register for opening bundles, appear in the resume palette, right? tomeu: Heh, OK. So fix that one little bit. The only difference is that they can be launched. eben_: oh cool was not aware of that, good job tomeu: yes that is true. However... Other activities need to be able to use them. homunq: however? ;) ... I think the details view on an object should have a draggable apps that can open this list with the top one being the general default and another box above being the default for this instance. homunq: sorry, could you elaborate? I look at the details on a text file. called "foo". It says "foo" will open with etoys, files like this can open with write, etoys. I can drag that around. the "write" is in bold because it's first. * jgay has quit ("Ex-Chat") this is a future UI concept of mine, but for now, drag what around? the sentence? Sorry, not seeing the picture clearly. there is a vertical list. Like the list in the palette under the resume button... etoys, separator, write in bold, etoys not bold you can drag to reorder it. Ahhh, I see. Well, could equally be implemented as a popup instead of a list implementation left as an excercise for the reader :) just a concept for functionality. But I see the idea now. I wonder if opening a given object in another activity will be frequent or not. the first "etoys" would be file-specific, the rest of the list would be general for mime type/ this lets you replace write with your preference homunq: So you see this as a way to set default associations? activities could request a preference for files they created yes homunq: Maybe we could use an interface just like that within the control panel. homunq: I think it might be unclear to make global changes within the detail view for a single object. ... but mostly they wouldn't, mostly they'd let the user decide. But the thought is a good one. anyway, just a thought. back to realit. if bundles are not a special case which only runs homunq: ok, so for now we can just change the journal so it also allows to start the bundle in any activity that registers that? then somebody needs to say that bundles can run. Who is that somebody? datastore.py? homunq: why it is not a special case that, apart from being started in activities like Develop, can be run by themselves? registry.py? homunq: that would be easiest in impl at a quick glance, I can't find the registry that is behind dbus. I was just reading up on dbus when the meeting started. registry.py is only the one in front, AFAICT easiest impl would be datastore.py, it has the special case now. so I'd have to touch it anyway. but cleanest would be to have it in the list from the start. from behind dbus homunq: hmm, I would prefer to special case closer to the UI OK, datastore.py it is. homunq: and journaltoolbox.py, so we choose Develop in the palette of course. homunq: if I'm not mistaken, this looks as a simple change such that, if we all agree, could get into git really soon OK. That was what I needed to talk about. I could talk about my ideas for a full-featured search UI but I think I've gone on long enough. (the next needed feature for develop) homunq: is there a ticket about what changes develop needs? (the ones we just discussed) um, there is a ticket about bundlebuilder the other stuff, not yet. something like "Journal should let activity bundles be started in Develop" would be good ok homunq you have an action item :) I will do one for activity.py, a separate one for "dirty", and one for datastore/journaltoolbox homunq: I think we already have a dirty one, will check OK. homunq: can we move on? yes homunq: what needs to be changed in activity.py? (sorry if you told earlier) the create_jobject stuff for not just crashing when jobject is none. Speech synthesis: (who wants to discuss that?) I have it working. homunq: that won't be fixed when we implement is_dirty correctly? erikos: me oh tomeu :) erikos: just added it because those people are asking me periodically about how they can go forward are they around? tomeu: a full is_dirty fix includes this fix, but the current code is just buggy. A blocking bug for dirty, but separate. eben_: what are the plans for integrating speech synthesis in sugar? they are waiting for you to tell them erikos: don't thinks so, I think people in india are sleeping right now? tomeu: Well...... tomeu: oh they are from india tomeu: We have thoughts about a slightly modified approach to toolbars, which could potentially eliminate the activity toolbar itself.... Provision of a control panel for modifying speech synthesis parameters? If that were the case, we'd have to think more about how to integrate this level of service. Otherwise, it should be relatively easy to add a button for this in the activity toolbar and attach a palette to that button for the parameters. erikos: yea I'd like system wide prefs too. eben_: if you would prefer to have just a shortcut for now, that could suffice eben_: we don't need to go for the final solution yet if that's not clear eben_: but as they are so willing to work on this, I think we should let them progress if possible tomeu: OK, well then let's choose a shortcut for now, so we can get it in there and test it out....we can expose it visually once the path to doing so is clear. * homunq also was going to mention, totally unrelated, that a Spanish livecd just went online thanks to sebastiansilva: http://fuentelibre.org/trac/wiki/LiveCD eben_: fine, could you answer that email I linked to in the wiki page? If we're going to use a shortcut, it would be very positive to add a "Speech" section to the "Language" page of the control panel for setting defaults. tomeu: OK. :-) * gregdek has quit ("Ex-Chat") its janis hardy packages + xubuntu in spanish + little customization, no biggie - i hope it helps eben_: garycmartin-ff33 yeah maybe it is the best place sebastiansilva, homunq: I'm very happy to see the community in latin america getting so active and sugar in other distros is very important for the future, I think tomeu: i'm sure we'll see an explosion once these babies get their XOs sebastiansilva: I hope it won't be the battery what'll explode :p we're getting ready for that but yeah, many different profiles of people will benefit from that the hazzard / instruction icons at shutdown aren't reassuring regarding battery explosion yeah, adults like to scare children ok sorry to bud into the meeting my fault sebastiansilva: i think this was the ext point yeah, we have been on track: http://wiki.laptop.org/go/Sugar_dev_meeting#Topics tomeu: uff :) we can move to the faster branch then? yup cjb: we finally are at faster branch now tomeu: you did the changes - so what is the status of this ? I haven't had a chance to test a faster build....can someone summarize the progress? cjb: which changes are in faster that affect sugar? just the prefork hack I did? so I guess nobody tried the faster builds ? i did not try them yet :/ tomeu: downloaded and all ready to rock, but I'm using the XO for the IRC and thought I should keep it stable ;-) I think that my hack created problems with security cjb: regarding sugar it is on the latest roadmap - so we want to work on it (if this answers your question) the point is that I don't know if I should devote time to the prefork thing I remember that m_stone said in some ticket that some changes would need to be done in the kernel so security is not compromised by that if you get it working to where you can prefork yourself, it would help with everything :) As forewarning, I think that we're going to require some kernel work in order to get decent privilege separation in the launcher (which needs to fork, then cause the uid of the child to change). from http://dev.laptop.org/ticket/2276 homunq: preforking myself? that would be good in the mornings looks like it would be good if m_stone elaborate a bit on this yup, I think he is busy with deplyment stuff maybe we should leave it for the meeting here ? but he said he is interested in seeing this get into update.2 yup, I'm ok with stopping now sure maybe he will comment on the minutes then yup cool thanks everyone - was a long one tonight... yeah, have to leave now thanks for being our host erikos thanks, good afternoon :) cheers! * tomeu has quit ("Ex-Chat") garycmartin-ff33: try to host more stricter next time :) :-) * garycmartin-ff33 (n=urk@user-54430d6c.lns4-c7.dsl.pol.co.uk) has left #olpc-meeting * bertf (n=bertf@p4FD59F12.dip0.t-ipconnect.de) has left #olpc-meeting