[07:14] <robert_ancell> mlankhorst, hey
[09:16] <duflu> alan_g: I find myself potentially having to route logic through the frontend shell code. Although I can skip it for now if any of libmirserver will change again...?
[09:17] <duflu> I don't want to base it on classes that might change
[09:17] <duflu> It's functional without touching shell already. But in future should use shell.
[09:19] <alan_g> I expect some functions to get added to frontend::Shell to support sizing, morphing etc. But that's not my immediate agenda.
[09:19] <duflu> alan_g: Yeah, just about done :)
[09:19] <duflu> But the proof of concept is renaming, which doesn't need WM policy (yet)
[09:20] <alan_g> Surely there should be a policy about names. ;)
[09:21] <duflu> alan_g: Doubt it. Never seen a shell that modified what an app set...
[09:23] <alan_g> *something* needs to decide what to do if the name is stupidly long and won't fit in the decoration. I don't see that being the compositor
[09:24] <duflu> alan_g: Actually it is. That affects rendering and fade out etc. And even if it doesn't fit, the task switcher and panel etc still know the full name
[09:27] <alan_g> OK, (at least for now) it isn't as though we can't refine the logic later.
[09:28] <duflu> alan_g: Well all other spec morphs will need intervention of the shell. But I'm intentionally keeping that out of stage one
[09:29] <anpok> in the old days figuring out where to place letters was a compositors job.. but compositor is no longer a synonym to typesetter
[09:29] <anpok> at least in the world of display servers..
[09:30] <duflu> anpok: Also we don't draw lines... "Shell" includes compositor, WM, whatever you want.
[09:31] <duflu> Which makes sense... until you realize how mammoth a job it is to build all that. We need to make it a bit easier.
[09:31] <duflu> With reusable bits
[09:36] <anpok> yes it is easy to avoid conflicts or disagreement by just making general statements. I would conclude with the shell author should not have to replace or override the compositor to get a different title or decoration.. your example above just shows that the surfaces arent the right place to make layouting or display related changes to the text. The original problem seems that we havent established that o
[09:36] <anpok> ther place yet..
[09:37] <anpok> oh that message got long
[09:37] <anpok> bleh ModuleDeleter is no silver bullet I still have to take care of well defined ownerhsip
[09:46]  * alan_g resists quoting Brooks
[09:47] <anpok> :)
[09:54] <duflu> Each window has a "title" string. I haven't asserted anything beyond that other than suggesting it should be UTF-8
[09:54]  * duflu is confused, but also doesn't care as it's just about EOD
[10:06]  * duflu goes to cook weird-looking mushrooms
[11:38] <mpt> Would Mir’s security mechanism require command-line utilities where you choose a window, like xprop, xwininfo, or xkill, to be given special privileges?
[12:40] <alan_g> alf_: your tools/update_package_abis.sh just saved me from pushing a broken change. Thanks!
[12:42] <alf_> alan_g: good to hear!
[14:16] <anpok> alf_: alan_g: AlbertA: interested in reviewing https://code.launchpad.net/~andreas-pokorny/mir/dispatchable-action-queue-and-fixes/+merge/252451?
[14:17] <alf_> anpok: sure, will take a look in a bit
[14:22] <alan_g> anpok: ok
[14:24] <greyback> alan_g: hey, I noticed in mir::Scene:Surface, the methods configure & query are marked to be removed. And instead to read/write an attribute on a Surface, you need to go through AbstractShell. Isn't that a bit roundabout?
[14:28] <alan_g> greyback: it is more that the attribute implementation doesn't fit well with the MVC design that we were trying to stick to. The model (scene) should only contain stuff that is on interest across the system, the shell is the main consumer of attributes and they ought to be supported there.
[14:29] <alan_g> Certainly only the shell should be updating the model, not "anything that can view objects in the model".
[14:34] <greyback> alan_g: okay. It doesn't quite gel with me (cuz in my mind, the SurfaceStack is the model, Surfaces are entries in the model), but I'll acquiesce to your better judgment
[14:40] <alan_g> Essentially the model shouldn't be responsible for holding all information about surfaces that any part of the system might want. Only the information that is shared across the system. (If you think about the canonical MVC view as a widget, the model doesn't need to know the typeface)
[14:43] <greyback> fair, ok
[14:50] <alan_g> anpok: I may be missing something: is there an advantage to using an Fd over a condition variable?
[14:52] <anpok> well apart from the fact that you can use the fd in a more neutral way with regard to the threading model ...
[14:52] <anpok> the Dispatchers that execute Dispatchables need fds
[17:20] <nikwen> Hi!
[17:20] <kdub> hello nikwen
[17:20] <nikwen> I have a question regarding Mir and Slimport devices.
[17:20] <nikwen> I've installed the latest version of Mir from trunk on my vivid Nexus 4 and connected my Slimport adapter.
[17:21] <nikwen> When I connect the phone to a screen, I only see a black screen.
[17:21] <nikwen> However, the syslog shows that the device detects my monitor (I've tried with multiple ones) and the devices recognize that there is some input.
[17:21] <nikwen> The display that there's a 1920x1080 (60 Hz) source attached, but yet the screen is black.
[17:22] <kdub> well, id make sure that everythings powered down and up with the slimport attached, mine's a bit flaky sometimes
[17:22] <nikwen> Do I need any other piece of software? How can I verify it's not an issue with the hardware?
[17:23] <nikwen> Btw, I've tried with two (sadly poor-quality) HDMI cables and three monitors.
[17:23] <kdub> and, the mir demos should work, but unity8 needs some work to get going
[17:24] <kdub> and maybe the display-report or compositor-report or hwc-report (from mir's --help option) can give some clues as to what mir is doing
[17:24] <nikwen> Ah, that might be the issue. Do I need to install a special version of Unity8? If so, which branch should I install?
[17:28] <kdub> nikwen, I'd just advise tinkering with the demos at the moment, and waiting for that stuff to trickle out, /me has lost track of which branches need to go together
[17:30] <nikwen> kdub, ok, thanks. I'll check whether I can get the demos working. :)
[17:30] <kdub> no problem
[17:31] <nikwen> I'll definitely report back if it works. ;)
[18:13] <anpok> oh terry pratchett died
[18:33] <nikwen> Hi, it's me again.
[18:34] <nikwen> kdub, Mir is working with my Slimport. :)
[18:34] <nikwen> Now I'll just have to find and compile the proper branch of Unity8. :)
[18:34] <kdub> nikwen, great!
[18:35] <nikwen> kdub, big thanks for your help. I thought my Slimport might be broken but I'm glad it was software-related.