[10:08] <TheMuso> ev: You're the approver for https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-accessibility-ubiquity could you please have a look over, and if you think someone else should look at it, re-assign approval etc if need be? Thanks.
[10:08] <ev> will do
[10:14] <ev> TheMuso: two questions
[10:14] <ev> "[themuso] Write the backend code to set up brltty with the selected options from the new Braille setup dialog box: TODO" - where do you want to put this dialog box?
[10:15] <ev> "[maco] Check widgets in QT ubiquity UI, and enable them for accessibility if necessary: TODO" - does Qt finally support at-spi2?
[10:17] <TheMuso> ev: There will be work going on this cycle to get QT working with at-spi2.
[10:17] <ev> ah, okay
[10:17] <TheMuso> As for the first WI you mentioned, just how/where this dialog box will be shown is something I need to talk to you/design about, if I haven't covered that clearly in another WI then let me know and I'll try and clarify that.
[10:18] <ev> no, I think it's okay as-is. I just wanted to see if you already had some idea, but we can most certainly discuss it in detail when the time comes
[10:18] <ev> t
[10:18] <ev> ha
[10:18] <ev> nk
[10:18] <ev> s
[10:18] <ev> weird
[10:18] <TheMuso> np
[10:19] <ev> right, I'm going to guess whoever made me approver had a reason for doing so.  Approved.
[10:20] <TheMuso> Yeah Jason did, and thanks.
[12:45] <CIA-13> ubiquity: evand * r4726 trunk/ (7 files in 4 dirs):
[12:45] <CIA-13> ubiquity: Provide access to the keymaps most-relevant for the currently
[12:45] <CIA-13> ubiquity: selected language in the keyboard indicator (LP: #656777).
[16:19] <cjwatson> ev: one concern with hiding the boot menu is that the lack of ability to write to the GRUB environment block means that I don't think we can support "show the boot menu if we fail to boot" on Wubi at the moment
[16:19] <cjwatson> at least not without a certain amount of extra clevernes
[16:19] <cjwatson> s
[16:19] <ev> hmm
[16:20] <ev> surely there some unused bit we could prod in the MFT
[16:20] <cjwatson> this is because having the environment block in /boot/grub/grubenv means that in order to write to it we have to be able to write to the loopback disk, which deliberately doesn't implement writing in order to avoid the risk of ever corrupting the filesystem
[16:20] <ev> but I guess that falls under cleverness
[16:20] <cjwatson> writing to the MFT wowrries me a lot more than writing to a file
[16:20] <ev> fair enough
[16:20] <cjwatson> there probably is some way around it
[16:21] <cjwatson> just haven't thought of it yet, and it's worth flagging because I don't think this constraint is an obvious one
[16:21] <ev> should this become a workitem as well, just so the concern doesn't get lost?
[16:21] <ev> or are you happy with the existing one
[16:21] <cjwatson> the existing one will probably do for now, but I'll keep it in mind
[16:21] <ev> okay
[16:21] <cjwatson> it goes with the inability to write to the env block on btrfs, LVM, and/or RAID
[16:22] <ev> ah, so it's not just a wubi thing then
[16:22] <ev> nice
[16:22] <cjwatson> the btrfs case at least has a design
[16:22] <ev> right
[16:22] <cjwatson> right, it's basically anything where the underlying disk/fs is complicated
[16:22] <cjwatson> if it's straight writes to preallocated space on disk with no checksums, that's OK
[16:25] <ev> mm, indeed
[16:25] <cjwatson> the btrfs workaround will be to shove the environment block into the first 64K of the fs instead, which is reserved for boot loaders
[16:26] <cjwatson> though we'll have to deal with various hardcoded assumptions that the environment block is /boot/grub/grubenv