| === hikiko is now known as hikiko|off | ||
| duflu | abi-check says we removed a function from MIR_CLIENT_DETAIL_9 ... that's OK right? | 07:50 |
|---|---|---|
| duflu | alan_g ^ | 07:53 |
| alan_g | duflu: yes(ish) | 07:54 |
| RAOF | I would also say yes. | 07:55 |
| duflu | It's an ABI but not as public | 07:55 |
| alan_g | It won't break clients, the things it would break are distributed at the same time | 07:55 |
| duflu | Indeed | 07:55 |
| duflu | Just looks bad for our tooling as even after I fixed some minor problems 'make abi-check' fails due to it | 07:56 |
| duflu | So you can't tell if other failures lurk after it | 07:56 |
| * alan_g would like to reorg the code - but that would break ABIs | 07:56 | |
| * RAOF is happy to break any ABI that isn't the client ABI. | 07:58 | |
| alan_g | MirAL brings a new hope of a stable server-side ABI (but that includes getting mircommon stable) | 07:59 |
| duflu | I would like to say it's too late in the week to think about that but I am presently looking at it | 07:59 |
| RAOF | Re-exporting symbols is a thing, right? | 07:59 |
| RAOF | Hm. | 08:00 |
| alan_g | Hmm that is a thought | 08:00 |
| duflu | RAOF: Definitely, in theory. Just need to know how with our tools | 08:00 |
| RAOF | Actually, *why* can't we just include mircommon statically into mirclient? | 08:01 |
| duflu | Because it's a waste of space. Also the break already happened anyway | 08:01 |
| RAOF | I mean, we could *remove* libmircommon as a thing. | 08:01 |
| alan_g | Because it is used by platform modules, the mirserver and mircommon | 08:01 |
| RAOF | It's a trivial waste of space, and it simplifies our lives. | 08:01 |
| alan_g | ODR rule | 08:02 |
| duflu | RAOF: That solves the symbol version problems sure. But not header changes... ODR | 08:02 |
| RAOF | alan_g: The ODR rule doesn't apply here, though? | 08:02 |
| alan_g | Why not? | 08:02 |
| duflu | Common sense by some other name then. Database normalization (?! | 08:02 |
| duflu | ) | 08:02 |
| RAOF | Because there are no C++ objects in the interface between mirclient and mirserver/mirplatforms? | 08:03 |
| duflu | libmirprotobuf is C++ but a different lib | 08:04 |
| RAOF | I mean, it's not an ODR violation if glib internally has a class called mir::Dispatchable but it's not exported in the symbol table and never appears in the interfaces. | 08:04 |
| duflu | Don't worry about it. We all know a fix is possible at the binary level. Just need to work out the high level syntax | 08:04 |
| RAOF | (If that *is* an ODR violation then that's another area where C++ is insane) | 08:04 |
| RAOF | (This might require getting rid of mirclientdetail, which exists, from memory, purely for the benefit of acceptance tests?) | 08:05 |
| alan_g | I think also for the debug extension rubbish | 08:05 |
| RAOF | Yeah, I'm happy to fold that in. | 08:06 |
| RAOF | We'll have an *actual* extension mechanism *someday*. | 08:06 |
| alan_g | One day we'll work out exactly what we need in what libraries and declare version 1 | 08:06 |
| duflu | I actually wanted to look at a version "25" but that idea fell flat when I realized mirserver is already higher :( | 08:07 |
| duflu | How did we get here? | 08:07 |
| alan_g | good intentions | 08:07 |
| alan_g | Good session for the sprint? | 08:08 |
| duflu | alan_g: Sounds like a session we've had (multiple times?) before | 08:10 |
| duflu | Not sure I want to go through that again | 08:10 |
| RAOF | This seems like a different session? | 08:10 |
| RAOF | “How can we make it so that mirclient (a) exports no C++ symbols and (b) is standalone”? | 08:11 |
| RAOF | I don't think we've asked that before. | 08:11 |
| duflu | I thought we kind of had tests for it? | 08:11 |
| duflu | Or similar... | 08:11 |
| alan_g | And (c) how do we make a stable server ABI? | 08:11 |
| duflu | Making sure it doesn't re-export mircommon | 08:11 |
| alan_g | The stuff MirAL actually uses from mircommon actually should be stable | 08:12 |
| duflu | You can use anyone else's API/ABIs in your headers if they are version < 3. Otherwise (if they are ours) then maybe not | 08:12 |
| alan_g | To make 3rd-party platforms viable they need a stable ABI from mircommon | 08:13 |
| alan_g | To make 3rd-party server viable they need a stable ABI from mircommon + miral | 08:13 |
| duflu | We break libmirplatform often too | 08:13 |
| alan_g | Yep, all part of the big question | 08:13 |
| duflu | BTW, I just logged some relevant bugs | 08:14 |
| alan_g | I think we're now at a point where it is feasible, and getting important enough | 08:14 |
| RAOF | An alternative: we ask legal to get the appropriate verbiage to make it clear that loadable platform modules *aren't* covered by the GPL, and then not expect them to link to mircommon. | 08:14 |
| alan_g | mircommon provides stuff like "Rectangles" that we should be able to make stable | 08:15 |
| RAOF | Absolutely. | 08:15 |
| RAOF | Which is why having modules expect the server to supply those symbols is perfectly sensible :) | 08:15 |
| RAOF | Actually, if mirclient stops linking with mircommon then we lose the pressure for mircommon to be the things common to client and server. | 08:16 |
| duflu | BTW I've tried some experiments intentionally breaking things. Turns out a full wildcard * does not break existing symbols, but a partial one like ReadableFd does. | 08:16 |
| RAOF | Which would make stripping out all the bits which *aren't* super-stable easier. | 08:17 |
| duflu | I would also like to build one libmir* of everything with all symbols for testing, and then strip the private bits. No more object libs | 08:17 |
| alan_g | I don't see a problem with linking to mircommon + mirplatform - we "just" need to ensure they only publish stable stuff. | 08:17 |
| RAOF | Yeah, that's right. | 08:18 |
| duflu | Remind me why mirplatform exists? | 08:18 |
| RAOF | One of the current problems is that mircommon is that stable stuff, *plus* the bits shared between server and client that we actively change. | 08:18 |
| alan_g | To define the interface between server and platform | 08:19 |
| alan_g | (in an LGPL library) | 08:19 |
| duflu | alan_g: Remember we have the graphics and input ABIs which are different to mirplatform | 08:19 |
| alan_g | Follows from long discussions with legal | 08:19 |
| duflu | Oh. Too lawyerish for a Friday | 08:20 |
| RAOF | Yeah; again, an alternative would be an explicit grant of “no, your modules don't need to be GPL” | 08:20 |
| alan_g | Yeah, we'll not solve it here | 08:20 |
| alan_g | One of the current problems is that mircommon is that stable stuff, *plus* the bits shared between server and client *and platform* that we actively change. | 08:21 |
| RAOF | And one of the problems there is that I fully expect us to change the *platform ABI* reasonably frequently. | 08:23 |
| duflu | Another reason why I would prefer our namespaces followed the library names... so you could also find #include "mir/common/*" | 08:23 |
| RAOF | (For example: I don't think there's *ever* been an Xorg release that didn't change the graphics ABI) | 08:23 |
| alan_g | I think we now have enough platforms to shake out the right abstractions | 08:23 |
| duflu | RAOF: Xorg has the benefit of less frequent releases | 08:23 |
| duflu | Slightly | 08:24 |
| RAOF | duflu: Yes. I absolutely don't expect us to be bumping our platform ABI every release. But once a year seems perfectly plausible. | 08:24 |
| RAOF | Now, our platforms are doing an easier job for us than Xorg's platforms, but still. | 08:24 |
| duflu | RAOF: A separate stable trunk to save up those breaks? | 08:24 |
| RAOF | Support >1 ABI. | 08:25 |
| duflu | Or that | 08:25 |
| RAOF | We've got it all set up so that we can (reasonably easily) do that! | 08:25 |
| * RAOF EOD. For the moment. | 08:25 | |
| duflu | Or dinner | 08:25 |
| === chihchun_afk is now known as chihchun | ||
| duflu | alan_g: A bug that exists in mir_proving_server can't be MirAL can it? | 08:39 |
| duflu | Or can it | 08:39 |
| alan_g | They could have the same bug | 08:39 |
| alan_g | But MirAL code isn't in proving_server | 08:40 |
| duflu | Indeed | 08:41 |
| duflu | So bug invalid for MirAL | 08:42 |
| === chihchun is now known as chihchun_afk | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| alf_ | Saviq: greyback: Hi! How do apps tell unity8/qtmir that they want to keep the display on? Is it done through QT? | 13:05 |
| greyback | alf_: not through Qt itself, I think people use the dbus api that powerd offers to keep the display on | 13:22 |
| alf_ | greyback: ok, how is losing focus handled? | 13:23 |
| greyback | alf_: I *think* we trust the application to be good | 13:23 |
| greyback | I'd need to look into it | 13:23 |
| greyback | going off old memories here | 13:23 |
| alf_ | greyback: thanks, this came up again because I am working on the snap interface for keeping the screen on, and wasn't sure if things had changed. | 13:25 |
| greyback | no changes afaik | 13:26 |
| alf_ | greyback: Ideally, as discussed in the past such requests should be sent to Unity8, and then unity8 can decide what to do depending on form factor, focus etc | 13:27 |
| greyback | alf_: correct | 13:27 |
| greyback | but nothing has happened on that front | 13:27 |
| alf_ | greyback: yeah, I will update the snap iface to work with what's currently in place and we can revisit the topic (perhaps in the sprint) | 13:28 |
| === JanC is now known as Guest73904 | ||
| === JanC_ is now known as JanC | ||
| alan_g | bschaefer: as my pointer confinement guru - could you check the miral integration? https://code.launchpad.net/~alan-griffiths/miral/confine_pointer/+merge/306635 | 14:51 |
| bschaefer | alan_g, yes! | 14:52 |
| bschaefer | looks nice | 14:53 |
| bschaefer | the only thing /me trying to remember if you'll need to specifically do something on a window creation spec for confinement | 14:54 |
| bschaefer | alan_g, also how come you have to do the #if? | 14:54 |
| alan_g | miral presents the same API/ABI on xenial as on yakkety | 14:55 |
| alan_g | But xenial is on Mir-0.22 | 14:55 |
| bschaefer | o dang /me hopes it wont become an #if nightmere :| | 14:55 |
| bschaefer | nightmare* | 14:55 |
| bschaefer | alan_g, without actually testing it looks good to me (have you tried out the example?) | 14:56 |
| * alan_g is only supporting LTS, Yakkety, and lp:mir | 14:56 | |
| alan_g | bschaefer: not yet | 14:57 |
| * alan_g remembers not knowing what the example should do | 14:57 | |
| bschaefer | alan_g, i can re-compile and test it out after the standup | 14:57 |
| bschaefer | alan_g, i made a mir demo :) (mir_demo_client_pointer_confinement) | 14:57 |
| alan_g | I remember not knowing what to expect from that | 14:58 |
| === dandrader is now known as dandrader|afk | ||
| bschaefer | alan_g, o .. right well you should be able to move the red square for ever when pointer confinement is on | 14:59 |
| bschaefer | when its off your cursor will go our of the screen boundary | 14:59 |
| alan_g | I need something more recent that 0.24 don't I? | 15:01 |
| bschaefer | alan_g, yeah there are some changes in 0.25 that fixed some pointer confinement issues | 15:03 |
| bschaefer | mainly with WM stuff | 15:03 |
| bschaefer | moving/resizing etf | 15:03 |
| bschaefer | etc* | 15:03 |
| alan_g | I mean for the demo | 15:04 |
| bschaefer | alan_g, hmm i thought the demo was in 0.24 but i only have trunk mir branch /me checks | 15:04 |
| alan_g | bschaefer: could you try it then - miral builds much faster | 15:05 |
| bschaefer | alan_g, yeah i must have been compiling a chunk of mir not miral when i mention it the other day (took less then a min for miral) | 15:06 |
| bschaefer | http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/examples/pointer_confinement.c | 15:06 |
| bschaefer | alan_g, but yeah ill test after standup | 15:06 |
| === dandrader|afk is now known as dandrader | ||
| alan_g | bschaefer: well, it seems to do something | 15:43 |
| bschaefer | alan_g, haha thats good (was answering an OSK) | 15:43 |
| bschaefer | alan_g, theres hot keys to disable pointer confinement | 15:43 |
| bschaefer | p i think | 15:43 |
| alan_g | Yes, I had to read the code. and "F" to toggle fullscreen (What happened to F11?) | 15:44 |
| bschaefer | alan_g, umm me breaking the standard :) | 15:44 |
| alan_g | Yes, you ignore "close the window" too | 15:45 |
| alan_g | ;) | 15:45 |
| bschaefer | haha | 15:46 |
| bschaefer | i thought i put q back in | 15:46 |
| bschaefer | or tried to filter those events through... | 15:46 |
| bschaefer | (do the underlying handle event) | 15:46 |
| * bschaefer compiling now | 15:47 | |
| bschaefer | alan_g, umm invalid free / next | 15:48 |
| * bschaefer checks things | 15:48 | |
| bschaefer | huh using 0.24 but i tihnk i compiled against 0.25 for some reason | 15:49 |
| alan_g | I mean mir_event_type_close_surface | 15:50 |
| bschaefer | alan_g, o ... that would have been something to use | 15:50 |
| alan_g | It's only an example, but... | 15:50 |
| bschaefer | yeah i like examples to be just as good as our code | 15:51 |
| bschaefer | (mainly people look at examples to write their code) | 15:51 |
| bschaefer_ | that was strange.. | 15:54 |
| alan_g | ldconfig? | 15:55 |
| * bschaefer_ doesnt understand joke | 15:56 | |
| bschaefer_ | alan_g, i hit that mirshell session next thing | 15:56 |
| bschaefer_ | (possibly) where input didnt work but went to a tty to attempt to step through it and once i hit the tty hot keys my machine just stopped | 15:57 |
| alan_g | bschaefer_: that's an evil bug. | 15:58 |
| bschaefer_ | yeah... im trying to get you more info | 15:58 |
| bschaefer_ | alan_g, i seem to hit it only using the x11 platform | 15:58 |
| alan_g | then possibly one for camako | 15:59 |
| bschaefer_ | possibly just need more info before i can really poke anyone :( | 15:59 |
| bschaefer_ | a way to reproduce would be nice :) | 15:59 |
| alan_g | yes, might mir-trunk related - which I don't use be default | 16:00 |
| === bschaefer_ is now known as bschaefer | ||
| bschaefer | alan_g, very true i use trunk mir | 16:00 |
| bschaefer | could be an ABI issue as well? | 16:00 |
| bschaefer | no | 16:00 |
| bschaefer | that would cause a crash... | 16:00 |
| alan_g | *probably* | 16:00 |
| bschaefer | i suppose if it ... somehow ABI match the bytes to a different function... | 16:00 |
| bschaefer | haha that would be funny... | 16:01 |
| === dandrader is now known as dandrader|afk | ||
| anpok_ | i think thats because the x11 platform tries to grab the keyboard? | 16:18 |
| alan_g | probably need to ssh in from another computer | 16:20 |
| bschaefer | alan_g, i was lucky to get into a tty for that current backtrace we have... but it froze this last time | 16:22 |
| bschaefer | anpok_, could be, the strange thing all mouse events work fine | 16:22 |
| bschaefer | (it just almost feels like the mir shell keeps grabbing focus ... ie keyboard grab?) | 16:23 |
| alan_g | bschaefer: http://voices.canonical.com/alan.griffiths/2016/09/23/debugging-mir-servertoolkit-interactions/ | 16:56 |
| bschaefer | alan_g, sweet thanks i will be using this! | 16:57 |
| bschaefer | for more debugging info for reports | 16:57 |
| * bschaefer will be sure to include logs for reports as well | 16:58 | |
| alan_g | :) | 16:58 |
| === dandrader|afk is now known as dandrader | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!