[03:52] <RAOF> Today's yak shaving: gdb --args gdb --args bin/mir_unit_tests --gtest_filter=...
[05:19] <duflu_> RAOF: Heh. I encountered gdb crashes ending last week too. Very frustrating
[05:44] <RAOF> Prior to that was working out why my local MTA wasn't working.
[05:44] <RAOF> Spoilers: nullmailer is terrible, and should not be used by anyone.
[06:07] <tvoss> RAOF, have been to the nullmailer movie, too :) quite interesting how much CPU something that simple can use
[06:08] <RAOF> Quite interesting how many people feel like reimplementing getopt() without features such as “oh, maybe someone will want to have a space in the input” :)
[06:33] <duflu> Gah, gdb keeps crashing!
[06:36] <RAOF> While reading debugging symbols?
[06:36] <RAOF> It's pretty rad, isn't it?
[09:04] <anpok_> alan_g: I need you opinion
[09:04] <alan_g> anpok_: about?
[09:05] <anpok_> the issue you discovered in the drop-dynamic-ptr-cast MP - I see two possible ways of cleanup to fix that kind of issue
[09:05] <anpok_> not sure which path to take
[09:05] <anpok_> because only the server holds the input_dispatcher_configuration and because of the order of calls the in the nested case
[09:06] <anpok_> the first instance of it gets discarded after initializing the nested platform
[09:06] <anpok_> i thought to fix it by removing the dispatcher_configuration entirely
[09:07] <anpok_> there are only two method calls involved the rest of the initialization parameters is passed only through constructors
[09:08] <anpok_> .. now I wonder if I should try to hide the droidinput::DispatcherPolicy and droidinput::InputDispatcherInterface types from the default_display_configuration
[09:08] <alan_g> Hm. This is the problem with several "configuration" objects that hold state. Getting rid of them is a good idea.
[09:08] <anpok_> I could do so by moving the construction and wiring into the implementation of mir::input::android::AndroidInputDispatcher
[09:09] <anpok_> or should I have them as entities in the DefaultDisplayConfiguration
[09:09] <anpok_> when moving them down there, testing without them will require separate construction code..
[09:09] <anpok_> down == AndroidInputDispatcher
[09:10] <anpok_> on the other hand I dislike leaking that namespace (android and the alias droidinput) into DefautlDisplayConfiguration
[09:12] <alan_g> anpok_: I think the long term progression will be to move stuff from the "3rd_party" fork of android input into "src" - and that will eventually resolve the naming issues.
[09:13] <alan_g> So I'm not too bothered by exposing the names. (Or we could just move the classes to a new namespace and have that referenced from droidinput"
[09:14] <anpok_> it would be the names and CachedAndroidPtr
[09:14] <anpok_> that one pulls in Ref
[09:14] <anpok_> RefBase and StrongPointer
[09:15] <alan_g> Not so nice.
[09:15] <anpok_> which
[09:15] <anpok_> might then go away one day too
[09:16] <alan_g> True. Making them go away would be nice.
[09:16] <anpok_> I could try to move those to <memory>
[09:17] <anpok_> ok then I will go for the slightly simpler but cleaner solution
[09:17] <alan_g> Yes. For just a couple of classes that might work. But it could also start an unravel.
[09:18] <alan_g> How about spending an hour or so on changing those sp's as a separate prerequisite MP? If it doesn't go easy then give up for now.
[09:19] <anpok_> yap
[09:22] <alan_g> Has anyone else noticed that "discover_tests_in_mir_unit_tests" takes an age. WTF is it doing?
[09:49] <duflu> Discovering?
[09:49] <duflu> :)
[10:00] <anpok_> nothing left to be found?
[10:37] <duflu> alan_g: Was there any other rule to distinguishing errors from exceptions apart from recoverability?
[10:39] <alan_g> duflu: that's certainly one. But with a whole range of error reporting options there's a few nuances. You have a specific example?
[10:40] <duflu> alan_g: I have a rather nice framework, but am trying to avoid converting too many exceptions to errors. You will see...
[13:12] <kgunn> greyback: so i'm seeing some other people talk about splash screen in mir...but to me, that doesn't make sense, shouldn't it be unity-mir that paints the 1st frame with a "unity8" splash ?
[13:14] <kgunn> e.g. other shells might want to have their own splash
[13:14] <greyback> kgunn: some shells may not want a splash (desktops don't usually)
[13:15] <greyback> kgunn: I intended that unity-mir would supply info to the shell, so the shell could show the splash screen
[13:15] <kgunn> greyback: so potentially configurable based on "form factor" ?
[13:16] <greyback> kgunn: right
[13:16] <kgunn> greyback: thanks, at least we both agree, not a mir thing but a shell thing
[13:17] <greyback> kgunn: yep
[13:19] <greyback> kgunn: there's a few outstanding questions on splash screen stuff, https://blueprints.launchpad.net/ubuntu/+spec/appdev-1311-sdk-appstartupsplash
[13:20] <greyback> kgunn: I'll ping kalikiana and see where they're at
[14:20] <racarr__> Morning
[14:25] <seb128> rhey racarr__
[14:31] <racarr__> seb128: Btw someone else ran in to touchscreen not working in unity8 and I got some logs...am going to debug it today
[14:31] <racarr__> so may have a fix
[14:31] <seb128> great, thanks
[14:31] <racarr__> ill email you if so :)
[14:31] <seb128> let me know if you need debug info from me
[14:31] <racarr__> I have no touchscreen so will need testing friends at least
[14:32] <seb128> sorry I didn't propose that to the other day, I though it was a "need a local config" not a "it's a bug"
[14:32] <seb128> I can do that
[14:32] <racarr__> np
[14:32] <racarr__> I thought it was just going to be a config file thing too but the other guy gave me some logs and there is
[14:32] <racarr__> some sort of small email
[14:32] <racarr__> some sort of small bug*
[14:32] <racarr__> ...the keys are right next to eachother?!
[14:33] <seb128> (I hope that poor celeron box is good enough to build Mir, I've hear comments about Mir being yet another of those awesome c++ projects so easy to build)
[14:33] <racarr__> haha itll be fine
[14:37] <racarr__> alan_g: I have run in to a strange architecture issue with the scene observer and cursor and am wondering if you have any ideas...
[14:37] <racarr__> the problem is...ok so my basic approach is there is a new mi::CursorListener implementation
[14:37] <alan_g> racarr__: ideas me?
[14:37] <racarr__> which takes mi::InputTargets and
[14:38] <racarr__> when the cursor moves finds the surface under it and sets the cursor image, et
[14:38] <racarr__> c
[14:38] <alan_g> CursorListener is an interface or the new implementation?
[14:38] <racarr__> CursorListener is an existing interface
[14:38] <racarr__> right now it just takes cursor_moved_to from the input stack and calls mg::Cursor::move_to
[14:39] <racarr__> so the new CursorController impl takes these cursor_moved to and calls mg::Cursor::move_to but also looks for the appropriate uh
[14:39] <racarr__> unoccluded surface to get its cursor image data
[14:39] <racarr__> the problem is with mi::InputTargets....
[14:39] <racarr__> my idea was to promote scene::add_observer to mi::InputTargets. because this thing also needs to be an observer clearly
[14:39] <racarr__> but that doesn't work
[14:40] <racarr__> because scene::add_observer passes scene::Surface*
[14:40] <racarr__> and in my tests I just want to stub/mock input::Surface/input::InputTargets
[14:41] <alan_g> Naturally
[14:42] <racarr__> so I can't think of any satisfactory solution...I mean obviously mi:CursorController shouldn't take mc::Scene
[14:42] <alan_g> But why does it want to observe scene? Doesn't it really want to ask InputTargets to supply the right cursor?
[14:42] <racarr__> alan_g: Oh hmm
[14:43] <alan_g> input_targets->update_cursor(cursor);
[14:43] <racarr__> there also needs to be some observation...maybe it can be internal to the input targets or ith another method though
[14:44] <racarr__> but I mean, surface closes, you may need to update the cursor
[14:46] <racarr__> So I mean one "fix" would be
[14:46] <racarr__> input_targets->update_cursor_image(cursor, point) +
[14:46] <alan_g> Yes, but CursorListenerImpl is only handling cursor movement events
[14:46] <racarr__> input_targets->add_occlusion_change_callback
[14:46] <racarr__> std::function<void()>
[14:46] <alan_g> Actually...
[14:47] <racarr__> but that seems like a pain too
[14:47] <racarr__> alan_g: Who handles the
[14:47] <racarr__> say surface destroyed and need to update the cursor "events" t hough
[14:47] <alan_g> Why is CursorListener telling the cursor what to do? Surely a Listener tells other things that it has changed
[14:48] <racarr__> alan_g: Android inputism
[14:48] <racarr__> CursorListener should be named
[14:48] <racarr__> CursorSink
[14:48] <racarr__> or something
[14:48] <racarr__> its just how we get the cursor pos out of the input stack
[14:51] <alan_g> So CursorSink isn't the thing that monitors model changes
[14:51] <racarr__> hmm
[14:51] <racarr__> not necessarily no
[14:52] <racarr__> but the thing that implements CursorSink...could conceivably be that.
[14:52] <racarr__> because I was trying to keep it to one place that manipulates the cursor image
[14:52] <racarr__> because there is some logic, i.e. if no surface is present at point use the cursor specified as default
[14:53] <racarr__> if the scene change doesnt change the cursor image avoid reuploading it (significantly reduces noise ina cceptance tests in addition to being an optimization)
[14:53] <racarr__> etc...
[14:53] <alan_g> Sure, but I've a feeling that the "surface isn't there anymore" notification should come via compositing not the scene
[14:53] <racarr__> via compositing?
[14:54] <alan_g> Isn't it the compositor that maps the scene into the display? And owns the cursor?
[14:55] <racarr__> no, the compositor doesnt much to do with the cursor
[14:55] <racarr__> as it stands its in the gbm display buffer mostly
[14:55] <racarr__> but the goal is the scene owns the cursor
[14:55] <racarr__> so it will just be another type of renderable
[14:55] <racarr__> because on android there is no special cursor buffer or anything
[14:55] <racarr__> and also we want to support software cursors well, etc...
[14:55] <alan_g> If the scene owns the cursor how do you manage spreads and other effects?
[14:56] <racarr__> ? Even when you spread the cursor is still just
[14:56] <racarr__> a 64x64 buffer that appears on top of
[14:56] <racarr__> everything
[14:56] <racarr__> that is rendered at an x,y coordinate
[14:56] <alan_g> The scene isn't changed when you do a spread
[14:57] <racarr__> but the cursor doesnt change when you spread unless
[14:57] <racarr__> it would change anyway due to toehr things right?
[14:57] <racarr__> Also in "qt compositor short term arch" certainly the scene doesnt change
[14:57] <racarr__> when you spread
[14:57] <racarr__> but in "qt compositor long term arch"
[14:57] <racarr__> it does right, I mean spread is transformation updates, etc...
[14:58] <racarr__> ah I see what you are getting at, how would you update the right
[14:58] <racarr__> cursor image in case of spread, etc...
[14:58] <racarr__> I dunno
[15:00] <racarr__> I still feel very strongly that
[15:00] <racarr__> updates to the view/what is rendered
[15:00] <racarr__> that arent expressed in the model
[15:01] <racarr__> will be the architectural death of us if we do it :p
[15:01] <racarr__> so all this stuff like spread, zoom, decorations being int he compositor/renderer
[15:01] <racarr__> worries me a lot
[15:01] <alan_g> They are projections of the model onto the screen. And the cursor is tied to the screen image and not projected.
[15:02] <alan_g> anyway standup time
[15:02] <racarr__> I see...maybe
[15:02] <racarr__> the problem is it becomes
[15:02] <racarr__> "Model Model-View-Controller Controller"
[15:03] <racarr__> which is a pretty hair architecture :p
[23:40] <RAOF> Ok. Now that my tea has stopped trying to murder me...