| === pete-woods1 is now known as pete-woods | ||
| mterry | tsdgeos, I made a thing you'll like: https://code.launchpad.net/~mterry/unity8/test-greeter-dbus-fixes/+merge/292677 | 08:05 |
|---|---|---|
| tsdgeos | :) | 08:06 |
| tsdgeos | mterry: why the > 0? is this something that would get fixed in future branches? | 08:09 |
| mterry | tsdgeos, that's because there are two PropertiesChanged signals sent out -- for two separate properties. And the previous code was racy if both came in before spy.wait() finished | 08:10 |
| mterry | tsdgeos, so I think >0 is fine as is, even in future | 08:10 |
| tsdgeos | mterry: if there's two of them, should be > 1 ? | 08:10 |
| mterry | tsdgeos, we only care about the first one -- we know the order they come in, and the test is only interested in the first | 08:11 |
| tsdgeos | ok | 08:11 |
| mterry | tsdgeos, good points though -- that check does *look* flaky :) | 08:11 |
| tsdgeos | mterry: so shall i approve it or you'll have another look? | 08:13 |
| mterry | tsdgeos, no I was just saying they were good questions. I'm +1 for code as is. I think there are comments already in that function that explain what's going on | 08:13 |
| tsdgeos | ok :) | 08:13 |
| Mirv | I give silo 19 "Timo's seal of approval" on my frieza that Bq shipped to me on Friday | 09:27 |
| Saviq | +1 | 09:28 |
| === vrruiz_ is now known as rvr | ||
| cimi | tsdgeos hey albert, any reason why we didnt add qml tests for the expandable filter? https://code.launchpad.net/~aacid/unity8/expandable_filter/+merge/288957 | 10:02 |
| tsdgeos | cimi: hmmm | 10:30 |
| tsdgeos | cimi: i guess i forgot :D | 10:31 |
| tsdgeos | cimi: can you comment asking for it in the MR? | 10:31 |
| cimi | tsdgeos I asked a need information | 10:32 |
| tsdgeos | oki | 10:32 |
| davmor2 | Saviq: I wouldn't pay too much attention to that though we fail Mirv silos all the time ;) | 10:44 |
| Mirv | haha | 10:57 |
| === alan_g is now known as alan_g|lunch | ||
| tsdgeos | cimi: added the test | 12:27 |
| === alan_g|lunch is now known as alan_g | ||
| dandrader | tsdgeos, no apps scope when I run unity8-dash in my laptop. any idea why? | 13:34 |
| tsdgeos | dandrader: not installed? | 13:34 |
| tsdgeos | unity-scope-click | 13:34 |
| dandrader | tsdgeos, right. installing now. do you know which package brings this one in? | 13:35 |
| dandrader | tsdgeos, wow, unity8-dash loads it on the fly | 13:35 |
| tsdgeos | dandrader: ubuntu-touch is the dependency that brings it in | 13:35 |
| === dandrader is now known as dandrader|afk | ||
| === willcooke is now known as wllck | ||
| === dandrader|afk is now known as dandrader | ||
| ChrisTownsend | Hey all! If I pair a keyboard with say an N4 or Frieza, how does it figure out what keyboard is being used. I know if you explicitly set the hardware keyboard in System Settings->Language & Text->External Keyboad->Layouts and other sources", then it is saved in org.freedesktop.Accounts.User$UID.InputSources property. But if I just pair it and not set it in there, that property is blank. | 14:33 |
| ChrisTownsend | Does U8 assume it's a US(?) keyboard and the user has to go in there to set it to their particular keyboard layout? Or is there some sort of probing to figure out the keyboard layout when pairing? | 14:36 |
| ChrisTownsend | Saviq: Any ideas? ^^^^ | 14:44 |
| Saviq | ChrisTownsend, no probing possible | 14:52 |
| Saviq | ChrisTownsend, we'll default to the default one for the language | 14:52 |
| Saviq | or have it in OOBE for desktops | 14:52 |
| ChrisTownsend | Saviq: Ok. Background is that I need to set the same keyboard for X apps, so the best approach would be if InputSources is blank, then use the language that is set. But if InputSources is set, then use the first one that is set. | 14:53 |
| Saviq | ltinkl, comment ↑? | 14:54 |
| ChrisTownsend | Saviq: In The Future, I will plan on dynamic keyboard selection for X apps, but this will have to due for now. | 14:54 |
| Saviq | ChrisTownsend, define dynamic? you mean applied on the fly? | 14:55 |
| ChrisTownsend | Saviq: Yes, on the fly. Like if someone changes the keyboard layout in System Settings, that can also be applied to any running X apps. But that is much more complicated, so that will be done the line. | 14:56 |
| ChrisTownsend | Saviq: So I would need some sort of something to catch the change property signal and see if it changed...or somethin'. | 14:56 |
| ChrisTownsend | Saviq: But right now, X apps are US keyboard only and that is bad. | 14:56 |
| ChrisTownsend | Saviq: So if I can at least set the current layout when an X app launches, that will satisfy most use cases. | 14:57 |
| * ltinkl reads the backlog | 15:04 | |
| ltinkl | ChrisTownsend, so what's known is the user's preferred keymap but you can't currently ask U8 which is the current one | 15:07 |
| ltinkl | ChrisTownsend, so that's something I could expose to you to fix this | 15:07 |
| ltinkl | if the user hasn't configured any keymaps, I don't think we should get too smart and try to guess from the language (which is also technically wrong, some keymaps don't match the language code) | 15:09 |
| ChrisTownsend | ltinkl: Well, that would certainly be a good thing. It looks like System Settings queries org.freedesktop.Accounts.User$UID.InputSources property for the selected maps. | 15:09 |
| ltinkl | ChrisTownsend, yes, we do the same in u8 (that's our common "storage") | 15:09 |
| ltinkl | ChrisTownsend, but the current keymap is only known to u8 atm | 15:10 |
| ChrisTownsend | ltinkl: Ok, then it's easy enough for me to query that too. But my question is, if I just pair a keyboard, that property is blank, so how is the keymap determined in that case. | 15:10 |
| ChrisTownsend | ltinkl: Oh, ok, if U8 only knows, then having some way to query U8 would probably be best. | 15:11 |
| Saviq | ChrisTownsend, ltinkl, I think when changing language, we should set the default keymap, too (at least if it's empty?) | 15:11 |
| ChrisTownsend | ltinkl: Would it be some Dbus interface you would expose? | 15:11 |
| Saviq | please no | 15:12 |
| Saviq | ChrisTownsend, can't you access accountsservice? | 15:12 |
| ChrisTownsend | Saviq: Via DBus? | 15:14 |
| ChrisTownsend | Saviq: I guess I'm asking if it provides a dbus service. | 15:14 |
| Saviq | ChrisTownsend, AS does | 15:15 |
| Saviq | ChrisTownsend, org.freedesktop.Accounts | 15:15 |
| Saviq | it's a property there | 15:15 |
| ChrisTownsend | Saviq: Yes, actually I do that in the code I'm developing now. It's the InputSources property, right? | 15:15 |
| Saviq | ChrisTownsend, yes, that's the "official" API | 15:16 |
| ChrisTownsend | Saviq: Ok, sure. Well, my question goes back to this: InputSources is blank when pairing a keyboard, so how is the keyboard layout chosen in that case? | 15:17 |
| Saviq | ChrisTownsend, today we assume US | 15:17 |
| Saviq | so you should do the same IMO | 15:18 |
| ChrisTownsend | Saviq: lol, ok. Then it's the responsibility of the user to set it correctly after pairing. | 15:18 |
| Saviq | ltinkl, would you say that we should fill InputSources when changing language or should we default to the default language keyboard based on the current language? | 15:18 |
| ChrisTownsend | Saviq: Sure, I can assume that too. Well, currently, I always assume that:) | 15:19 |
| Saviq | ChrisTownsend, not necessarily ↑ | 15:19 |
| Saviq | ChrisTownsend, but doing that you'd be on par with unity8 ;) | 15:19 |
| === dandrader is now known as dandrader|lunch | ||
| ltinkl | Saviq, not sure... we could certainly do this in the Wizard, to set the default HW keymaps (as we do wirth OSK) | 15:24 |
| ltinkl | Saviq, still I need to expose the current keymap somewhere, InputSources in AS/DBUS isn't what Chris needs | 15:25 |
| Saviq | ltinkl, oh you mean when we're switching it | 15:26 |
| ltinkl | Saviq, exactly | 15:26 |
| Saviq | ltinkl, can't he take it from the surface? | 15:26 |
| ltinkl | Saviq, ah right, but onky MirSurface (from qtmir) has it, the getter is missing in Mir itself :/ | 15:27 |
| ltinkl | Saviq, the correct way imho would be for Mir to provide the getter (besides the setter it has), then anyone can read it | 15:28 |
| Saviq | ltinkl, think it's on purpose clients don't know? | 15:29 |
| ltinkl | Saviq, hmm in theory, Mir has a surface observer so you at least get a signal when the keymap gets changed, that might be a way too | 15:29 |
| ltinkl | ChrisTownsend, ^^ | 15:29 |
| ChrisTownsend | ltinkl: Hmm, maybe Xmir would be the one that should handle keyboard mapping since it's the thing that interfaces with Mir. | 15:31 |
| Saviq | ChrisTownsend, totally | 15:31 |
| ltinkl | yeah, you could listen to the keymap_changed signal from Mir observer | 15:32 |
| ltinkl | and propagate it into the container | 15:32 |
| ChrisTownsend | ltinkl: Yeah, ok, I guess I need to talk to duflu(?) about how to implement something in Xmir to do something like that. | 15:33 |
| ltinkl | ChrisTownsend, yup | 15:33 |
| ChrisTownsend | ltinkl: Saviq: Thanks guys! | 15:33 |
| ltinkl | ChrisTownsend, duflu or anpok | 15:33 |
| anpok | hm? | 15:33 |
| anpok | keyboard mapping? | 15:34 |
| anpok | not keymapping? | 15:34 |
| Saviq | anpok, keyboard layout | 15:35 |
| ChrisTownsend | Right, layout | 15:35 |
| anpok | do you need to know which layout? | 15:35 |
| anpok | or is it enough to know that it changed? /me hasnt read the scrollback yet. | 15:36 |
| ChrisTownsend | anpok: Well ,however we accomplish it, we need to set the correct layout in the libertine container for X apps that matches the currnt layout in U8. | 15:36 |
| anpok | ah ok.. we could forward the keymap itself | 15:36 |
| ChrisTownsend | anpok: Ideally, we would want "xkb:de" set in X for the container if U8 is using "de". | 15:37 |
| Saviq | anpok, I just wonder if there's a reason not to tell the client? | 15:37 |
| ChrisTownsend | anpok: So one idea is that Xmir could get the layout from Mir and set it appropriately for that X session. And could even possible listen for signal when it changes in U8 and change it for the running X instance. | 15:38 |
| anpok | there is none.. we just dont provide the xkb settings to the client.. just the keymap itself.. | 15:39 |
| ChrisTownsend | anpok: Hmm, so it's not possible with the way Mir is currently implemented? | 15:50 |
| anpok | no. we just have to eihter also send the credentials used to assemble the keymap or forward the keymap that we received from the server.. | 15:52 |
| ChrisTownsend | anpok: Ok, looks like that is a dead end. Saviq, ltinkl^^^^ | 15:53 |
| anpok | the latter xmir could already do .. the former ... needs a mir change | 15:53 |
| ChrisTownsend | anpok: After reading your last statement, so there is a way to do it via forwarding the keymap received from the server to Xmir? | 15:56 |
| anpok | yes | 15:56 |
| ChrisTownsend | anpok: So Xmir would just need to be modified to do that, right? | 15:57 |
| anpok | i assume so yes | 15:57 |
| ChrisTownsend | anpok: Ok, thanks | 15:57 |
| ChrisTownsend | Saviq: So just to confirm, I set the language to German and the keyboard layout stays US. So currently, it seems that the user has to explicitly set the keyboard layout they want, which is kind of what I expected, but wanted to chack. | 16:15 |
| === dandrader|lunch is now known as dandrader | ||
| === alan_g is now known as alan_g|EOD | ||
| === Tk is now known as Guest44387 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!