Web   ·   Wiki   ·   Activities   ·   Blog   ·   Lists   ·   Chat   ·   Meeting   ·   Bugs   ·   Git   ·   Translate   ·   Archive   ·   People   ·   Donate

#sugar-meeting meeting, 2012-07-23 14:31:15

Minutes | Index | Today     Channels | Search | Join

All times shown according to UTC.

Time Nick Message
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@96.Red-88-7-71.staticIP.rima-tde.net> has joined #sugar-meeting
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@> has joined #sugar-meeting
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@> has joined #sugar-meeting
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@> has joined #sugar-meeting
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

Minutes | Index | Today     Channels | Search | Join

Powered by ilbot/Modified.