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