[12:37] <greyback_> 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] <greyback_> if so, would be nice to include with mir 0.17.1 release
[12:39] <alan_g> greyback_: not yet. But looks similar to other nested display config problems I'm chasing down
[12:40] <greyback_> alan_g: ok
[12:58] <alan_g> greyback_: have you seen anything similar on phone? https://bugs.launchpad.net/mir/+bug/1511723
[12:58] <greyback_> alan_g: I haven't actually.
[12:59] <greyback_> alan_g: that's desktop only?
[13:00] <alan_g> greyback_: that's what I've been testing - as most of the display management problems are platform independent
[13:41] <anpok> alf: was that convincing enough? https://code.launchpad.net/~andreas-pokorny/mir/input-configuration-api/+merge/273975/comments/697135
[14:02] <alf_> anpok: is a device configured either as touchpad or pointer?
[14:03] <alf_> anpok: or => xor
[14:07] <anpok> alf_: no.. touchpads are both touchpads and pointers
[14:07] <anpok> mice are just pointers..
[14:13] <alf_> 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] <alf_> anpok: Anyway, I won't block on that.
[14:20] <alan_g> alf_: I agree - they have different effects
[14:21] <anpok> hmm
[14:21] <anpok> isnt just a matter of abstraction when describing the effect
[14:21] <anpok> +that
[14:22] <anpok> there is no problem in changing the interface.. I just want to understand that point.. or rather..
[14:22] <anpok> when do you think overloading is ok-ish.. and when is it considered harmful .. not appropriate..
[14:23] <alan_g> draw_a_gun()  and draw_a_card() vs draw()
[14:24] <anpok> ^ a good case of draw(gnu) draw(card)?
[14:25] <alf_> anpok: a bad case
[14:25] <anpok> oh really?
[14:25] <anpok> draw : gnu -> void      draw : card -> void ..
[14:26] <anpok> they wont have the same effect but both draw <something> .. somewhere..
[14:27] <anpok> .. compare to operator<<(stream, T)
[14:28] <alf_> 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] <anpok> oh .. gun ... i read gnu
[14:31] <anpok> what do you mean be different methods? I would expect neither inside a 'Cowboy'
[14:31] <anpok> s/be/by
[14:35] <alf_> anpok: Well, now we are starting to discuss class design completely theoretically... :)
[14:35] <anpok> meta design
[14:35] <anpok> we need space glasses for that..
[14:36] <anpok> http://blog.spaceglasses.com/
[14:36] <anpok> guess we just have to expense that..
[14:36] <alan_g> draw_a_picture_of_a(gnu) is different again
[14:38] <anpok> ok need to go offline again..
[14:38] <alf_> 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] <alf_> anpok: going with the first approach (all these create events) has led to a very hard to read API
[14:39] <anpok> alf_: there I agree it should not be the same name,
[14:40] <anpok> bbl
[15:54]  * alan_g is tired of segfaults deep inside /usr/lib/x86_64-linux-gnu/dri/i965_dri.so