[09:57] <ShR3K> Hi ! What is the name of the view which display running apps after right edge swipe gesture ?
[10:02] <tsdgeos> ShR3K: Spread
[10:04] <tsdgeos> cimi: can you do https://code.launchpad.net/~aacid/unity8/stabilize_test_all_widgets_height/+merge/294377 ?
[10:04] <ShR3K> tsdgeos : Thanks
[10:04] <cimi> tsdgeos, sure
[11:04] <tsdgeos> Saviq: since the silos triple build now, should we adapt the CI?
[11:18] <Saviq> tsdgeos, right, yes, we should
[11:18] <Saviq> but that will mean a lot of red right now ;)
[11:19] <Saviq> still, doing
[11:19] <tsdgeos> oka
[12:32] <tsdgeos> Saviq: i'm going to unassign me and you to https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1535798 so it closes in 60 days since noone seems to care about retesting/giving a case in which it fails
[12:33] <tsdgeos> actually just unassigning me aws enough
[12:33] <tsdgeos> cool
[13:24] <zzarr> hello!
[13:25] <zzarr> is there a way to change what sound output libertine uses? (it's not the same as Mir/Unity8)
[13:27] <Saviq> bregma, any idea ↑?
[13:28] <cimi> tsdgeos, https://unity8-jenkins.ubuntu.com/job/test-0-autopkgtest/label=amd64,release=vivid+overlay,testname=qmluitests.sh/808/ ?
[13:28] <tsdgeos> cimi: yeah flaky test
[13:28] <tsdgeos> can't be related
[13:28] <tsdgeos> didn't touch the spread at all
[13:29] <cimi> sorry wrong copy paste :)
[13:30] <cimi> tsdgeos, btw can we make it more stable with your new branch to stabilise tests?
[13:30] <davmor2> tsdgeos: that looks like my bug I'll check for you after but I thought I had provided people with tracks already
[13:30] <tsdgeos> cimi: no idea, haven't looked at it
[13:30] <tsdgeos> davmor2: maybe it's fixed in one of the 150 branches we have yet to land
[13:31] <mterry> Saviq, happy Monday!  :)  So silo 58, is it still blocked on an uninstallability issue?
[13:31] <Saviq> mterry, yeah, we're getting there, though
[13:31] <mterry> k
[14:26] <ShR3K> How can I make package for armhf from my desktop environment ? I'd like to test on my Aquaris M10
[14:28] <Saviq> ShR3K, use the Ubuntu SDK, it will cross-build packages for you
[16:24] <mterry> Is the problem with cmake not finding compiler ABI info on yakkety known yet?
[16:24] <mterry> and/or am I hitting a unique-to-me issue maybe?
[16:26] <mterry> I must be, we compile on yakkety in buildd...
[16:27] <mterry> aha.  we don't play with ccache well apparently
[17:30] <bschaefer> greyback, hello, so to talk about maliit osk window resizing
[17:30] <bschaefer> err moving rather
[17:31] <bschaefer> now ... this will be a huge issue for gtk apps, but even when i tried a qt in app in xmir it didnt move the window (not sure how that informations gets sent to qt)
[17:31] <bschaefer> i assumes since its on X11 it never gets there from unity8 unless some sort of dbus stuff?
[17:31]  * bschaefer should have remember earlier and assumes you're off :)
[17:32] <greyback> bschaefer: I'm still around
[17:33] <greyback> bschaefer: there is a side-channel which communicates between shell and qtubuntu to tell it the OSK size
[17:33] <greyback> that doesn't existin xmir
[17:33] <bschaefer> o ok soo my guess is the qt apps on xmir doesnt use the qtubuntu platform
[17:33] <bschaefer> soo that'll be an issue
[17:33] <bschaefer> yeah
[17:33] <greyback> right
[17:33] <greyback> qtubuntu allows Qt apps run on Mir
[17:33] <bschaefer> nor can that be solved... sooo we'll need a separate handling method :(
[17:34] <greyback> well it /could/ - but that's a platform specific solution, and GTK won't be happy then
[17:34] <bschaefer> yup
[17:34] <bschaefer> which is a lot of the apps hmm
[17:34] <bschaefer> greyback, the only other way i've thought of is to manually resize the windows... or rather ask them to resize
[17:34] <bschaefer> if ... the other way doesnt work
[17:34] <bschaefer> but that seems harsh
[17:35] <greyback> bschaefer: have you talked to some GTK people? In case they're aware of a nice thing they cna do?
[17:35] <bschaefer> greyback, i have not!
[17:35]  * bschaefer adds that to the list to track down
[17:35] <bschaefer> would be nice if they did support something like that directly
[17:36] <greyback> bschaefer: because resizing a window isn't always guaranteed to work. Some windows have a minimum size
[17:36] <bschaefer> yup, hence why it would be a suggestion
[17:36] <bschaefer> and wont always work but if it would work anyway, not sure how it would have worked anyway :)
[17:36] <greyback> how about could te toolkit inform us of the geometry of the focused text box, then shell could move the surface to never occlude the text box?
[17:36] <bschaefer> err if it wouldnt have worked /me generates confusing sentences
[17:37] <bschaefer> greyback, well im hoping thats ... maliit would know this
[17:37] <bschaefer> but
[17:37] <bschaefer> dnag
[17:37] <bschaefer> i know the toolkit tells maliit where to draw
[17:37] <bschaefer> err
[17:37] <bschaefer> preedit lines at lease
[17:37] <bschaefer> for the text
[17:37]  * bschaefer double checks this
[17:39] <bschaefer> greyback, hmm actually dont think so but there *seems* to be a dbus interface to change to position of the maliit keyboard
[17:39] <greyback> bschaefer: also, has not an OSK been a thing people can enable for accessibility?
[17:39] <bschaefer> soo i might have to figure out... how to do this per input context
[17:39] <bschaefer> qt/gtk
[17:40] <bschaefer> greyback, err usually you can enable them?
[17:40] <bschaefer> for U7 you can at lease
[17:40] <greyback> bschaefer: caution that that is an X11 dbus thing
[17:40]  * bschaefer might have mis understood that question
[17:40] <greyback> be wary that Mir may not let maliit do what X11 did
[17:40] <bschaefer> greyback, o very true
[17:40] <bschaefer> ive not tested out this function and if it works on mir
[17:41] <greyback> bschaefer: well I know it can be enabled, but surely then it would have the same consequences that you're looking at now - and possibly some solutions
[17:41] <bschaefer> that would be a good first step since we slightly depend on it :)
[17:41] <bschaefer> greyback, well i would assume the desktop just doesnt do that sort of thing
[17:41] <bschaefer> but yeah i should
[17:41] <bschaefer> look into how the desktop handles it
[17:41] <greyback> bschaefer: plz have a look, just in case
[17:41] <bschaefer> o yeah
[17:41] <bschaefer> i need to
[17:41]  * bschaefer adds it to the list
[17:41] <greyback> odds are, there's nothing
[17:41] <greyback> but just in case
[17:42] <bschaefer> greyback, we could also ... set the osk as part of the ...
[17:42] <bschaefer> U8 interface
[17:42] <bschaefer> just like the panel?
[17:42] <bschaefer> that would be resizing though
[17:42] <bschaefer> (same idea i suppose)
[17:42] <greyback> bschaefer: I'd rather not. Later on there could be 3rd party keyboards
[17:42] <bschaefer> greyback, very true
[17:42] <bschaefer> greyback, cool you've given some things to dig around thanks!
[17:43] <greyback> bschaefer: we can let keyboard draw anywhere it wants on screen
[17:43] <bschaefer> yeah
[17:43] <greyback> I wonder what Windows10 does
[17:44] <bschaefer> i can take a look my brother has win10 on his desktop
[17:44] <bschaefer> greyback, i think ... win before has done
[17:44]  * bschaefer cant remember :)
[17:44] <greyback> bschaefer: would you please write up your research in a doc, so people can read and contribute?
[17:45] <bschaefer> greyback, yup! Quickly checking Win7
[17:45] <bschaefer> its just a normal window
[17:45] <bschaefer> if you move it over a text box
[17:45] <bschaefer> you just can draw on it
[17:45] <bschaefer> err see it*
[17:45] <greyback> so it occludes?
[17:45] <bschaefer> you cant see the text box* and it still allows it no
[17:45] <bschaefer> no
[17:45]  * bschaefer cant speak atm
[17:45] <bschaefer> greyback, its just a normal window always on top
[17:45] <greyback> ok, so it relies on user to reposition OSK surface to not occlude
[17:46] <bschaefer> yes, thats one thing that maliit needs
[17:46] <bschaefer> if you can move it around your self
[17:46] <bschaefer> then this solves that as well
[17:46] <greyback> bschaefer: I think windows7 is too old, win8 onwards has a very different OSK
[17:46] <greyback> I've got Win9/10 on a machine, I can try that at home
[17:47] <bschaefer> greyback, cool yeah i can try it as well i a bit
[17:47] <greyback> I think we can do better than "leave it to the user to fix it" :)
[17:47] <bschaefer> very true :)
[17:49] <greyback> bschaefer: the needs of a typical user OSK may differ significantly to the needs of an Accessibility keyboard - would be good to know if that the case or not
[17:49] <bschaefer> o very true i look through the options but didnt see any different placement options
[17:55]  * bschaefer wonders what would be the best solution really...
[17:56] <bschaefer> if the user moves an OSK over an input area...
[17:56] <bschaefer> thats just bad on them, but if it maps over one thats not good and *what* would ideally happen?
[17:56] <bschaefer> ideally, you can see the keyboard to click on, and you can clearly see the input area...
[17:56] <bschaefer> sooo something has to move
[17:57] <bschaefer> but what about something like gedit?
[17:57] <bschaefer> where the entire window is a input area :(
[18:24] <greyback> bschaefer: another thing I fear we'll be missing - how do you unfocus the text entry box?
[18:24] <bschaefer> greyback, im not sure how it currently works :)... i assume anytime you click away from it?
[18:24] <greyback> say you're editing a form, with a bunch of textboxes. When you tap one box, OSK slides up. But when you're done, what do you tap on to unfocus it?
[18:25] <bschaefer> hmm
[18:25] <greyback> bschaefer: user can't really unfocus, only move focus to something else
[18:25] <bschaefer> maybe a button on the osk?
[18:25] <bschaefer> you can slide the osk down
[18:25] <bschaefer> to hide it but theres no way to ... *unfocus* it
[18:25] <bschaefer> if a box is selected
[18:25] <greyback> and then,  do we know user tapped another text box to bring up osk again?
[18:25] <bschaefer> yeah thats how it currenlty works
[18:25] <bschaefer> annoyingly
[18:26] <bschaefer> as if you have the osk open
[18:26] <bschaefer> slide it down to hide
[18:26] <bschaefer> then click on a different input area
[18:26] <bschaefer> it comes back up
[18:26] <bschaefer> (actually IIRC clicking back on the same input area will cause it to re-open)
[18:27] <greyback> ok, so at least osk won't stay hidden if user wants to summon it
[18:27] <bschaefer> right, i havnt had that issue
[18:27] <greyback> android does have a hide-osk button on the osk
[18:27] <greyback> so we might need that too
[18:27] <bschaefer> yeah i agree
[18:27] <bschaefer> as sliding it down... makes sense but not always easy to figure out
[18:32] <dandrader|afk> fwiw, OSK on my android phone doesn't have a hide button
[18:33] <dandrader|afk> I have to press the phone's back soft-button
[18:34] <bschaefer> good to know maybe different android versions?
[18:34]  * bschaefer hasnt used android in a while
[19:20] <greyback> bschaefer: my nexus 10 OSK has software buttons , one of which is the hide-OSK button (one on the right I think)
[19:20] <greyback> maybe a hardware button does it for you
[19:21] <bschaefer> greyback, we dont have that luxury :)
[19:21] <bschaefer> though i dont remember seeing anything in maliit for that
[19:21]  * bschaefer isnt sure how hard that would be
[19:22]  * greyback eod
[19:22] <greyback> o/
[22:44] <bschaefer> attente, hey (if you're still around). How new is maliit inputcontext gtk3?
[22:45] <bschaefer> looking back at vivid + overlay it seems to just be an empty package?
[22:45] <bschaefer> in xenial it install im-modules.so
[22:45] <bschaefer> but the vivid one installs no libraries
[22:46] <bschaefer> looks ... pretty new from the google, you created the project in 2015-11-20... and first ppa was build jan 2016 hmm
[22:46] <bschaefer> soo that wont be in vivid :(