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