[12:37] alan_g: did you have any fixes for the system-compositor WM to deal with https://bugs.launchpad.net/canonical-pocket-desktop/+bug/1511538 [12:37] Launchpad bug 1511538 in qtmir (Ubuntu) "1/2 screen on external monitor" [High,Confirmed] [12:37] if so, would be nice to include with mir 0.17.1 release [12:39] greyback_: not yet. But looks similar to other nested display config problems I'm chasing down [12:40] alan_g: ok [12:58] greyback_: have you seen anything similar on phone? https://bugs.launchpad.net/mir/+bug/1511723 [12:58] Launchpad bug 1511723 in Mir "unplugging external monitor causes nested server to throttle client" [Undecided,New] [12:58] alan_g: I haven't actually. [12:59] alan_g: that's desktop only? [13:00] greyback_: that's what I've been testing - as most of the display management problems are platform independent === alan_g is now known as alan_g|lunch === dandrader is now known as dandrader|afk [13:41] alf: was that convincing enough? https://code.launchpad.net/~andreas-pokorny/mir/input-configuration-api/+merge/273975/comments/697135 === dandrader|afk is now known as dandrader [14:02] anpok: is a device configured either as touchpad or pointer? === alan_g|lunch is now known as alan_g [14:03] anpok: or => xor [14:07] alf_: no.. touchpads are both touchpads and pointers [14:07] mice are just pointers.. [14:13] anpok: I don't know... I still think that apply_touchpad_configuration() is a different operation to apply_pointer_configuration(), not just variations of the same operation. [14:15] anpok: Anyway, I won't block on that. [14:20] alf_: I agree - they have different effects [14:21] hmm [14:21] isnt just a matter of abstraction when describing the effect [14:21] +that [14:22] there is no problem in changing the interface.. I just want to understand that point.. or rather.. [14:22] when do you think overloading is ok-ish.. and when is it considered harmful .. not appropriate.. [14:23] draw_a_gun() and draw_a_card() vs draw() [14:24] ^ a good case of draw(gnu) draw(card)? [14:25] anpok: a bad case [14:25] oh really? [14:25] draw : gnu -> void draw : card -> void .. [14:26] they wont have the same effect but both draw .. somewhere.. [14:27] .. compare to operator<<(stream, T) [14:28] anpok: well, it really depends on the context, but drawing a gun is drawing a card is not related in general. For example in a class Cowboy I would expect two different methods. [14:28] oh .. gun ... i read gnu [14:31] what do you mean be different methods? I would expect neither inside a 'Cowboy' [14:31] s/be/by [14:35] anpok: Well, now we are starting to discuss class design completely theoretically... :) [14:35] meta design [14:35] we need space glasses for that.. [14:36] http://blog.spaceglasses.com/ [14:36] guess we just have to expense that.. [14:36] draw_a_picture_of_a(gnu) is different again [14:38] ok need to go offline again.. [14:38] anpok: I guess for me the ultimate counter example we have is mev::make_event(). At one abstraction level you could say that all these create "events", and that's correct, but I argue that we should have "make_touch_event", "make_pointer_event" etc instead [14:38] * alan_g wonders about angels and points of pins [14:39] anpok: going with the first approach (all these create events) has led to a very hard to read API [14:39] alf_: there I agree it should not be the same name, [14:40] bbl [15:54] * alan_g is tired of segfaults deep inside /usr/lib/x86_64-linux-gnu/dri/i965_dri.so === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === alan_g is now known as alan_g|EOW === benonsoftware is now known as MisterHiyas