| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| RAOF | I am going to be most displeased when I discover that boost::asio is the thing that's broken here... | 08:07 |
|---|---|---|
| RAOF | But for the moment, EOD. | 08:07 |
| anpok | alan_g: do you want to have a last look at just-unregister-fd? Applied your suggestion. I would like to approve it now. | 10:50 |
| alan_g | anpok: looking | 10:51 |
| alan_g | anpok: approved | 10:53 |
| anpok | thx | 10:53 |
| === pete-woods is now known as pete-woods-lunch | ||
| === alan_g is now known as alan_g|lunch | ||
| === renato_ is now known as Guest77133 | ||
| === alan_g|lunch is now known as alan_g | ||
| DonkeyHotei | anpok: how's the mesa work going? | 14:08 |
| === pete-woods-lunch is now known as pete-woods | ||
| anpok | DonkeyHotei: I was gone for a week and not much progress since then. I only discovered that mir server with demo shell works really fine | 14:22 |
| anpok | so mesa directly works flawless | 14:22 |
| anpok | so there must be some kind of initialization issue when mesa runs with mir platform, that causes a corrupt driver state.. | 14:23 |
| anpok | which then causes egl/mir clients to fail | 14:24 |
| DonkeyHotei | would be nice to get a trusty SRU when you fix that | 14:26 |
| === dandrader is now known as dandrader|afk | ||
| kdub_ | alf__, remove the stub from hwc-device-test-cleanup | 15:27 |
| alf__ | kdub_: great, (top) approved | 15:30 |
| kdub_ | alf__, thanks! i think track-visibility-in-default-compositor is good to go | 15:30 |
| === dandrader|afk is now known as dandrader | ||
| kgunn | alf__: so racarr_ thot he might bump server, but he didn't....but i understand some recent "scene" stuff you landed most likely broke abi | 15:58 |
| kgunn | i assume related to visibility prep | 15:59 |
| kgunn | can you mp the bump ? | 15:59 |
| alf__ | kgunn: sure | 16:00 |
| kgunn | ...note, if you do, need to also update build dep for the rdeps (unity-mir, usc, papi) | 16:00 |
| kgunn | at | 16:00 |
| alf__ | kgunn: where do I find these? | 16:00 |
| alf__ | kgunn: I mean the updated values | 16:01 |
| kgunn | alf__: so in mir, its the top most cmake, the debian/control...and changelog of course | 16:02 |
| alf__ | kgunn: ah, nevermind, thought you meant it the other way around | 16:02 |
| === chihchun is now known as chihchun_afk | ||
| kgunn | camako: ^ we're spreading the pain right? you break abi you buy it :) | 16:03 |
| kgunn | alf__: we have been using https://code.launchpad.net/~mir-team/platform-api/development-branch & https://code.launchpad.net/~mir-team/unity-mir/development-branch | 16:03 |
| kgunn | to stage the rdep bumps | 16:04 |
| alf__ | kgunn: ok | 16:04 |
| alf__ | kgunn: it sounds like we need a script for this... update_mir_abi.sh :) | 16:05 |
| kgunn | alf__: i have one :) | 16:05 |
| kgunn | 2 secs | 16:05 |
| kgunn | alf__: https://pastebin.canonical.com/112279/ | 16:06 |
| kgunn | doesn't address the debian/changelog obviously | 16:07 |
| alf__ | kgunn: excellent, thanks | 16:08 |
| alf__ | kgunn: camako: Should I also update the minor version number 0.3.0 -> 0.4.0? | 16:12 |
| kgunn | alf__: looks like if you need an updated u-s-c branch...you'll need to create one... | 16:12 |
| kgunn | something like ~mir-team/unity-system-compositor/devel-mir-next would be handy | 16:13 |
| kgunn | then we can make it a semi-permanent vehicle | 16:13 |
| Nothing_Much | I think there's a problem with the lock screen with XMir | 16:14 |
| Nothing_Much | As in | 16:14 |
| Nothing_Much | It logs out instead of locks | 16:14 |
| alf__ | kgunn: camako: why not unity-system-compositor/development-branch so that we are consistent in all projects? | 16:14 |
| kgunn | alf__: only because its not really a "devel only"...its "devel for mir server abi breaks" :) | 16:15 |
| kgunn | and i have an outstanding action to go rename those others | 16:16 |
| kgunn | unity-mir/devel-mir-next, papi/devel-mir-next | 16:16 |
| kgunn | this way people can continue with trunk landings not having to "wait" on mir | 16:16 |
| alf__ | kgunn: OK. Is the policy to bump dependencies in all rdeps or only those that really need it? | 16:16 |
| kgunn | alf__: really only those that need it.... by that i assume you mean like, xmir uses client only..so this is a no hit to xmir | 16:19 |
| alf__ | kgunn: created usc/devel-mir-next | 16:19 |
| kgunn | awesome | 16:20 |
| greyback | +1 on the branch renames | 16:20 |
| kdub_ | so the policy is to scan papi, usc, unity-mir, powerd, qtsg stuff, etc for abi breaks and update them? | 16:21 |
| alf__ | kgunn: hmm, should devel-mir-next be based off each project's development-branch or each trunk? | 16:22 |
| kgunn | alf__: you can base it off of trunk...the way i have the recipe set up it will merge trunk before building | 16:24 |
| kgunn | so you keep getting the goodness of other landings | 16:24 |
| kgunn | if it fails, we get a mail | 16:24 |
| kgunn | (or we should) | 16:24 |
| kgunn | only thing is it does require merging trunk before going for a landing of the whole nut (which is what cemil or i would do) | 16:25 |
| kgunn | hopefully we keep rolling fast enough | 16:25 |
| kgunn | alf__: that its not too much headache.... | 16:25 |
| kgunn | headache only really comes when we "wait" for releases | 16:25 |
| alf__ | kgunn: camako: I am confused about the flow... when we break ABI we should propose a dependency bump MP against each affected project's devel-mir-next? | 16:26 |
| * kdub_ is too | 16:26 | |
| alf__ | kgunn: camako: and then what happens? | 16:26 |
| kgunn | alf__: so if its strictly an abi break...that mp just sits there until its landed | 16:27 |
| kgunn | alf__: so, after you do this... camako will collect those 3 rdep branches (which bump debian dep on mir) | 16:28 |
| kgunn | along with the mir-devel branched to 0.4.0...and attempt to land it | 16:28 |
| kgunn | alf__: kdub_ is it still confusing ? | 16:28 |
| kdub_ | I have some misgivings about this approach | 16:29 |
| alf__ | kgunn: so the MP against devel-mir-next should also contain fixes for any code broken by Mir changes? | 16:29 |
| kgunn | don't we all | 16:29 |
| kdub_ | like, if we do something that changes api, it might require significant changes to the downstreams | 16:29 |
| kdub_ | and we'd go stepping on the downstreams toes potentially in fixing the solution | 16:29 |
| kgunn | alf__: yes... so if you break api you should have _more_ than just a debian/dep bump on mir...you would have acutal code changes cooresponding to the mir api that you changed | 16:30 |
| kgunn | kdub_: this is why google hangouts/irc/launchpad were create :P | 16:30 |
| kgunn | anyone who's breaking _api_ (not abi) should have a reason, and they should work with the rdeps owners as to why... | 16:31 |
| kdub_ | kgunn, sure, but we don't know who's responsibility it is to fix the downstreams in the case of a larger change | 16:31 |
| kgunn | but...abi's are less disruptive in that regard | 16:31 |
| alf__ | kgunn: will other projects continue to develop in a development-branch or move back to trunk? | 16:31 |
| alf__ | kgunn: (I mean mir rdep projects) | 16:32 |
| kgunn | kdub_: name a downstream please ? | 16:32 |
| kdub_ | like, usc | 16:32 |
| kgunn | kdub_: u-s-c alberto or mterry | 16:32 |
| kdub_ | sure, I know who to talk to for the projects, roughly | 16:33 |
| kdub_ | or at least the irc channels to bother people on | 16:33 |
| kgunn | kdub_: any mp must be reviewed and approved...so even if you tried to take a stab at it, you wouldn't get through until someone approved | 16:33 |
| alf__ | kgunn: will other mir rdep downstreams continue to develop in a development-branch or move back to trunk? | 16:34 |
| kgunn | alf__: tldr version of events, i couldn't get papi to agree to work in a dev mode...so they are on trunk...they told me to create a mir-next branch to stage | 16:34 |
| alf__ | kgunn: ok | 16:35 |
| alf__ | kgunn: thanks | 16:35 |
| kgunn | so if you do that with 1 you do it with all | 16:35 |
| kdub_ | kgunn, sure, but like from an actual 'getting that approval' standpoint, its sometimes tricky to jump into a downstream project and comply with all the team-rules and understand the scope of the project that they're trying to solve | 16:36 |
| kdub_ | I'm not saying that I can't do it, it just seems like a recipe for headaches for the mir team coders | 16:36 |
| kdub_ | and headaches == regressions or long roundabout reviews | 16:37 |
| kgunn | kdub_: think of it this way wrt dealing with "downstreams"...what do you do when android changes? | 16:37 |
| kgunn | you update | 16:37 |
| alf__ | kgunn: One potential problem is that by the time we try to merge devel-mir-next (which is when we try release if I understood correctly) 1. our patches may be out of sync 2. They will not have been tested | 16:37 |
| kdub_ | kgunn, right, i'm the downstream... in this scenario, the upstream goes to all the downstreams and updates | 16:37 |
| kdub_ | so the analogy would be google coming in and updating mir for us when hwcomposer.h changes | 16:38 |
| kgunn | alf__: 1) & 2) are solved by the ci-train process locking the project | 16:38 |
| alf__ | kgunn: I am not sure, let's say I propose an MP with a bump and changes to USC. When will this be merged to trunk and tested? | 16:39 |
| kgunn | kdub_: if google proactively submitted an mp to your project before they released an api change...would that not be helpful to you ? | 16:39 |
| kgunn | camako: i am remembering now why i never asked anyone to do this and just did it | 16:39 |
| alf__ | kgunn: lol | 16:39 |
| kdub_ | kgunn, sure, it would be helpful for me in the analogy, but a moderately large burden for the upstream | 16:40 |
| kgunn | right...the idea is for it to be a pita | 16:41 |
| kgunn | in order to incentivize ourselves towards getting the server api under control | 16:41 |
| alf__ | kgunn: I think that will come naturally as we stop getting feature requests :) | 16:42 |
| kgunn | alf__: kdub_ note...i am not saying that _you_must_ make an MP with code changes for api changes.... | 16:43 |
| kgunn | however, you just need to make sure it does exist...no matter who does it | 16:43 |
| kgunn | right? | 16:43 |
| kgunn | i mean you can't release until that gets sorted | 16:43 |
| kgunn | and we want to build testable packages off our devel-branch... | 16:43 |
| kgunn | that's where this "need" comes from | 16:43 |
| kgunn | otherwise, you have a devel-branch you cannot system test | 16:44 |
| kdub_ | sure, I appreciate the need | 16:44 |
| kgunn | does that make sense ? | 16:44 |
| kdub_ | I'm just surprised that we're at 1.0 so suddenly I guess | 16:45 |
| kgunn | and hopefully you are working with _all_ the downstreams close enough that you can determine who is best to make a change (or at least get a spike in place) | 16:45 |
| kgunn | kdub_: ?...what do you mean ? | 16:46 |
| kdub_ | like, this approach limits the development of the server api/abi quite a bit in terms of time-to-land-a-change | 16:47 |
| kdub_ | which, given the projects, might just be appropriate | 16:47 |
| kgunn | kdub_: i would say this....for ABI...we break like every 3 days it feels...updating for it is like a couple of debian control file changes & a build | 16:48 |
| alf__ | kgunn: My concern is this: let's say that today I propose an MP against devel-mir-next for platform-api. Platform-api developers will continue working on trunk for a while (let's say a week) unaware of the changes. At the end of that week we decide it's time to release, so camako will try to merge platform-api/devel-mir-next into lp:platform-api, but lp:platform-api may have changed enough for the devel-mir-next changes to not apply. Have I mi | 16:48 |
| kgunn | for API....we actually don't change too much...maybe 1 or 2 times a month, | 16:48 |
| kgunn | and the updates for those, really havne't been much | 16:49 |
| kgunn | b/c 9 times outta 10, its the downstream asking for it | 16:49 |
| kgunn | so...while this is all interesting irc discussion, the reality hasn't mete out that its headache/hard etc...all we're trying to solve is being able to get features from mir-devel into hands of other developers sooner than the monkey-race that is landing in trunk | 16:50 |
| kdub_ | kgunn, I agree about the frequency of the abi/api stuff | 16:51 |
| kgunn | alf__: sure...might happen, conflicts...resolve the conflicts, go for landing done | 16:51 |
| kdub_ | but am still concerned that we're just benefiting from a big chunk of our 'public' api going unused | 16:51 |
| kgunn | kdub_: benefiting how ? | 16:52 |
| kgunn | oh you mean...we have only a couple of shells | 16:53 |
| kgunn | so server api hasn't seen every single thing someone might ask for ? | 16:53 |
| Nothing_Much | Is there a bug with XMir that causes a crash when I lock the screen? | 16:53 |
| kdub_ | like, if we add a function to Scene, its just a simple pass-through function that we have to usc to get the wrapper class to compile | 16:53 |
| kdub_ | but then, say usc starts to use that function somehow | 16:54 |
| kgunn | Nothing_Much: sorry, i couldn't tell you | 16:54 |
| kgunn | kdub_: ok...i'm tracking... | 16:54 |
| kdub_ | and then the kicker (in terms of headache-time) is that we figure out that this added function is a strange function for an interface | 16:55 |
| kdub_ | and we have to reshuffle the usc code that we're somewhat unfamiliar with the requirements | 16:55 |
| kdub_ | the summary is I guess, it'll drive more feature-branch style development in mir | 16:56 |
| kdub_ | which... might not be that bad of a thing | 16:56 |
| kdub_ | because if I'm driving at a new feature or a 'structural bugfix' that requires dabbling in the public headers, we shouldn't be releasing those intermediate steps publically | 16:57 |
| kgunn | kdub_: right, so you say ...hey, i hate that method...change it....compile usc, it won't...uh-oh, i have to talk to somone/proposeMP/not change it | 16:58 |
| kdub_ | right, which is okay because if they're using it, they have some requirement that needs satisfying | 16:58 |
| kgunn | _exactly_ | 16:58 |
| kgunn | there's a reason behind everything.... | 16:59 |
| kdub_ | but in terms of landing things in mir, development happens in 1000 line chunks to devel these days | 16:59 |
| kgunn | reason behind you trying to change it...and a reason they're using it.... | 16:59 |
| kgunn | kdub_: are all 1000 lines in include/ ? | 16:59 |
| kgunn | :) | 16:59 |
| kgunn | typically not | 16:59 |
| kdub_ | no, 2 lines in include, and other stuff | 16:59 |
| kdub_ | but in terms of the mir team and reviewing, if its more than 1000-1800 lines, it lingers in review | 17:00 |
| kgunn | right...i guess i'm kind of sitting here thinking, i've been doing exactly what we're talking about for last ~1.5 yrs | 17:00 |
| kgunn | and hadn't seen any real issue... | 17:00 |
| kgunn | sure it takes a day or 2 every now and then to sort a bigger change...but mostly | 17:00 |
| kgunn | its really simple | 17:00 |
| kgunn | kdub_: if its in review...and not landed on devel...then devel still builds for the downstreams | 17:01 |
| kgunn | see what i mean | 17:01 |
| kdub_ | kgunn, sure, I do | 17:01 |
| kgunn | think of it as 1000 line mp...you're now adding a few pre-req branches & few more loc changes to make it all happy from a build perspective | 17:01 |
| * kgunn notes this irc chat probably took more time than most abi bump cycles :D | 17:02 | |
| kdub_ | kgunn, right, I mean, I think we're on the same page that we have to be more conscious of having the downstreams compile | 17:02 |
| * alan_g is about to go but noticed chat for the 1st time. The main thing that would be nice is a CI that says "if this lands on devel then usc breaks". | 17:03 | |
| racarr_ | +1 | 17:03 |
| kgunn | ++ | 17:03 |
| alan_g | I've set these things up in the past. It isn't hard. | 17:04 |
| kgunn | alan_g: alberto_ pointed out a tool y'day...i think kdub_ even toyed with it ? | 17:04 |
| === alan_g is now known as alan_g|EOD | ||
| * kdub_ feels 'violent agreement' feelings | 17:04 | |
| racarr_ | Really? I just feel food poisioning sort of feelings. | 17:07 |
| racarr_ | :p | 17:08 |
| racarr_ | <- Mildly sick. | 17:08 |
| kdub_ | hah, my suggestion I guess is that we have to shift the status quo for how we review things, and the branching strategies while we're coding | 17:08 |
| alberto_ | abi-compliance-checker it's already a debian package you can install with apt-get | 17:09 |
| kdub_ | and... also improve the tooling so that we know when we're breaking things | 17:09 |
| alberto_ | I haven't tried to use it yet | 17:09 |
| alberto_ | but from what I read it basically does what we want | 17:10 |
| alberto_ | it generates abi and api information for a release | 17:10 |
| kgunn | kdub_: right...i don't think camako (or i) are asking for the world...just at least a check from every engineer "did i break abi"...we'll catch it on promotion to trunk , but engineers addressing it | 17:10 |
| alberto_ | and you can then compare against another release version | 17:10 |
| kgunn | when they do it, would go a long way to helping to keep ppa's building, other teams using mir-devel when they need to | 17:10 |
| kgunn | e.g. trusted session was a good example | 17:10 |
| kdub_ | kgunn, right, I mean, I agree that we have to have to have the stack buildable without jumping through a lot of hoops or having to learn a lot of internals | 17:11 |
| * kdub_ has been whining about that for a long time :) | 17:11 | |
| kgunn | help me help you :) | 17:11 |
| alberto_ | I was in my TODO list to try that tool...but the powerd/usc stuff keeps being a timesink hole | 17:12 |
| kdub_ | kgunn, I'm just trying to come to terms with 'diff size' vs 'get the stack to compile' in terms of like, actually working on the mir code | 17:13 |
| kdub_ | and the suggestion is to review things as feature branches | 17:13 |
| kdub_ | and once the line of work is done, get the completed feature branch out to devel along with all the 'get the stack to compile' stuff | 17:14 |
| kgunn | kdub_: it can be 2 diff steps | 17:18 |
| kgunn | kdub_: problem is in the past...we've broken abi, and let it sit | 17:19 |
| kdub_ | right, I'm on the same page with that being very bad for a lot of reasons :) | 17:20 |
| alberto_ | there seems to be 2 issues here | 17:20 |
| dandrader | kgunn, anpok, alan_g|EOD - the fallback approach is ready https://code.launchpad.net/~dandrader/mir/expose-android-input/+merge/224335 | 17:20 |
| alberto_ | one is the abi in mir should be bumped with the MR/MP that breaks it | 17:20 |
| kgunn | alberto_: eh..i could live with, bumping right after | 17:20 |
| alberto_ | the other is once we break the abi/api in mir - who is reponsible for making changes | 17:20 |
| alberto_ | to the other immediate dependencies | 17:21 |
| alberto_ | umir/usc/papi | 17:21 |
| alberto_ | I think that's one reason why asac wants all those in the same repo | 17:21 |
| dandrader | racarr_, https://code.launchpad.net/~dandrader/mir/expose-android-input/+merge/224335 | 17:21 |
| kgunn | alberto_: in my mind, answer to who is only relevant for api... and usually the rdep owner b/c most of the time they're asking for it | 17:22 |
| alberto_ | kgunn: right sorry api breaks | 17:22 |
| alberto_ | abi is just rebuilds | 17:22 |
| kgunn | in case where they didn't, i'd like to see people at least provide an mp and then pick up the phone and work with the owner | 17:22 |
| kgunn | but...i can live with just "owning" making sure something gets changed soon to "make the stack workie" | 17:23 |
| kgunn | dandrader: thanks | 17:23 |
| kgunn | ok, lunch.... | 17:23 |
| kdub_ | right, we all agree that we need a buildable/releasable stack people can go to | 17:23 |
| kdub_ | I'm still just chewing on how to best do that within the mir team, because there's pressure to have small diffs for review, and pressure to have everything tested with decent public headers in devel | 17:25 |
| kdub_ | If we bump api, we need to review the c++ interfaces on the server as closely as if we break the c client api | 17:26 |
| kdub_ | and a review that says 'this interface has some smell to it' tends to snowball a 1000 line review to a 4000 line review | 17:26 |
| racarr_ | dandrader: :D will review after I finish implementing this strange new class in Ozone. | 17:28 |
| === dandrader is now known as dandrader|lunch | ||
| kgunn | racarr_: strange ? | 17:53 |
| racarr_ | strange? | 17:53 |
| racarr_ | Oh | 17:53 |
| racarr_ | Yeah its just....they have a new refactoring | 17:54 |
| racarr_ | in which um...something called a window creates something called a surface lol | 17:55 |
| racarr_ | which isn't really even wayland terminology either | 17:55 |
| racarr_ | so I'm calling that a strange choice :p | 17:55 |
| racarr_ | Also I now have to implement a "SurfaceFactory" class which among other things is responsible for | 17:56 |
| racarr_ | dlsyming eglGetProcAddress | 17:56 |
| racarr_ | so I'm also gonna call thesurface factory "strange" | 17:57 |
| racarr_ | lol | 17:57 |
| kgunn | lol | 17:57 |
| racarr_ | Also there is this vsync provider whichI don't totally understand because wayland hasnt implemented it all yet but | 17:57 |
| racarr_ | it may expose an interesting sort of new mirclient requirement | 17:58 |
| racarr_ | it seems...to call this function at...some sort of interval (not yet clear to me) | 17:58 |
| racarr_ | and then it wants you to fill in a struct | 17:58 |
| racarr_ | with timing information about the last vsync/swap | 17:58 |
| kdub_ | racarr_, and who uses that? | 17:59 |
| racarr_ | That's whatI don't know yet :p | 17:59 |
| kdub_ | racarr_, sounds sort of android-ish | 17:59 |
| racarr_ | I mean, roughly it seems like its sent back to the host process | 17:59 |
| racarr_ | at which point they presumably do something clever with it | 17:59 |
| racarr_ | yeah | 17:59 |
| racarr_ | android has that last frame input | 17:59 |
| racarr_ | resampling | 18:00 |
| racarr_ | thingy | 18:00 |
| kdub_ | I think its used in android to sync input processing and frame timing | 18:00 |
| racarr_ | it could be something like that. | 18:00 |
| racarr_ | yeah | 18:00 |
| kdub_ | well, more like, 'when to best fire off new frames' as opposed to 'ensuring no tearing' | 18:00 |
| racarr_ | Yes | 18:00 |
| racarr_ | Anyway we may need to expose this frame timing somehow...because afaik I see now with them justcalling eglSwapBuffers there is no good way to get at it | 18:01 |
| kdub_ | racarr_, well, we can kick out the signal from the android platform, although I don't know if mesa can do that as easily | 18:02 |
| kdub_ | but also, I know that the android system can work off of a fake vsync signal, so that seems easier/more flexible for all platforms | 18:02 |
| kdub_ | like, query display, 'oh you're 120 hz? i'll make a 120hz heartbeat thread' | 18:02 |
| racarr_ | Hmm maybe...I think we should be able to get a better number on any platform though | 18:06 |
| racarr_ | not 100% sure but I think what you want this number to converge to is the time the buffer first appears on screen | 18:06 |
| kdub_ | yeah, we could at least sync to the last-known vsync | 18:06 |
| racarr_ | so if there is nothing better, at least the page flip | 18:06 |
| racarr_ | callback for mesa | 18:06 |
| racarr_ | is pretty good | 18:06 |
| racarr_ | yeah | 18:06 |
| kdub_ | ilke, if its within i dunno (guesstimate coming up) 10% of the phase of the actual vsync signal, its probably good enough | 18:07 |
| racarr_ | haha right. this is the part that I don't entirely understand...what that% is | 18:07 |
| racarr_ | I guess need to look at the details | 18:08 |
| racarr_ | of theinput resampling algorithm | 18:08 |
| racarr_ | and | 18:08 |
| racarr_ | potentially what chromium is doing | 18:08 |
| racarr_ | :( my laptop screen just shattered in perhaps the most spectacular fashion ive ever seen | 18:34 |
| racarr_ | also wifi broke and keyboard is failing lol | 18:41 |
| racarr_ | luckily emergency backup of chromium tree to nexus 7 succeeded. | 18:41 |
| === dandrader|lunch is now known as dandrader | ||
| === no_mu is now known as Nothing_Much | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| dandrader | what does mir_surface_state_restored mean? | 21:56 |
| racarr_ | dandrader: normal | 22:03 |
| racarr_ | lol | 22:03 |
| racarr_ | as opposed to maximized or minimized, etc | 22:03 |
| racarr_ | in particular, when you go from maximized/minimized, etc | 22:04 |
| racarr_ | your old "floating state" is"restored" | 22:04 |
| racarr_ | notthebest name | 22:04 |
| dandrader | racarr_, ah ok. | 22:04 |
| dandrader | racarr_, yeah, I would have understood normal | 22:04 |
| racarr_ | or floating even | 22:05 |
| dandrader | as well | 22:05 |
| racarr_ | theres an item somewhereto update themto the design language | 22:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!