| racarr_ | annnd back | 01:32 |
|---|---|---|
| racarr_ | I just realized a great alternative to input-sender besides | 04:21 |
| racarr_ | copying InputDispatcher in to unity-mir lol | 04:21 |
| racarr_ | it's also possible to just take the unity-mir InputDispatcher patches (for a certain kind of injection) in to our input dispatcher, and expose it | 04:22 |
| racarr_ | via say...the_input_sender() with a small wrapper class | 04:22 |
| racarr_ | without exposing any of the android-deps. | 04:23 |
| === chihchun_afk is now known as chihchun | ||
| alan_g | alf__: I don't really understand the motivation for the attributes mechanism: It uses values (index into the attribute array) in place of types which I guess allows some binary compatibility - but the way we use it hides that behind incompatible functions. (We have mir_surface_set_swapinterval() not mir_surface_set_attribute(...mir_surface_attrib_swapinterval...)) | 09:04 |
| alf__ | alan_g: I see it as an internal convenience mechanism for adding (simple) surface attributes and associated change notifications | 09:09 |
| alan_g | alf__: I sometimes see it as an internal inconvenience mechanism. ;) | 09:15 |
| alf__ | Saviq: Hi! Do you know if Gerry is around today? | 09:25 |
| Saviq | alf__, it feels like he took a swap day today... but I'm not positive on that... | 09:27 |
| alf__ | Saviq: thanks | 09:27 |
| alf__ | Saviq: Do you know where the qt compositor branch is? | 09:28 |
| Saviq | alf__, of unity8? | 09:28 |
| alf__ | Saviq: yes | 09:29 |
| Saviq | alf__, https://code.launchpad.net/~unity-team/unity8/mirCompositor | 09:29 |
| alf__ | Saviq: great, thanks | 09:29 |
| Saviq | alf__, mzanetti will be able to guide you through the branches, too | 09:29 |
| Saviq | alf__, you can also always look at https://launchpad.net/~unity-team/+archive/phone-right-edge/+packages | 09:30 |
| Saviq | alf__, and see that unity8 was built by recipe unity8-qtcompositor | 09:30 |
| Saviq | alf__, and that, in turn, will tell you which branch it builds from :) | 09:30 |
| alf__ | Saviq: ha ^ | 09:31 |
| Saviq | :) | 09:33 |
| alf__ | greyback: Good morning! I have added as reviewer for https://code.launchpad.net/~afrantzis/mir/scene-elements/+merge/223822 . I don't need a code review (but you are welcome to do so), just a Qt compositor perspective on the approach (see comments). | 09:35 |
| greyback | alf__: hey. Ok, will take a look | 09:35 |
| === alan_g is now known as alan_g|lunch | ||
| === renato_ is now known as Guest34798 | ||
| === alan_g|lunch is now known as alan_g | ||
| mterry | Hey folks! Can I get someone to review https://code.launchpad.net/~mterry/unity-system-compositor/kill-spinner/+merge/223837 ? | 13:11 |
| kgunn | AlbertA: ^ would you mind ? | 13:38 |
| kgunn | alan_g: alf__ racarr_ so dandrader and i were just chatting about inputsender branch | 13:44 |
| alan_g | kgunn: ok | 13:44 |
| kgunn | if we go back in time, reason for this was to avoid exposing android headers in our public includes.... | 13:44 |
| kgunn | howerver, what are your thoughts on it compared to (vs.) input sender | 13:45 |
| kgunn | being a large diff, that might bring in bugs | 13:45 |
| kgunn | whereas exposing android headers would be a direct/proven path | 13:46 |
| kgunn | ...and we're not exactly settling on inputsender | 13:46 |
| alan_g | Why would we need to expose android headers? | 13:46 |
| dandrader | alan_g, so that qtmir can replace android::InputDispatcher with its own thing | 13:47 |
| dandrader | alan_g, not needing the input_sender interfaces then | 13:47 |
| kgunn | right, sender is effectively a wrapper | 13:47 |
| dandrader | alan_g, and the big mir changes that entails it | 13:47 |
| kgunn | dandrader: is that really the _only_ reason ? avoiding the header thing for custom dispatcher | 13:48 |
| alf__ | kgunn: I assume we are discussing in the context of rtm? | 13:49 |
| alan_g | dandrader: I've not been following the branch closely but I don't understand why a custom dispatcher would need all the stuff that has aggregated there. | 13:49 |
| kgunn | alf__: yes, well landing qtcomp for sure | 13:49 |
| dandrader | alan_g, I didn't go through that branch. I just used the needed interfaces it provides. so can't comment on the rest | 13:50 |
| alan_g | E.g. timer and scheduler classes being introduced in or moved to the wrong namespace | 13:50 |
| alf__ | alan_g: kgunn: IIRC, originally what was needed was to be able to deregister fd handlers from the main loop | 13:51 |
| kgunn | ah so there's a little more than the header sanitation issue | 13:52 |
| alf__ | alan_g: kgunn: but that led to further complexity added to MainLoop, and the decision was made to split things out (and Timer functionality too), as a refactoring | 13:52 |
| dandrader | so at this point, to make it for RTM, the safest approach, IMHO, would be to expose android-input headers as a "private API" (i.e. an exposed API that can/will change without further notice, "use it at your own risk") | 13:53 |
| * alan_g thinks someone needs to be taught the "mikado game" | 13:53 | |
| * kgunn has to google mikado game | 13:55 | |
| alan_g | I thought racarr_ was going to review this and propose a solution? | 13:55 |
| dandrader | so that we unblock the qt compositor work and don't bring in any polemic mir changes | 13:55 |
| alf__ | dandrader: kgunn: will exposing the android-input headers (even as "private") commit us in any way to continue using them? | 13:55 |
| dandrader | alf__, you can remove them once mir API for doing the same (e.g. input_sender) is available | 13:56 |
| dandrader | alf__, in order to not leave qtmir in the dark | 13:57 |
| alan_g | kgunn: try googling "jeff langer mikado Method" | 13:57 |
| alf__ | alan_g: kgunn: "langr" :) | 13:57 |
| kgunn | dandrader: right, but begs the question...is it the right thing | 13:57 |
| kgunn | to do | 13:57 |
| kgunn | i suppose its not forced on anyone | 13:58 |
| kgunn | e.g. only shells that wanna replace input dispatcher | 13:58 |
| alan_g | the right thing to do is properly integrate our fork of android input into the rest of Mir | 13:58 |
| kgunn | i gotta hop otp, bbian | 13:58 |
| kgunn | oops/bbian/bbiab | 13:58 |
| * alan_g wonders if we achieved anything | 14:00 | |
| dandrader | alan_g, but do we have time to do the right thing? | 14:00 |
| alan_g | dandrader: Short term: I don't know. But this is a continuing drain of resources: do we have the time not to do the right thing? | 14:02 |
| alan_g | I don't have a strong position on anything except that the MP is currently in a state of confusion. It could be pragmatic to land and fix after. | 14:04 |
| dandrader | alan_g, I do think we have the time to go for the approach of exposing android-input headers until the input_sender work is shiny and ready to land | 14:05 |
| dandrader | meaning landing input_sender post RTM | 14:05 |
| dandrader | when-it's-done | 14:05 |
| alan_g | dandrader: racarr_ was looking into this. What does he say? | 14:07 |
| dandrader | alan_g, we will know once he starts his work-day today | 14:08 |
| dandrader | I'm just getting freaked out about the impending deadline approaching and we still having qtcomp blocked | 14:09 |
| === chihchun is now known as chihchun_afk | ||
| === dandrader is now known as dandrader|afk | ||
| greyback | alf__: still there? | 15:31 |
| alf__ | greyback: yes | 15:32 |
| greyback | alf__: just looking at https://code.launchpad.net/~afrantzis/mir/scene-elements/+merge/223822/comments/537129 | 15:32 |
| greyback | alf__: I don't quite understand the question. | 15:32 |
| alf__ | greyback: ok | 15:32 |
| greyback | alf__:" compositor *has* to decide whether it's going to use a renderable or not when getting it" | 15:32 |
| greyback | could you rephrase please | 15:33 |
| greyback | alf__: directly I don't see any impact to QtComp with that change, since we don't use mir's Scene at all | 15:34 |
| greyback | and overall I think it's a good idea | 15:34 |
| alf__ | greyback: in the MP the compositor gets a sequence of all SceneElements (corresponding to surfaces) as distinct objects and can process them (e.g. mark them as occluded or rendered) at any convenient time during compositing. The alternative is for the scene to do the filtering, but that means that the compositor needs to know at the beginning which surfaces it will render and which not. | 15:37 |
| alf__ | greyback: @we don't use mir's Scene at all, hmmm, hmmmmmmmm | 15:37 |
| alf__ | greyback: so qt compositor itself will take care of telling surfaces when they are occluded? | 15:38 |
| greyback | alf__: it'll have to yes. | 15:38 |
| === dandrader|afk is now known as dandrader | ||
| alf__ | greyback: so I guess what's in devel right now (the ability to configure a surface attribute for visibility on the server) is enough for you? | 15:40 |
| alf__ | greyback: (changing visibility will send an event to the client) | 15:41 |
| greyback | alf__: effectively yes | 15:41 |
| greyback | alf__: I like the idea of the compositor being pretty dumb, it should just render exactly the list of things it is given. So I'd prefer scene to do the filtering | 15:43 |
| alf__ | greyback: well, the "scene" in mir is not a proper Scenegraph, so it doesn't have all the information to do the filtering | 15:44 |
| greyback | alf__: then with current mir arch, the compositor is the only thing which has the info to do the filtering, am I right? | 15:45 |
| alf__ | greyback: yes (although the scene could do it for some cases) | 15:47 |
| racarr_ | dandrader: I have another solution for input sender | 15:49 |
| racarr_ | alan_g: ^ | 15:50 |
| alf__ | kdub_: ^^ (discussion with greyback) | 15:50 |
| alan_g | racarr_: \o/ | 15:50 |
| racarr_ | 1. Small input_dispatcher patcher in our tree that exposes like sendToTargets. | 15:50 |
| racarr_ | 2. Wrap InputDispatcher in our server configuraiton as | 15:50 |
| racarr_ | wait for it...the_input_sender | 15:50 |
| racarr_ | 3. Export that | 15:50 |
| racarr_ | 3. When non android input sender is ready | 15:51 |
| racarr_ | drop it in API compatible | 15:51 |
| greyback | alf__: I don't know what more I can say then :) | 15:53 |
| kdub_ | greyback, the thing I don't like about the scene having /all/ the information is scenarios where the compositor (the view) has some state | 15:53 |
| greyback | kdub_: IMO compositor should not have any state, only the scene should | 15:54 |
| alan_g | racarr_: that sound like what I thought anpok tried to do before starting n unravelling the world | 15:54 |
| kdub_ | like, if you have some perspective that affects occlusion set in the compositor, then the compositor is the best to figure that out | 15:54 |
| alan_g | But I've yet to understand why it doesn't work | 15:54 |
| racarr_ | alan_g: Ok I am 95% sure it can work... | 15:54 |
| racarr_ | and I thought | 15:54 |
| racarr_ | anpok just got excited by | 15:55 |
| racarr_ | tryinhg to "fix" everything | 15:55 |
| racarr_ | lol | 15:55 |
| racarr_ | i.e. eventually we really would like to chunk up input dispatcher | 15:55 |
| greyback | kdub_: right, but IMO that perspective should be defined in the scene, just executed by the compositor. Say if you do add that perspective just in the compositir, how then do you calculate the input destination? | 15:55 |
| alan_g | racarr_: make it so! | 15:55 |
| alan_g | ;) | 15:55 |
| kdub_ | greyback, right, but that limits the flexibility you can have in putting stuff on the screen | 15:56 |
| racarr_ | alan_g: mm ill mp something today. | 15:56 |
| kdub_ | because you can only put on screen what is implemented/designated by the scene | 15:56 |
| kdub_ | whereas if you're given this universal idea of a scene, then you can shuffle it around however you want during the gl pass | 15:56 |
| alan_g | racarr_: Sounds good | 15:56 |
| kdub_ | like, the compositor as 'the view' should have state, as long as that state applies only to how the view is seen | 15:57 |
| kdub_ | the visibility stuff is an example of how we can arrange state changes (like input stuff) when accessing the scene | 15:59 |
| kdub_ | I guess what I'm driving against is having stuff like 'spread' or 'zoom' as scene concepts | 16:00 |
| dandrader | racarr_, so we need two things. 1- get all input events out of InputReader, 2- ability to send an event to a given surface (actually its underlying input channel). your solution seems to take care of only item 2? | 16:00 |
| alf__ | kdub_: greyback: I guess if Qt's Scenegraph is powerful enough to represent all views we need to support for unity8, then qt compositor won't care about compositor->scene communication anyway | 16:01 |
| greyback | kdub_: I worry if any visual state is defined in the compositor, then the input system will be lacking information | 16:01 |
| dandrader | otherwise, yeah, it sounds like it would solve our problems | 16:01 |
| kdub_ | greyback, right, but the compositor is already mapping the surface from the 'universal' scene designation to the 'onscreen' mapping, so hopefully that information can just be fed back to the scene | 16:02 |
| kdub_ | and input is happy | 16:02 |
| racarr_ | dandrader: Hmm...right... | 16:02 |
| racarr_ | dandrader: Would it be enough to use | 16:02 |
| racarr_ | the_input_filter? | 16:02 |
| greyback | kdub_: fed back. So compositor writes to the scene? | 16:02 |
| racarr_ | it will get all the events....and can drop them from the normal dispatch | 16:03 |
| racarr_ | by "handling them" | 16:03 |
| racarr_ | then reinject them to a specific channel | 16:03 |
| racarr_ | if they come back out of Qt | 16:03 |
| kdub_ | greyback, it has to get the info there, kinda like the visibility stuff | 16:03 |
| kdub_ | and so I guess the scene then has the info, but its more generic | 16:03 |
| dandrader | racarr_, sounds good. question is: how much effort is required to come up with such MP? | 16:04 |
| greyback | kdub_: if the scene had all the visual state itself, then the scene has enough info to determine visibility | 16:04 |
| greyback | and compositor doesn't need to "feed back" - just needs to render what it is told to render | 16:04 |
| alf__ | greyback: "I guess if Qt's Scenegraph is powerful enough to represent all views we need to support for unity8" -> is it? | 16:04 |
| dandrader | racarr_, does this the_input_filter already exist? | 16:04 |
| racarr_ | dandrader: I think like 2-3 hours :) | 16:04 |
| racarr_ | the_input_filter does exist | 16:05 |
| racarr_ | the input dispatcher patch...I think I found a quite easy approach | 16:05 |
| racarr_ | that will let both work | 16:05 |
| racarr_ | and then | 16:05 |
| racarr_ | the_input_sender itself is the same interface | 16:05 |
| racarr_ | as from anpoks mp | 16:05 |
| dandrader | racarr_, it's too good to be true :) | 16:05 |
| kdub_ | greyback, but what about simple vs complex compositors | 16:05 |
| greyback | alf__: sorry, missed that. I've not encountered any design request that QML was unable to do yet | 16:05 |
| racarr_ | it seems so doesnt it lol | 16:05 |
| racarr_ | dandrader: Anyway im going to give it a try today and get a proposal up then on monday | 16:06 |
| racarr_ | maybe anpok will have a stroke of brilliance and input sender will be instantly ready | 16:06 |
| racarr_ | and if not we can land this and it will be ABI compatible | 16:07 |
| dandrader | racarr_, the simpler the better | 16:07 |
| kdub_ | like, if someone doesn't need an animation/zoom/etc framework, but is given one by the scene, makes the usc-type compositors less possible (or at least less lightweight) | 16:07 |
| racarr_ | :) | 16:07 |
| racarr_ | dandrader: For the actual injection, surface->consume(event) like in input sender is enough right? | 16:07 |
| alf__ | greyback: ok, do you need anything more from the visibility events side (as mentioned you can send occluded/exposed events to client surfaces with mir/devel)? | 16:08 |
| racarr_ | No extra flags or anything | 16:08 |
| dandrader | racarr_, yeah surface->consume(event) would be the best API. | 16:08 |
| greyback | alf__: I don't think so. Note it is something we'd like working in USC, when split greeter lands it's a nice optimisation, so have unity8 notified it is hidden | 16:09 |
| racarr_ | Ok! will get on it as soon as the coffee kicks in | 16:09 |
| dandrader | :) | 16:09 |
| kdub_ | so, in summary, I guess I'm just interested in having the ideas in the scene be very generic, and the 'compositor' can set some of those generic ideas | 16:10 |
| greyback | kdub_: then building a scene into Mir at all is doomed. How it be both simple and complex? | 16:10 |
| greyback | kdub_: QtComp isn't using Mir's scene, because Mir's scene is too basic | 16:11 |
| alf__ | greyback: go not to the elves for counsel, for they will say both no and yes | 16:11 |
| greyback | alf__: :D | 16:11 |
| racarr_ | kgunn: Just to fill you in, have a new input sender theory | 16:11 |
| kdub_ | greyback, i guess thats the challenge, to have the scene ideas be flexible enough to support the complex stuff without forcing requirements on the simple compositors | 16:12 |
| racarr_ | That's the great thing about trees lol | 16:12 |
| racarr_ | kgunn: Basically patch our input dispatcher to support what they need | 16:13 |
| racarr_ | expose it via mir::InputSender | 16:13 |
| racarr_ | ABI compatible when anpoks stuff is done | 16:13 |
| greyback | kdub_: those terms sounds contradictory to me, but perhaps there is a middle-ground | 16:14 |
| greyback | I hope you enjoy challenges ;) | 16:14 |
| racarr_ | I don't think its contradictory! | 16:14 |
| racarr_ | QML isn't hard for simple apps. | 16:14 |
| alf__ | greyback: how are you tracking server surfaces in qt compositor (e.g. do you intercept creation and attach the surface to your own/Qt's objects?) | 16:14 |
| greyback | alf__: exactly that | 16:15 |
| racarr_ | kgunn: Did spend time reviewing input-sender... | 16:15 |
| racarr_ | it does seem roughly correct, but there are...um | 16:16 |
| racarr_ | on the order of dozens of small issues | 16:16 |
| racarr_ | which in a normal situation we would block review with | 16:16 |
| racarr_ | which makes it kind of hard | 16:16 |
| racarr_ | to convince yourself there aren't major problems because of all the minor problem noise | 16:16 |
| racarr_ | sooooo....I think we would be luckly to land it by next week. | 16:17 |
| racarr_ | confidently land it | 16:17 |
| * kdub_ has forgotten the original topic | 16:17 | |
| racarr_ | kdub_: We were trying to make an alternative to X11 because its hard to extend. | 16:18 |
| racarr_ | :p | 16:18 |
| alf__ | kdub_: greyback: well, ok, for the moment let's focus on something useful for USC and other simple compositors and try to gradually evolve it to something qt compositor can integrate with (it will take time). | 16:18 |
| kdub_ | alf__, right, sounds good to me | 16:19 |
| alf__ | kdub_: original topic was getting the Qt compositor perspective on exposing SceneElement objects vs the scene doing the filtering (your proposal in the comment) | 16:19 |
| alf__ | kdub_: bottom line is that Qt compositor doesn't care about it at all at the moment :P | 16:20 |
| greyback | alf__: +1 from me too | 16:20 |
| alf__ | kdub_: although I like the "tell don't ask" flavor of the scene doing the filtering, it seems from the conversation that exposing SceneElement gives us more flexibility for other use cases (like input) | 16:22 |
| kdub_ | alf__, yeah, the thing I liked over my suggestion in your approach was that the visibility stuff can only be told on a change, instead of every frame | 16:22 |
| * kdub_ makes confusing sentence | 16:23 | |
| kdub_ | alf__, I liked that your approach could only tell when things change | 16:23 |
| kdub_ | also, scene element might be a way to break Renderable::id() | 16:25 |
| kgunn | racarr_: ack | 16:31 |
| kgunn | racarr_: maybe with anpok back on monday and some review attention we can iterate more quickly | 16:31 |
| kgunn | racarr_: dandrader was espousing earlier the idea that just exposing the android headers might not be less risky both in terms of time & bugs | 16:32 |
| kgunn | and then switch when input-sender is ready | 16:32 |
| dandrader | kgunn, s/might not be/might be | 16:33 |
| kgunn | yes | 16:33 |
| kgunn | sorry | 16:33 |
| kgunn | exposing the android headers might _be_ less risky both in terms of time & bugs | 16:33 |
| racarr_ | slightly | 16:35 |
| racarr_ | the idea is this should not be very risky either | 16:35 |
| racarr_ | because its 99% the existing android code | 16:35 |
| racarr_ | so it just saves us exposing the headers I guess | 16:35 |
| racarr_ | right, I mean, an option that has the same risk | 16:36 |
| racarr_ | as exposing the android headers | 16:36 |
| racarr_ | but doesnt expose the headers | 16:36 |
| racarr_ | is rather than make an input dispatcher that can function in both modes (which...again I dont think will be much more than exposing some stuff) | 16:37 |
| racarr_ | is copy dandraders patched input dispatcher | 16:37 |
| racarr_ | in to our tree | 16:37 |
| racarr_ | expose it via the_input_sender (no android headers, small wrapper object...literally just a forwarder) | 16:37 |
| racarr_ | and allow selection of input dispatchers via something in the server configuration | 16:37 |
| racarr_ | that | 16:37 |
| racarr_ | doesn't require android headers...which is easy because its not arbitrary input dispatchers | 16:38 |
| racarr_ | just input dispatcher 1 v. 2 | 16:38 |
| racarr_ | kgunn: dandrader: ^ | 16:38 |
| racarr_ | So. I think that's better than exposing the android headers. | 16:38 |
| dandrader | racarr_, beware that in my android::InputDispatcher fork I removed all the logic about android::InputDispatcher deciding what windows gets the incoming events. So it works only in "dumb" mode. ie: "send this event to this channel" | 16:39 |
| racarr_ | Yes | 16:39 |
| racarr_ | so it would be | 16:39 |
| racarr_ | an alternative input dispatcher | 16:39 |
| racarr_ | rather than replacing ours | 16:39 |
| racarr_ | but like I said I am very hopeful I can make an input dispatcher which will work in both modes | 16:40 |
| racarr_ | without much risk | 16:40 |
| racarr_ | well. it could replace ours at runtime, but I mean we could temporarily have both in tree | 16:41 |
| dandrader | racarr_, having both in the tree sounds safer | 16:41 |
| racarr_ | but I think, taking the InputDispatcher and building it in our tree, then exposing it without android headers. | 16:41 |
| racarr_ | is better than | 16:41 |
| racarr_ | building it in your tree | 16:41 |
| racarr_ | just to prevent leaking | 16:41 |
| racarr_ | android any more and | 16:41 |
| racarr_ | right I mean its just slightly better | 16:41 |
| racarr_ | all around | 16:41 |
| racarr_ | ABI compatibility when input sender lands | 16:41 |
| racarr_ | etc | 16:41 |
| dandrader | racarr_, the "one inputdispatcher that servers all modes" is an unproven approach. it might work, but it might not. I don't think we have time to experiment with that | 16:43 |
| dandrader | racarr_, resist coming up with a cleaner, more beautiful patch :) | 16:44 |
| racarr_ | Lol I guess you are right... there are so many member variables in InputDispatcher its basically impossible to "prove" that changing any one method | 16:46 |
| racarr_ | isn't going to subtly destroy everything | 16:46 |
| racarr_ | even if I have a strong suspiscion in this case lol...ive been known to be wrong | 16:46 |
| racarr_ | so um [ | 16:46 |
| racarr_ | we go with | 16:46 |
| racarr_ | copy your input dispatcher in to our tree | 16:46 |
| racarr_ | expose it via InputSender? | 16:47 |
| racarr_ | How do you get the events out of InputReader in this setup...what does your patched dispatcher do when it gets events from the InputReader (where it would normally decide what windows get the events) | 16:48 |
| racarr_ | because that is the part that offers events to the_input_filter | 16:48 |
| dandrader | racarr_, it just doesn't | 16:49 |
| racarr_ | it doesn't? Where do events go out of the input reader then? | 16:50 |
| dandrader | racarr_, well, in my original patch, there's a QtEventFeeder that gets the events from InputReader instead of InputDispatcher | 16:50 |
| dandrader | racarr_, then eventually the forked InputDispatcher is told to send event X to channel Y and that's it | 16:51 |
| racarr_ | dandrader: Ok so to avoid exposing InputListenerInterface (interface from Reader->Dispatcher) | 16:51 |
| racarr_ | lets modify your forked inputdispatcher to hook up to the input reader again | 16:51 |
| racarr_ | but rip out ALL the logic | 16:51 |
| racarr_ | and it will just immediately | 16:51 |
| racarr_ | send the event | 16:51 |
| racarr_ | to the mir input filter | 16:51 |
| dandrader | racarr_, right | 16:51 |
| racarr_ | ok :D | 16:53 |
| dandrader | racarr_, it was like this https://docs.google.com/a/canonical.com/drawings/d/1tXs9s32ix5c_Iomj2TfGPgx615yCuadWRd1UTJKnbac/edit | 16:53 |
| racarr_ | mm. | 16:54 |
| === alan_g is now known as alan_g|EOW | ||
| === renato_ is now known as Guest14152 | ||
| === dandrader is now known as dandrader|lunch | ||
| === dandrader|lunch is now known as dandrader | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!