« Previous day | Index | Today | Next day » Channels | Search | Join
All times shown according to UTC.
Time | Nick | Message |
---|---|---|
00:58 | garycmartin has quit IRC | |
02:20 | Ariel_Calzada has quit IRC | |
02:25 | Ariel_Calzada <Ariel_Calzada!~aricalso![]() |
|
02:26 | Ariel_Calzada has quit IRC | |
02:34 | Ariel_Calzada <Ariel_Calzada!~aricalso![]() |
|
03:59 | Ariel_Calzada has quit IRC | |
04:30 | Ariel_Calzada <Ariel_Calzada!~aricalso![]() |
|
04:56 | Ariel_Calzada has quit IRC | |
10:38 | Ariel_Calzada <Ariel_Calzada!~aricalso![]() |
|
11:16 | tch___ <tch___!~tch![]() |
|
11:20 | garycmartin <garycmartin!~garycmart![]() |
|
11:35 | gonzalo_ <gonzalo_!~gonzalo![]() |
|
11:57 | Ariel_Calzada has quit IRC | |
12:09 | satellit has quit IRC | |
12:09 | reubencaron has quit IRC | |
12:09 | bertf has quit IRC | |
12:10 | satellit <satellit!~satellit![]() |
|
12:10 | reubencaron <reubencaron!~reubencar![]() |
|
12:10 | bertf <bertf!~quassel![]() |
|
12:21 | satellit has quit IRC | |
12:21 | reubencaron has quit IRC | |
12:21 | bertf has quit IRC | |
12:22 | satellit <satellit!~satellit![]() |
|
12:22 | reubencaron <reubencaron!~reubencar![]() |
|
12:22 | bertf <bertf!~quassel![]() |
|
12:23 | cjb has quit IRC | |
12:24 | cjb <cjb!~cjb![]() |
|
12:26 | Ariel_Calzada <Ariel_Calzada!~aricalso![]() |
|
12:41 | Ariel_Calzada has quit IRC | |
12:41 | Ariel_Calzada <Ariel_Calzada!~aricalso![]() |
|
14:23 | caspar <caspar!~caspar![]() |
|
14:29 | JT4sugar <JT4sugar!~JT![]() |
|
14:30 | daroal <daroal!~daroal![]() |
|
14:30 | garycmartin | Hi folks, design meeting about to start here :) |
14:30 | Cerlyn <Cerlyn!~ALEIN![]() |
|
14:31 | satellitSNFact <satellitSNFact!~urk![]() |
|
14:31 | pflores <pflores!~pflores@r186-48-37-207.dialup.adsl.anteldata.net.uy> has joined #sugar-meeting | |
14:31 | tch___ | hiho |
14:31 | m_anish | :-) |
14:31 | garycmartin | #startmeeting |
14:31 | meeting_ | Meeting started Mon Jul 23 14:31:15 2012 UTC. The chair is garycmartin. Information about MeetBot at http://wiki.debian.org/MeetBot. |
14:31 | Useful Commands: #action #agreed #help #info #idea #link #topic #endmeeting | |
14:31 | pflores | hiQ |
14:31 | hi! | |
14:31 | quidam | hi |
14:31 | caspar | hi |
14:31 | garycmartin | Hi all, can we have a show of hands :) |
14:31 | ajay | raises his hand |
14:31 | JT4sugar | Hi |
14:32 | garycmartin | So todays agenda is here: |
14:32 | #link http://wiki.sugarlabs.org/go/Design_Team/Meetings | |
14:32 | silbe | waves |
14:33 | garycmartin | Lets dive right in with an item we didn't get to last Wednesday. |
14:33 | m_anish | garycmartin, thx for the wiki page! |
14:33 | garycmartin | #topic Journal multi-select |
14:33 | gonzalo_ | is reading, hello all .... |
14:33 | garycmartin | #link http://wiki.sugarlabs.org/go/F[…]ction_screenshots |
14:33 | gonzalo_: Hi. | |
14:33 | #link http://lists.sugarlabs.org/arc[…]-July/038558.html | |
14:34 | m_anish | btw, if anyone wants to try these features in a build, you should be able to find images on http://build.activitycentral.com/ |
14:35 | garycmartin, so points of discussion are (1) should entries in source view remain selected after the operation has completed? (2) should there be alerts for de-selecting entries? | |
14:36 | garycmartin | I think both danielf and aguz could not make this Monday meeting time, and had feedback about the feature (so this 14:30 Monday start is still not a good choice for a regular meeting) |
14:36 | silbe | FWIW, if you're feeling adventurous and/or don't have an XO at hand, there are even images for use inside a VM (x86). |
14:36 | garycmartin | m_anish: Thanks, yes I have been experimenting a little with it in dx3ng143 |
14:36 | m_anish | garycmartin, i think i would be okay with changing around the time, but ideally would like these meetings on mon or tue |
14:37 | silbe | m_anish: source view? |
14:37 | m_anish | silbe, except for the jumpy mouse and small font, those VM images mostly work |
14:38 | tch___ | m_anish: regarding (1) what was the reason to deselect them in the first place? :) |
14:38 | garycmartin | m_anish: FWIW I've encountered several bugs using dx3ng143 on an XO-1 |
14:38 | m_anish | silbe, ah. okay so source view here means that ... suppose you want to copy many entries from journal to a USB stick... so you select journal entries (i.e. the source) and use the copy-to operation to batch-copy them to the USB stick... after the operation is complete the entries in the journal view (i.e. the source) would get deselected |
14:39 | tch___, i don't think its a particularly bad design | |
14:39 | ajay | tch___: well, main reason was to avoid de-select of the destination entries.. de-selection of source-entries happened as a result :) |
14:39 | m_anish | garycmartin, that could be possible, these images were build just last week without proper testing. i hope the bugs were more activities related. there are well-tested builds available too (but for the XO-1.5 only for now i think) |
14:40 | ajay | garycmartin: great !!!! could we have a quick listing? (will be great to have a bug-free feature) :) |
14:40 | silbe | m_anish: ok, makes sense, thanks. |
14:40 | garycmartin | m_anish: No bugs were with Journal multiselect. |
14:40 | m_anish | garycmartin, you mean in multi-select? |
14:40 | quidam | garycmartin: I make those images, so please ping me with any problem you find in them :) |
14:41 | m_anish | garycmartin, one bug that is known is that the checkbox select action doesnt become visible until the mouse hovers away from the entry |
14:41 | garycmartin | So quickly. 1) clicking the checkboxes is rather slow (can be a second or so even with just 6 items in the Journal) |
14:42 | silbe | m_anish: FWIW, personally I'd prefer the entries to stay selected, so you can check what entries you just copied (we should show that information on the Action View, but that's a separate topic). Also, if there's just copy and no move, you could copy and then remove the same set of entries. |
14:42 | ajay | garycmartin: using "select all"? |
14:42 | tch___ | ajay, m_anish: I would vote for leaving the source items selected also. It can save time for users when they try to do many operations to the same set of items. |
14:42 | silbe | (any further discussion should probably happen on sugar-devel I guess) |
14:43 | m_anish | #link http://build.laptop.org.au/xo/os/RC-8/ fwiw OLPC-AU dx3 based build for XO-1.5 laptop |
14:43 | garycmartin | 2) Clicking the checkboxes is unreliable. It seems almost like a mouse move event is needed. If you click and don't move the mouse cursor nothing happens. If you then think you didn't click correctly and click again you can end up deselecting the tick anyway (and nothing obviously happens). |
14:43 | ajay | garycmartin: that's a known bug (as pointed by m_anish). |
14:43 | m_anish | garycmartin, re: (2) that's exactly the known issue i pointed above, so you're right in that |
14:44 | garycmartin, before, it used to be _much_ slower !! live several seconds for say 10 entries. so we came a long way on that | |
14:45 | garycmartin, perhaps if we removed the alert, if could be faster | |
14:45 | garycmartin, but we don't want the user to not have any feedback if he is selecting, say a 100 entries | |
14:45 | garycmartin | 3) Once you have a selection active you can not favourite star or un-favourite star an entry, however once you clear the selection and stars you had been clicking catch up and change state. Very confusing, especially if you have a filter active. |
14:45 | \ | |
14:46 | m_anish | s/live several seconds/like several seconds/ |
14:46 | garycmartin, (3) i wasn't aware of. | |
14:47 | ajay | garycmartin, me too.... it could probably be happening because listview refresh is inhibited in batch mode. |
14:48 | garycmartin: so i guess we should inhibit changing the "favorite" status altogether while in batch-mode? | |
14:48 | m_anish | garycmartin, see my coments on your bug (1) above. i think it could be made faster, but it might be bad UI-wise if there were many journal entries. |
14:48 | garycmartin | m_anish: I was going for the use case where a user may want to quickly copy their favourite items over to a USB stick, and wants to remove some stars while they are selecting items to copy. |
14:49 | m_anish | garycmartin, that's what bug (3) is abt... so i guess it will have to be fixed anyway |
14:50 | tch___ has quit IRC | |
14:50 | garycmartin | OK, so back to design ;) |
14:50 | m_anish | garycmartin, did you identify UI changes that need to be made otherwise (apart from the bugs). |
14:50 | :-) | |
14:51 | wish walterbender was here too, as he played a part in getting the design ready | |
14:51 | garycmartin | m_anish: I got tangled up in these bugs trying to see how well the UI worked. So right now I'm not ready to make a judgement. |
14:52 | tch___ <tch___!~tch![]() |
|
14:52 | m_anish | garycmartin, hmm, so how do we proceed next on this? fwiw, i dont think (1) is a bug |
14:52 | tch___ | back~ just got kicked. |
14:53 | silbe | m_anish: I'd consider it a bug (it's _way_ too slow), but nothing we need to block on on the design side. It's an implementation issue. |
14:53 | satellitSNFact has quit IRC | |
14:54 | garycmartin | m_anish: So (1) is made worse by (2). If you get (2) fixed things may feel better. Right now just making a simple selection from a Journal with 6 items on an XO-1 is frustrating (for me). |
14:54 | m_anish | garycmartin, okay |
14:55 | ajay | garycmartin: ok.. will have a look into (2) |
14:55 | silbe | m_anish: if it turns out we can't do much better for this release cycle (which I don't hope), the Design Team will have to decide whether it's acceptable to ship regardless, though. |
14:55 | m_anish | garycmartin, ah there was another issue raised on the m-l thread. somebody didn't want checkboxes right next to the stars |
14:55 | garycmartin | silbe: Correct. |
14:56 | m_anish: Yes that was danielf and I think aguz's feedback. | |
14:56 | m_anish | silbe, fwiw, i think (2) and (3) need to be fixed. but much more cant be done re: (1) (its already a lot better than before)... and if we remove the alert, it think it would be counterproductive UI wise |
14:56 | garycmartin, I don't think its an issue having them side-by-side ... as gmail does it (but open to discussion ;) ) | |
14:57 | garycmartin | Note that GMail (folks keep saying the current design is based on Gmail's interface), puts the stars over to the far right (at least on their android GMail client) |
14:57 | silbe | m_anish: we should talk later (outside the meeting) about why it's so slow. |
14:57 | m_anish | silbe, ok |
14:58 | garycmartin, yes, but would it not be a regression (significant change) over existing UI? | |
14:58 | garycmartin | m_anish: Do we need an alert for the deselect all option? This is really like the 'I'm done' button. Actually that's exactly how GMail does it, a "Done" button that deselects any selections. |
14:59 | m_anish | garycmartin, but i can see it being worthwhile to move the star right, considering sugar might get used on a touch device someday |
14:59 | ajay | garycmartin: on gmail.. we have a paginated view .. unlike the journal where we may have 1000s of entries ... so again .. the UI feedback becomes kinda necessary |
15:00 | garycmartin | m_anish: I was just raising the point from danielf, yes it would be a significant change for existing users to move the star widgets over to the far right and raises the question of where the Detail widget would go. |
15:02 | gonzalo_ | garycmartin, gmail in the browser have the start and the checkbox at the left (but probably is not designed for touch) |
15:02 | garycmartin | ajay: paginated view, That's not so for their android client, it's a continuous scrolling window. They have removed 'select all', 'deselect all' and just have a 'done' (which acts as a deselect all). |
15:03 | erikos <erikos!~erikos![]() |
|
15:03 | m_anish | garycmartin, i can see why that makes sense (both the done button and star at the right). |
15:04 | ajay | garycmartin: okk .. and the deselection happens fairly quickly for 1000s of entries ? (sorry, just asking.. /me doesn't have an android phone, yet :P ) |
15:04 | garycmartin | gonzalo_: yes, that's a likely design change for touch (moving the small buttons apart). |
15:05 | m_anish | ajay, perhaps we can test how fast it is without the alert on the slowest available hardware (i,e XO-1) |
15:05 | and then make a call | |
15:05 | garycmartin, ajay gonzalo_ makes sense? | |
15:05 | ^^ | |
15:05 | ajay | m_anish: +1 |
15:05 | gonzalo_ | garycmartin, can we put the checkbox at the right instead of moving the stars? |
15:05 | garycmartin | ajay: well they don't have a 'select all' so they limit how many you can sanely select at once ;) |
15:06 | m_anish | garycmartin, in the gmail browser-view they do ;) |
15:06 | ajay | garycmartin: ahhh.. there we are... so we need to take a call for both the select-all and deselect-all in unison :) |
15:07 | m_anish | garycmartin, so the action items emerging here are ... |
15:07 | Fix the problem of selection not visible until mouse hovers | |
15:08 | Check speed after removing alert for both select and deselect operations | |
15:08 | Decide on where checkbox and star need to be placed? | |
15:08 | first two are for me and ajay, the last for discussion here (and you) :-) | |
15:08 | garycmartin, anything else? | |
15:09 | Ariel_Calzada has quit IRC | |
15:09 | garycmartin | m_anish: Fix changing favourite stars while in multi-select mode. |
15:09 | m_anish | garycmartin, +1 |
15:10 | garycmartin, would you be comfortable with installing an rpm with these changes (would save time over installing a whole build) | |
15:10 | :-) | |
15:10 | pflores | garycmartin m_anish as this feature is already being used in UY, AU and PY, I would think twice before making big UI changes (re: moving the star) |
15:10 | tch___ | m_anish: leave the items selected ;) (?) |
15:10 | garycmartin | I also need to test this some more with a larger number of journal entries, I only flashed this XO-1 last night so only have a handfull of entries to experiment with. |
15:11 | m_anish | m_anish, think we already agreed on that (to leave them selected)? |
15:11 | garycmartin | tch___: +1 |
15:11 | silbe | garycmartin: you could try "importing" entries from another XO using the Backup and Restore activities |
15:12 | tch___ | silbe: that was one of the original motivation for it ;) |
15:12 | m_anish | pflores, +1, but we need to discuss it in light of sugar being used on touch h/w where it becomes imp. |
15:12 | garycmartin | silbe: I'll just use multi-select from a USB key full of files ;) |
15:12 | tch___ | silbe: not very efficient, but at least more "natural" |
15:12 | pflores | m_anish +1 |
15:13 | silbe | heh, ok. :) |
15:13 | m_anish | fwiw, it's still light-years faster than copying each journal entry individually :P |
15:13 | Ariel_Calzada <Ariel_Calzada!~aricalso![]() |
|
15:13 | ajay | m_anish: lol :D |
15:13 | tch___ | m_anish: cannot disagree on that haha |
15:14 | garycmartin | #action Fix the problem of selection not visible until mouse hovers (ajay, m_anish) |
15:14 | #action Fix the problem of selection not visible until mouse hovers (ajay, m_anish) | |
15:14 | #action Fix changing favourite stars while in multi-select mode (ajay, m_anish) | |
15:15 | So is there agreement on "leave the items selected after a batch operation"? | |
15:16 | ajay | garycmartin: either ways would be fine i guess ... |
15:16 | garycmartin | #action test this some more with a larger number of journal entries (garycmartin) |
15:16 | Cerlyn | In terms of deselecting while copying, I could see this feature being used to copy starting files from a teacher's machine to several USB sticks for students. Hence my personal view they should stay selected. |
15:16 | ajay | Cerlyn: agree. |
15:16 | garycmartin | Cerlyn: +1 |
15:17 | m_anish | garycmartin, Cerlyn so an alternate to current workslow would be (1) Replace the deselect button with the "Done" button (2) Keep the entries selected |
15:17 | s/workslow/workflow | |
15:17 | ajay | m_anish: +1 |
15:18 | garycmartin | m_anish: Yes, you you keep the select all feature in that case? |
15:18 | m_anish | garycmartin, yes, i think that is useful |
15:18 | Cerlyn | m_anish: You still need a "deselect all" when the teacher has finished copying and doesn't need the list anymore |
15:19 | tch___ | Cerlyn: +1 |
15:19 | m_anish | garycmartin, for example a teacher wants to install many XO bundles on the XO... she inserts a pendrive with the bundles, selects all and copies to the journal... |
15:19 | ajay | Cerlyn: I think "Done" is just a rename of "Deselect All". Functionality wise, they would be same, would they? |
15:19 | m_anish | ajay, +1 |
15:19 | tch___ | ajay: ahh, ok, clarifies for me too |
15:20 | Cerlyn | What do Sugar HIG guidelines say? "Done" implies there is only one possible workflow |
15:22 | silbe | ajay: if you always show the selection checkboxes then it would be equivalent. If we have a "select mode" where we show the select check boxes, Done would also end that mode. |
15:22 | garycmartin | On the alert side I'm finding it quite interuptive, just about every operation has an alert before, and some alert after. |
15:23 | m_anish | silbe, the checkboxes always remain visible |
15:23 | (i think they should) | |
15:23 | ajay | silbe: hmm yep. so, needs a design-confirmation :) |
15:23 | m_anish | garycmartin, we should definitely do away with the 'deselect' alerts |
15:23 | garycmartin | m_anish: +1 |
15:24 | #action do away with the 'deselect' alerts | |
15:24 | m_anish | garycmartin, not so sure about 'select' maybe we need to check how fast it is |
15:24 | garycmartin, for alerts while deleting and copying, they are perhaps needed? | |
15:24 | tch___ | m_anish: garycmartin: for deleting for sure. |
15:25 | silbe | +1 on an alert for deletion as its irreversible |
15:25 | garycmartin | m_anish: how about the select all only raises an alert if there are greater than N items to be selected (Are you sure you want to select 247 entries?) |
15:25 | ajay | garycmartin: N ? |
15:26 | m_anish | garycmartin, hmm, makes sense. |
15:26 | tch___ | The only scenario where the alert-for-copying makes sense if there is no "cancel" option.. otherwise it could be the only way to prevent big time losses |
15:27 | garycmartin | m_anish: Alerts confirming Erase "Do you want to erase N entries? are critical. So we must keep them. The question for erase is that second alert/progress type feedback. |
15:27 | ajay | garycmartin, m_anish: yes...... distinction between confirmation-alert and progress-alert need to be clearly stated. |
15:28 | garycmartin | ajay: N == some number we decide is many, 25, 50, 100? |
15:28 | tch___ | garycmartin, m_anish: what is the point for alerting while selecting all? |
15:28 | ajay | tch___: confirmation-alert OR progress-alert? :P |
15:29 | garycmartin | tch___: I'm assuming the justification is that is is slow? ajay ? |
15:29 | tch___ | ajay: as I read sounds like a confirmation before the selection is being done |
15:29 | garycmartin: ahh | |
15:29 | so if the speed of selection can be fixed it won't be necessary right? | |
15:30 | garycmartin | tch___: I'm seeing some tick appearing with just 5 journal entries, need to test with 50-100. |
15:30 | m_anish | garycmartin, okay we have {confirmation_before, progress, confirmation_after} ... deselecting {N, N, N} ... selecting {Y?, N?, N?} ... deleting {Y, ?, ?} ... copying {Y, ?, ?} |
15:30 | ajay | garycmartin, tch___: well.. it needs to be decided .. that whether we want a little extra speed, or a seamlesss, non-anxious UI experience. :) |
15:30 | m_anish | currently we have {Y,Y,Y} for all |
15:30 | ajay | m_anish: awesome ... nice schema ... !!!! |
15:30 | garycmartin | tch___: Yep I'd say so |
15:31 | tch___ | ajay: are they mutual excluding requirements? |
15:31 | garycmartin | #action review {confirmation_before, progress, confirmation_after} ... deselecting {N, N, N} ... selecting {Y?, N?, N?} ... deleting {Y, ?, ?} ... copying {Y, ?, ?} for next meeting (garycmartin) |
15:32 | ajay | tch___: no .. they are dependent .. for a full feedback of the progress.. speed will have to be compromised (a little bit). |
15:33 | tch___ | ajay: of course, but does the selecting process require feedback of that progress? |
15:33 | m_anish | garycmartin, should we move to the next topic? we have lots of action items already ;-) |
15:34 | tch___ | ajay: for copying I assumes it makes sense, but just selecting.. |
15:34 | garycmartin | OK so I think we need work on this topic item some more and come back to it via the mail thread and the next meeting. |
15:34 | tch___ | kk |
15:34 | m_anish | garycmartin, +1 |
15:34 | ajay | tch___: in case of 1000s of entries, when things will anyways take time, ... probably yes. |
15:34 | m_anish: +1 | |
15:34 | garycmartin | #topic Touch hardware support |
15:34 | ajay | garycmartin: +1. in the meantime, m_anish and me will work on the bugs |
15:35 | garycmartin | ajay: Thanks! |
15:35 | #link http://wiki.sugarlabs.org/go/D[…]ivity_Touch_Input | |
15:35 | m_anish | garycmartin, can we discuss the 'lease expiration' proposal, it should be quick? i think people mostly agreed on the thread that its needed |
15:35 | garycmartin | #link http://wiki.sugarlabs.org/go/D[…]Shell_Touch_Input |
15:35 | m_anish | okay |
15:35 | garycmartin | #link http://wiki.sugarlabs.org/go/D[…]n-screen_Keyboard |
15:36 | m_anish: 'lease expiration' proposal is further down the agenda. First in first out ;) | |
15:36 | m_anish | garycmartin, +1 |
15:37 | garycmartin | OK, so I don't expect you to read all those tiuch links now ;) |
15:37 | But they are the growing set of work that is going on to make Sugar touch ready. | |
15:38 | m_anish | ok |
15:38 | garycmartin | I want to make sure this area is visible in the Design Meetings so that we are all aware of this direction (if it wasn't an obvious movement already). |
15:39 | m_anish | fwiw, we had an on-screen keyboard in dx but its only in spanish and not the best. ... worth exploring all the links in the page you referenced |
15:39 | silbe | garycmartin: I wouldn't have called it obvious until now, FWIW. Thanks for bringing it up during the Design Team meeting. |
15:40 | (and thanks for working on it!) | |
15:40 | m_anish | garycmartin, if you have a dx build handy, you can bring it up by going to the accessibility section in CP (just in case you wanted to try) |
15:40 | garycmartin | m_anish: Yes I've used the DX on-screen keyboard, it's not really practical for a touch device and not too well integrated into the Sugar experience. |
15:41 | m_anish | garycmartin, +1 on those observations :-) |
15:41 | tch___ | have anyone tried the gnome's 3 virtual keyboard? |
15:42 | m_anish | garycmartin, we should consider things like which project is actively maintained and is in a good state upstreamwise for choosing it to implement in sugar |
15:42 | garycmartin | tch___: Yes, and it was rejected. |
15:43 | m_anish | quidam, ^^ (think you'll be interested in this discussion) |
15:43 | garycmartin | tch___: relies on hardware acceleration (clutter) amongst other (I'd need to look back at my review notes) |
15:43 | tch___ | garycmartin: Ah, ok. Maybe later I can catch up on the reasons. |
15:44 | garycmartin: good, can you share those notes? :) | |
15:44 | silbe | m_anish: do we even need to do anything in Sugar that depends on a specific OSK software? After all it should work outside of Sugar, too. |
15:44 | garycmartin | The plan is to raise mail threads for the various topics as we start to make real design decisions. One that needed to start early was the move towards using the Maliit OSK, work is pretty far along on internal testing, we have had developers doing paid work on it's integration so far. |
15:45 | m_anish | silbe, hmm, IMHO, i think just on the area about how well it integrates with sugar UI wise (and doesn't stick out, like the WLAN password entry box does) |
15:45 | dirakx has quit IRC | |
15:46 | silbe | m_anish: ok, good point. But even that should just require some additional support for the specific OSK, nothing that would lock us in. |
15:46 | dirakx <dirakx!~rafael![]() |
|
15:47 | m_anish | silbe, right, i think that was the biggest concern i had when it came to sugar-integration. perhaps it can be done in an OSK-s/w-agnostic fashion. I'm not sure. |
15:48 | garycmartin | silbe: Sugar need to support various items reliably for OSK to be properly integrated into the system, but yes if a 3rd party OSK fits those hooks then they could take advantage of them as well. However there si need to focus on a solution, get it designed correctly, integrated for Sugar, packaged and tested. We need a solid well tested solution here to be a success. |
15:53 | silbe | garycmartin: my point is that if the OSK works well enough with most software (and it will need to if it's going to be used on a general purpose system), then there shouldn't be much need to do anything that would only work with a specific implementation. So there's no need for Sugar maintainers to do a detailed analysis of what solution will have the best chance of surviving long-term. We can just take whatever downstream favours today and |
15:53 | easily switch to different software later. | |
15:53 | garycmartin | So touch has quite a large chunk of my design time (supported via OLPC, so we can be future proofed and ready for touch based hardware). I'll try to kick of mail-threads when the work starts to bump into Sugar design issues, but the feedback review on Activity design is an example of the kinds of changing already ongoing http://wiki.sugarlabs.org/go/D[…]ivity_Touch_Input |
15:54 | m_anish | garycmartin, in the Requirements section, should we also add "haptic feedback"... the little vibration giving feedback to the user that something was pressed. Might be useful for touch devices that support it in h.w? |
15:55 | garycmartin | silbe: sure. Maliit was selected partly because it has been well tested on other platforms in many languages, is actively maintained and has developers willing to make it work well elsewhere. |
15:58 | m_anish: haptic feedback, I believe that is patent encumbered, but might be worth adding it as 'would like to have' Interestingly even sound feedback is quite a challenge as the audio latency is very sensitive if it is to work as feedback, haptic feedback would be a similar challenge ;) | |
15:59 | m_anish | garycmartin, ok :) |
15:59 | garycmartin | OK, moving on to next topic? |
15:59 | m_anish | yep |
15:59 | garycmartin | (Touch is going to come back quite frequently in the future ;) ) |
16:00 | #topic Speech engine technology | |
16:00 | #link http://lists.sugarlabs.org/arc[…]-July/038570.html | |
16:00 | So Chris (cjl) wanted to raise our choice of speech engine as a design question to look at. | |
16:01 | cjl: beep | |
16:01 | Cerlyn | Can we be like Orca (the JAWS of the Linux world) and use a engine-independant backend? |
16:02 | garycmartin | Any one here have experience with other speech engines on XO type hardware? |
16:02 | m_anish | nope :/ |
16:02 | silbe | FWIW, we're already 1:30 in the meeting. Not sure how long we want to go on today. |
16:02 | tch___ | garycmartin: examples for activities ;) |
16:02 | hehehe | |
16:03 | garycmartin | Cerlyn: I think we already do with espeak, I think gonzalo_ mentioned originally it was designed so it could work with festival as well, though not sure those hooks are still there. |
16:03 | gonzalo_ | garycmartin, we can use gnome-speech to have a better backend abstraction |
16:03 | garycmartin | silbe: Good point! I'm forgetting that 30min offset start time ;) |
16:04 | gonzalo_ | garycmartin, but we need test again what is his actual state |
16:05 | silbe | garycmartin: Sugar is currently hardcoded to use gst-espeak (which isn't available on most distros other than Fedora). Not sure if there's something like gst-festival that we could easily use alternatively. |
16:05 | Cerlyn | Orca on Fedora uses speech-dispatcher{-python}, which is a TTS independant backend https://live.gnome.org/Orca/SpeechDispatcher |
16:06 | garycmartin | gonzalo_: gnome-speech thanks, perhaps this can be investigated at some point? I guess the goals are to have better language support and improved voice quality? |
16:07 | gonzalo_ | garycmartin, yes, should be investigated... anybody with time in his pockets |
16:07 | ? :) | |
16:07 | but yes, i agree with the goals | |
16:07 | garycmartin | OK, so let's hold off on this one for now, not a critical path for us as we have a working espeak (most of the time) ;) |
16:08 | m_anish | gonzalo_, my pocket has a big hole, time keeps slipping through it :-) |
16:08 | garycmartin | #action wiki page for gathering TTS engine options (garycmartin, cjl) |
16:08 | silbe | m_anish: +1 I'm afraid :-/ |
16:09 | gonzalo_ | m_anish, may be we bought the pants in the same place ! :) |
16:09 | m_anish | lol |
16:09 | silbe | garycmartin, cjl: thanks for taking care of this! |
16:09 | m_anish | silbe, +1 |
16:10 | gonzalo_ | garycmartin, a lot of reserch can be done without programming, gnome-speech have test utilities |
16:10 | silbe | gonzalo_: looks more like a global conspiracy to me, unless both of you happened to go shopping in Germany :) |
16:10 | gonzalo_ | garycmartin, and the voices can be installed and tried in the differnt xos |
16:10 | garycmartin | If sjl and I gather some concrete notes on some options at least that will get the ball rolling a little, it should be obvious if there is a big win to be had with another technology. I quite like espeak to be honest, but we could do with tweaking the voices a little more (no reason not to have make and female voices ) |
16:10 | ) | |
16:10 | gonzalo_ | silbe, hmmm :) |
16:11 | garycmartin | #topic Meeting wrap up |
16:11 | OK so time is well past! | |
16:12 | We lost two contributors with this 14:30UTC Monday start time :( | |
16:12 | silbe | garycmartin: FWIW, even if something's too compute intensive on modern XOs, upstream Sugar would still be interested in engines with better output ("voices"). We can make it switchable at run-time. |
16:13 | m_anish | silbe, +1 its a worthwhile thing to explore IMO, but not a high-pri one i think. |
16:13 | garycmartin | I'll look into later times for next week, Monday or Tuesday. |
16:13 | silbe | m_anish: exactly |
16:14 | m_anish | garycmartin, +1 just let us know atleast 2-3 days before the meeting, otw, we should hold it at the same time as today |
16:15 | silbe | garycmartin: anything starting 20UTC or before would work for me |
16:15 | tch___ | m_anish: +1 |
16:15 | garycmartin | The agenda items we missed this week will roll over as usual onto the next meeting, please also do continue relevant threads on the mail-list, and start a new threads if you have new agenda items. |
16:15 | m_anish: 2-3days before, yes will do! | |
16:15 | cjl | waves after showing up late |
16:15 | m_anish | garycmartin, thx |
16:16 | silbe | garycmartin: BTW, thanks for organising the meetings! |
16:16 | garycmartin | cjl: I volunteered you to help me make a wiki page with possible TTS engines options to explore ;-) |
16:17 | OK time for the count down! | |
16:17 | 7... | |
16:17 | m_anish | 6 |
16:17 | silbe | 5 |
16:17 | cjl | 4 |
16:17 | tch___ | 3 |
16:17 | ajay | 2 |
16:17 | caspar | 1 |
16:18 | garycmartin | #endmeeting |
16:18 | meeting_ | Meeting ended Mon Jul 23 16:18:07 2012 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot. (v 0.1.4) |
16:18 | Minutes: http://meeting.sugarlabs.org/s[…]-23T14:31:15.html | |
16:18 | Log: http://meeting.sugarlabs.org/s[…]12-07-23T14:31:15 | |
16:18 | garycmartin | Thanks all! |
16:18 | m_anish | yay |
16:18 | :) | |
16:18 | silbe | hmm, we missed Cerlyn and pflores I think... |
16:18 | garycmartin | I'll email out the minutes. |
16:18 | cjl | garycmartin: Sure on the wiki, I don't know the answers, I just think it is a question we need to explore carefully. |
16:19 | garycmartin | silbe: I'll bump up my count down again next week :) |
16:20 | cjl: +1 we just need to pull some research together so we have a place to begin exploring. | |
16:20 | pflores | silbe I was here, but asynchronously :) |
16:20 | silbe | garycmartin: maybe we should have a bot command for that? The bot would count the number of participants (i.e. those who said something during the meeting) and start the countdown there. quidam? ;) |
16:21 | m_anish | silbe, think he has his hands full :-P |
16:22 | cjl | garycmartin: I couldn't imagine this changing in less than two release cycles, but we need to start doing the groundwork now. |
16:22 | garycmartin | silbe: ;) |
16:22 | silbe | m_anish: too bad :) |
16:23 | garycmartin | cjl: true but we could move to try and be more engine agnostic so different back ends could be used. |
16:23 | cjl | garycmartin: maybe we can drag Cerlyn into a little research for the wiki page :-) |
16:23 | garycmartin | cjl: a Sugar API would help avoid all the copy and pasting that is currently going on in Activities. |
16:24 | (copy and pasting of code) | |
16:24 | cjl | garycmartin: yes, it is the fact that it touches so many plaecs that it needs forethought |
16:24 | silbe | garycmartin: being agnostic to the speech backend is certainly a good idea and should be a goal for including speech support in sugar-toolkit. |
16:25 | garycmartin | silbe: Yes I think that makes sense as well. |
16:25 | cjl | We have de facto gst-espeak "lock in" at the moment, let's not go to far without considering such issues. |
16:26 | is obviuosly lookin gat this from a "voice" L10n perspective | |
16:26 | Cerlyn | cjl: Personally I would prefer if we could defer all the usablity TTS (things not like Clock telling the time) to Orca like we are moving the touch keypad to maliit |
16:26 | But the Orca user experience in Sugar right now is poor (I've tried it) | |
16:27 | or at least flakey and varies by app | |
16:27 | jvonau has quit IRC | |
16:27 | cjl | Cerlyn I'd value having that perspective on the wiki page (when we start it). |
16:28 | silbe | if there needs to be code for that in sugar-toolkit at all - if the API provided by gnome-speech or speech dispatcher is good enough, we can just let people use that directly |
16:28 | cjl | I really want a decision made on a speech technology tha taddresses a11y and L10n. A11y is in some ways jsut another form of L10n. |
16:29 | dogi has quit IRC | |
16:29 | Cerlyn | Orca is looking for AT-SPI hints but we don't do a good job of that; a lot of buttons are not discovered, it thinks radio buttons are "1 of 1", and sees a lot of things as just "text" and "frame" because no labels or titles are associated with the entry field/window/etc. |
16:31 | Somehow the braile monitor also doesn't end up "always on top" even when that is selected as well | |
16:35 | silbe | Cerlyn: yeah, I'm currently working on that because we need it for automated UI tests, too. |
16:35 | The lack of titles that is | |
16:39 | Cerlyn | In general Orca spots the menu items in a pallete but not its title and other information (such as for the currently connected AP, etc.) |
16:41 | silbe | Cerlyn: are you trying with mainline Sugar or erikos' de-hippoized branch (can dig out the link if you don't have it yet)? |
16:42 | Cerlyn | silbe: Just mainline sugar; at some point I will be looking at GTK 3 ported activities, hopefully soon |
16:43 | dogi <dogi!~dogi![]() |
|
16:43 | cjl | just happy the conversation is happening and has faith in our community process to achieve a good result. |
16:59 | caspar has left #sugar-meeting | |
17:11 | JT4sugar has quit IRC | |
17:13 | erikos has quit IRC | |
18:37 | jvonau <jvonau!~jvonau@S010600508b0f7a4e.wp.shawcable.net> has joined #sugar-meeting | |
18:38 | igod <igod!~omen![]() |
|
19:13 | garycmartin has quit IRC | |
19:37 | Ariel_Calzada has quit IRC | |
20:14 | satellit_ <satellit_!~satellit![]() |
|
20:17 | Ariel_Calzada <Ariel_Calzada!~aricalso![]() |
|
20:21 | JT4sugar <JT4sugar!~JT![]() |
|
20:24 | daroal has quit IRC | |
20:41 | garycmartin <garycmartin!~garycmart![]() |
|
20:45 | JT4sugar has quit IRC | |
20:48 | tch___ has quit IRC | |
21:10 | satellit has quit IRC | |
21:13 | dirakx has quit IRC | |
21:21 | erikos <erikos!~erikos![]() |
|
21:29 | tch___ <tch___!~tch![]() |
|
21:34 | tch___ has quit IRC | |
22:01 | erikos has left #sugar-meeting | |
22:05 | silbe is now known as silbe`away | |
22:25 | Ariel_Calzada has quit IRC | |
22:35 | gonzalo_ has quit IRC | |
22:39 | Ariel_Calzada <Ariel_Calzada!~aricalso![]() |
|
22:40 | Ariel_Calzada has quit IRC | |
22:42 | gonzalo_ <gonzalo_!~gonzalo![]() |
|
22:52 | gonzalo_ has quit IRC | |
23:13 | Ariel_Calzada <Ariel_Calzada!~aricalso![]() |
|
23:34 | pflores has quit IRC | |
23:43 | garycmartin has quit IRC | |
23:46 | pflores <pflores!~pflores@r186-48-45-251.dialup.adsl.anteldata.net.uy> has joined #sugar-meeting |
« Previous day | Index | Today | Next day » Channels | Search | Join