| === chihchun_afk is now known as chihchun | ||
| RAOF | Today's yak shaving: gdb --args gdb --args bin/mir_unit_tests --gtest_filter=... | 03:52 |
|---|---|---|
| duflu_ | RAOF: Heh. I encountered gdb crashes ending last week too. Very frustrating | 05:19 |
| === duflu_ is now known as duflu | ||
| 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. | 05:44 |
| tvoss | RAOF, have been to the nullmailer movie, too :) quite interesting how much CPU something that simple can use | 06:07 |
| 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:08 |
| duflu | Gah, gdb keeps crashing! | 06:33 |
| RAOF | While reading debugging symbols? | 06:36 |
| RAOF | It's pretty rad, isn't it? | 06:36 |
| anpok_ | alan_g: I need you opinion | 09:04 |
| alan_g | anpok_: about? | 09:04 |
| 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:05 |
| 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:06 |
| anpok_ | there are only two method calls involved the rest of the initialization parameters is passed only through constructors | 09:07 |
| 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:08 |
| 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:09 |
| anpok_ | on the other hand I dislike leaking that namespace (android and the alias droidinput) into DefautlDisplayConfiguration | 09:10 |
| 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:12 |
| 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:13 |
| anpok_ | it would be the names and CachedAndroidPtr | 09:14 |
| anpok_ | that one pulls in Ref | 09:14 |
| anpok_ | RefBase and StrongPointer | 09:14 |
| alan_g | Not so nice. | 09:15 |
| anpok_ | which | 09:15 |
| anpok_ | might then go away one day too | 09:15 |
| alan_g | True. Making them go away would be nice. | 09:16 |
| anpok_ | I could try to move those to <memory> | 09:16 |
| 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:17 |
| 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:18 |
| anpok_ | yap | 09:19 |
| alan_g | Has anyone else noticed that "discover_tests_in_mir_unit_tests" takes an age. WTF is it doing? | 09:22 |
| duflu | Discovering? | 09:49 |
| duflu | :) | 09:49 |
| anpok_ | nothing left to be found? | 10:00 |
| duflu | alan_g: Was there any other rule to distinguishing errors from exceptions apart from recoverability? | 10:37 |
| 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:39 |
| duflu | alan_g: I have a rather nice framework, but am trying to avoid converting too many exceptions to errors. You will see... | 10:40 |
| === 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 | ||
| 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:12 |
| 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:14 |
| 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:15 |
| greyback | kgunn: right | 13:16 |
| === chihchun_afk is now known as chihchun | ||
| kgunn | greyback: thanks, at least we both agree, not a mir thing but a shell thing | 13:16 |
| greyback | kgunn: yep | 13:17 |
| greyback | kgunn: there's a few outstanding questions on splash screen stuff, https://blueprints.launchpad.net/ubuntu/+spec/appdev-1311-sdk-appstartupsplash | 13:19 |
| greyback | kgunn: I'll ping kalikiana and see where they're at | 13:20 |
| === chihchun is now known as chihchun_afk | ||
| racarr__ | Morning | 14:20 |
| === alan_g is now known as alan_g|tea | ||
| seb128 | rhey racarr__ | 14:25 |
| === alan_g|tea is now known as alan_g | ||
| 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:31 |
| 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:32 |
| 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:33 |
| 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:37 |
| 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:38 |
| 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 |
| === dandrader is now known as dandrader|afk | ||
| racarr__ | but that doesn't work | 14:39 |
| 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:40 |
| alan_g | Naturally | 14:41 |
| 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:42 |
| 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:43 |
| racarr__ | but I mean, surface closes, you may need to update the cursor | 14:44 |
| 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:46 |
| 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:47 |
| 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:48 |
| alan_g | So CursorSink isn't the thing that monitors model changes | 14:51 |
| racarr__ | hmm | 14:51 |
| racarr__ | not necessarily no | 14:51 |
| 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:52 |
| 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:53 |
| alan_g | Isn't it the compositor that maps the scene into the display? And owns the cursor? | 14:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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 | 14:58 |
| 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:00 |
| 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:01 |
| 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:02 |
| racarr__ | which is a pretty hair architecture :p | 15:03 |
| === 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 | ||
| RAOF | Ok. Now that my tea has stopped trying to murder me... | 23:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!