[00:23] bregma: you around ? [00:23] bregma: I'm not sure what your view is on encoding Interface/Impl names, if you could clarify that would be great [00:30] Trevinho: ^ would be good to get your thoughts on that [00:30] I know that the style guide document says "use -Interface" but I also know that lots of people hate -Interface [00:31] smspillaz: I'm not sure I got what you mean... [00:32] Trevinho: do you prefer interface classes to be named FooInterface or Foo [00:33] and is that the general preference [00:33] Ah... I'd prefer FooInterface... or AbstractInterface if that's the case [00:33] sorry [00:33] AstractFoo [00:33] Trevinho: AbstractFoo ? [00:33] okay :) [00:34] yeah, sorry :P [00:34] I prefer Foo as the interface and use the bridge pattern [00:34] no problem, was just looking for what people preferred [00:34] bregma: okay, so whats the verdict :) [00:34] bregma: Foo/FooImpl or AbstractFoo/Foo ? [00:35] (one of the things I don't like about code review is that reviewers almost always disagree on style :)) [00:36] I don't like having structure creep into names in APIs, so I dislike Abstract, and Impl implies a private implementation behind the interface so it should never leak out [00:36] so I prefer Foo/Foo::Impl [00:38] bregma: Trevinho: what's the verdict then, and can we get this written down somewhere ? [00:38] yes, I'd like to get it written down [00:39] smspillaz: we have the style docs... they probably should be updated with these things too [00:39] bregma: btw, when you say Foo::Impl, do you mean a subclass? eg, Foo::Impl ? [00:39] erm, class Foo::Impl [00:39] yes, a nested class [00:39] using the pimpl idom [00:39] bregma: well, it wouldn't quite be nested [00:40] erm , a pimpl [00:40] bregma: but if you mean something like having the interface class with a static factory method which returns Foo::Impl through its interface then I guess that's okay [00:41] is the goal not to separate interface from implementation, to allow the implementations and interfaces to vary independently (ie. a Nux implementation, a mock interface)? [00:41] bregma: yes, Extract Interface [00:45] I think the best approach is to use the pimpl idiom (the bridge pattern) and have the interface class constructor take a factory function that defaults to creating the usual Nux-based implementation [00:45] a factory function that creates a mock implemntation can be used for the tests [00:46] bregma: that's not a pattern I've seen before, but its somewhat workable (although I'm a bit skeptical of interfaces having constructors) [00:47] I would really like to see as much nux as possible hidden behind facades [00:47] bregma: actually that could get a little awkward [00:48] if you wanted to create a MockFoo on the stack, that inherited from foo, you'd have to provide a "constructor" which returns a reference to the same thing in order to satisfy the interface constructor [00:48] erm, a "factory function" [00:49] bregma: do you want me to provide a sample of what I'm thinking of so I know we're both on the same page ? [00:49] it could be a little awkward if it goes too far, but right now it makes testing and maintenance harder because it's almost impossible to reason about functionality when a class has a 10-level inheritance heirarchy, ober 100 member functions, and 50 public member variables [00:50] bregma: I know :) [00:50] bregma: what I'm suggesting is that your method of having the interface class take a factory function is the awkward part [00:50] not the interface itself [00:51] I disagree, I've used that design before without problems [00:51] just not with nux and properties and introspection [00:51] bregma: hmm, okay. I'll just hack something together to see if we're both on the same page here [00:52] I've been playing wit hthe Switcher classes for the last few days for #824965, before I looked at your MP [00:52] smspillaz, hey, when you get a chance, can you take a look at this: https://code.launchpad.net/~brandontschaefer/compiz/lp.1002246-check-valid-strut-windows/+merge/140569 [00:52] bschaefer: sure [00:53] so I'm pretty certain we have the same goals [00:53] bregma: ah, hence the review :) [00:53] smspillaz, thanks, im not sure how I feel about it but its a tough problem to fix [00:53] bschaefer: actually, what was the problem with using ~PlaceWindow ? [00:53] smspillaz, the ~PlaceWindow gets called after the DestoryNotify event [00:54] bschaefer: yep, its supposed to [00:54] which the problem is the DestroyNotfiy is coming into compiz to later [00:54] to late* [00:54] does it come after the countdown timer ? [00:54] smspillaz, the review was actually because I'm trying to get through the backlog of MPs, it's just a coincidence [00:54] bregma: :) [00:54] bregma: great to see you're doing that [00:54] smspillaz, the count down is super late (The Fallback one) [00:55] smspillaz, which happens after everything [00:55] bschaefer: have you tried bumping up the timer ? [00:55] oh [00:55] hmm no I have not [00:55] well in that case it shouldn't be a problem [00:55] as long as we only ever hit the doHandleScreenSizeChangeFallback code after we get the DestroyNotify for the unity windows [00:55] I mean what should happen is this: [00:56] yeah that is what happens, the fall back is way after the DestroyNotify [00:56] the problem is we collect these windows, then we destroy the window, leaving the destroyed windows in the list [00:56] but the destoryed windows are still valid to compiz, but not the xserver [00:57] until the DestroyNotify comes through [00:57] ConfigureNotify on root window -> Place::handleScreenSizeChange -> strut windows collected -> Unity::handleScreenSizeChange -> unity struts destroyed -> Nondestroyed struts send a PropertyNotify (remove them from list) -> Destroyed struts send a DestroyNotify (-> ~PlaceWindow -> remove from list) -> mStrutWindows should now be zero, call doHandleScreenSizeChange [00:58] bschaefer: right, what I'm trying to say is that you can remove the windows from mStrutWindows and call if (mStrutWindows.empty()) doHandlescreenSizeChange () from within ~PlaceWindow [00:58] PlaceWindow has a private member variable "window", and you just call mStrutWindows.remove (window) [00:59] i tried that and .... hmm [00:59] now im wondering why it didn't work [00:59] The only reason I can see it not working is if the non-destroyed strut windows don't update their struts [01:00] in which case we just do the fallback anyways [01:00] thats what happens, it is destroyed, but compiz holds the struts still, so to compiz the struts are still valid [01:00] however if the DestroyNotify comes before the fallback, then there's really no problem [01:00] until the the destroy [01:00] bschaefer: ah [01:00] I even tried updateStruts() [01:00] but that didn't seem to work either which was odd [01:01] right it will just error out [01:01] yu[ [01:01] .. I think [01:01] well [01:01] actually [01:01] it should set it to false if hasNew is false [01:01] * bschaefer has to double check [01:01] its a huge function [01:02] bschaefer: src/window.cpp: after the second XGetWindowProperty [01:02] add an else block after that first if () check [01:02] that sets hasNew to true [01:03] smspillaz, well I would still have to update the list...but instead of doing XGetGeometry [01:03] if both properties fail to be read then we should assume that the window has no struts [01:03] do update struts on each one [01:03] bschaefer: okay, so two things [01:03] smspillaz, is it setting it to false? [01:03] bschaefer: yes [01:03] o there it is [01:03] bschaefer: so first you need to update the list on ~PlaceWindow [01:03] alright [01:03] and second you need to call w->updateStruts () before updating the list [01:03] with that small fix applied [01:04] smspillaz, the small fix being the w->updateStruts call? [01:04] the small fix being the hasNew = false [01:04] after [01:04] * bschaefer still needs to change the indention for reading compiz files [01:05] http://paste.ubuntu.com/1448984/ [01:05] it should be getting set to false on line 974 [01:06] oo right [01:06] bschaefer: use qtcreator and go into tool -> editor settings -> c++, change "always use spaces" to off, change "indent width" to 4 and "tab width" to 8 [01:06] quickest way to get compiz style [01:06] I use vim, and I have the compiz stuff commented out [01:06] i've just been to lazy to go edit that haha [01:07] smspillaz, hmm wont it still be false if this fails though? if (result == Success && data) [01:08] overall it says if (!hasNew) [01:08] so its false coming into this function [01:08] or cond sorry [01:08] yes, it is [01:08] so the way that function works [01:08] is that it checks _NET_WM_STRUT_PARTIAL [01:08] and then if that fails it goes to _NET_WM_STRUT [01:08] if either one succeeds, it sets the new strut values [01:09] both calls to XGetWindowProperty are going to fail because the window does not exist [01:09] so, in that case, we should reset its struts back to zero [01:09] hence the hasNew = true [01:09] yes, so result should not == Succes though [01:09] correct [01:09] but isn't it already false? [01:09] result ? [01:09] or hasNew ? [01:10] result = XGetWindowProperty (screen->dpy (), priv->id, [01:10] will get result != false [01:10] i mean [01:10] result will not equal success, but hasNew at this point is already fase [01:10] false [01:10] yes [01:10] f (!hasNew) [01:10] and you want to se it to true [01:10] ooooo [01:10] sorry, I typoed it in my pastebin [01:10] that is what I got confused about :) [01:11] http://paste.ubuntu.com/1448991/ [01:12] smspillaz, hmm but don't we want line 1145 to be ran? [01:12] priv->struts = NULL; [01:13] smspillaz, ill play around with it, thanks! [01:14] hmm [01:14] okay, actually I'm wrong [01:15] bschaefer: check that in its current implementation, priv->struts is indeed set to NULL when you call updateStruts [01:15] it seems we need this to be true: hasOld != hasNew || [01:16] that should be the only thing that matters [01:16] smspillaz, alright, ill check that because I tried this twice and it seemed to work when I was doing XGetProperty, but when I removed that it seemed to fail to set it to false [01:16] * bschaefer might have been forgetting to flush X [01:16] then on ~PlaceWindow you can do (window->updateStruts (); mStrutWindows.remove(window); if (mStrutWindow.empty ()) doHandleScreenSizeChange ()); [01:16] bschaefer: XGetWindowProperty is a sychronous operation there's no need [01:17] gotta run bbl [01:17] smspillaz, alright, thanks a lot! [01:17] (i meant that XGetWindowProperty() was causing things to be flush, ie. why updateStruts() worked when that was there) [01:17] * bschaefer is most likely wrong [01:18] XGetWindowProperty calls _XReply which is an implicit flush-and-sync [01:19] o cool, good to know [01:22] bregma: yeah, no so sure about the default constructor. Here is what I think you're talking about [01:22] bregma: http://paste.ubuntu.com/1449009/ [01:23] Foo.h has a depedency on FooImplFactory.h [01:23] not really sure you want that [01:23] bbl [01:25] bregma: if I'm wrong, can you paste an example of what you're talking about ? [01:36] well awesome, that worked....I must have been doing something horribly wrong haha [02:08] smspillaz, I'm in and out, I'll try to post what I mean in a bit [02:42] bschaefer: :) [02:42] bregma: okay, no problem. I'll split up the proposals now while I'm waiting [04:20] smspillaz, http://paste.ubuntu.com/1449232/ -- an example taken from another project with some global substitution of class names for clarity [04:20] not in Unity code style [04:21] bregma: thanks, I'll take a look [04:22] I have no idea if it's clear or not, but it compiles and runs [04:22] bregma: ah right [04:22] bregma: see my issue there is that you've got a dependency on Controller::Impl within Controller [04:23] this looks more like the pimpl idiom than it does the bridge pattern [04:24] the pimpl idiom _is_ the bridge pattern [04:25] bregma: well, in this implementation it is, yes [04:26] bregma: it is clever though, no virtual functions in the interface [04:26] virtual functions in the interface cause Fragile Base Class syndrome [04:26] agreed [04:26] bregma: I wanted to do something like this for compiz in fact :) [04:27] bregma: that being said, the controller interface is internal. I'm not too worried about ABI stability there [04:27] true, force of habit doing years of library API development on my part [04:28] bregma: its a good habit [04:28] bregma: anyways. I can do it like this if you want [04:28] it would be quite different to most of the code in unity though [04:28] but simple, solid interfaces make testing easier and reasoning about the code easier [04:28] and we can modify the other faces gradually as we do other things [04:29] I agree [04:29] testing will be a bit more awkward though [04:29] you'll have something like this: [04:29] bregma: actually hmm [04:30] bregma: see the thing with testing and google mock generally is that we need to have access to the underlying MockFoo in order to set expectations on it [04:30] yes, which means the Impl will have to be a mock object [04:30] right, but I need to have access to it [04:31] which means either adding a getter to Controller to get a MockImpl (not gonna happen) or having this awkward "CreateImplFunction" which just returns a reference to the existing mock object [04:31] so you'd have something like (just thinking aloud) [04:31] MockFoo::Ptr p (new MockFoo); [04:32] Controller::CreateImplFunction f ([&]{ return p; }) [04:32] Controller c (x, y, f); [04:32] would that make sense ? [04:33] why not just Controller c(x, y, [](){return Ptr(new MockImpl); }); ? [04:33] oh, wait [04:33] bregma: because I need to have access to the actual MockImpl [04:33] yeah, I just realized [04:33] unless you want to make an interface for MockImpl [04:33] ;-) [04:33] An interface for your interface! [04:34] bregma: btw, some people don't like NVI, prepare for some disagreement on reviews :) [04:34] no no, the Ptr type is a unique_ptr, you can use a unique_ptr on a stack-based object [04:34] or it might just be the NV/P/I strain of NVI [04:35] I'm not so worried about reviews, I have a big club I can weild if I have to [04:35] bregma: you can use unique_ptr on the stack ? [04:35] wouldn't that mean that CreateImplFunction would have to return a const unique_ptr & > [04:35] ? [04:35] yes, the defaulted second argument is the deleter object, which can just do nothing [04:36] (since unique_ptr is noncopyable iirc) [04:36] or rather, it sets the old one to NULL [04:36] which isn't really what you want [04:36] impl would have to be shared [04:37] it's better if it's unique and a special deleter is used for mock impls [04:37] "there can be only one" [04:37] bregma: yeah, just the issue is this: [04:37] unique_ptr mock (new MockImpl) [04:38] controller (x, y, [&](){ return mock; } -> Impl::Ptr &) [04:38] now mock is NULL [04:38] (I'm sure that lambda syntax was not correct, just ignore it :)) [04:40] bregma: so can I make it shared ? [04:41] unique_ptr only runs the deleter on the underlying pointer, it does not null it out, that's why you need to supply a null deleter [04:41] I'm trying to find an example [04:43] this one has an example: http://stackoverflow.com/questions/8274451/well-how-does-the-custom-deleter-of-stdunique-ptr-work [04:43] bregma: ah, thanks. TIL [04:44] I expect to see some hairy stuff from people like Alexandrescu when more people start experimenting with std::unique_ptr [04:45] bregma: sadly there is no "one true style" for C++ [04:45] its all "my opinion is that" [04:46] bregma: BTW, do you mind if I rename SwitcherView to View? [04:46] I'll call the default implementation NuxView [04:46] they both sit in unity::switcher [04:46] it would be more consistent with switcher::controller [04:47] :) [04:47] bregma: BTW, I hope I don't come across as argumentative. I was just trying to work through the thought process. Thanks for the advice :) [04:48] no problem, I've been ruminating on this for a while so it's good to hash it out [04:48] :) [04:49] it's nice to do something non-administrative, too... too much management, not enough programming these days [04:49] why is that a common theme? [04:49] bregma: you know its awesome, since I've left, I can actually be productive now [04:50] the great irony of employment [04:51] yeah, like the irony or working from home: less time commuting but much much more time working [04:51] in fact, it's nearly midnight here and I have to get up in a few hours to start my day [04:51] bregma: I always thought this would happen: http://theoatmeal.com/comics/working_home [04:52] bregma: heh, get some sleep maybe. I figured it was late. Nice talking :) [04:53] heh, comic nailed it [04:54] I love the oatmeal. Frank and to the point === bregma is now known as bregma|away [05:16] Hello, does anyone know how to reset keyboard shortcuts back to default?? [07:39] hmm [07:39] bschaefer: you around ? [07:40] smspillaz, ish, whats up? [07:40] bschaefer: can you check if the standalone switcher crashes on startup for you? [07:40] smspillaz, sure [07:40] I'm doing some refactoring and its crashhing in an odd place that I haven't touched but I don't want to recompile all of unity [07:41] hmm nope doesn't seem to seg fault for me [07:41] okay, thanks, I'll keep looking into this [07:41] though its a bit odd...good luck! [07:41] I should head off to bed... [07:49] ah, FFS [07:49] you have to install it to run the examples [10:43] According to X11 specification XGrabKeyboard() should grab all keyboard events exclusively to my client, but its not the case for Super_L (windows key), Alt, which trigger Unity shortcuts [10:43] any ideas why Unity doesn't respect GrabKeyboard ? === _salem is now known as salem_ === bregma|away is now known as bregma [12:23] gatis: I think GrabKeyboard does not override passive grabs [12:23] smspillaz: i found this https://bugs.launchpad.net/unity-2d/+bug/964414 [12:24] Launchpad bug 950160 in OEM Priority Project precise "duplicate for #964414 Unity blocks other programs from binding globally to Super+* (* = any key)" [Critical,In progress] [12:24] i think that the culprit [12:24] yeah if I remember correctly that was a lot more complicated than it seemed [12:27] gatis: are you running precise or quantal ? [12:27] I thought that thing got finally resolved? [12:28] This bug I mean [12:28] "resolved" [12:28] if I remember correclty we added a workaround to not use the tap detection code on the super key [12:29] smspillaz: precise [12:29] gatis: yeah I dunno if we ever backported it [12:30] ah, then i will need to install quantal one day to verify [12:35] hm, I think we had packages prepared for precise [12:36] But indeed those never got released I think [12:36] Since we were working on packaging the workaround on UDS [12:51] the fix is only in raring because there is a side-effect being investigated by brandon (dash pops up when display is switched) [12:52] if that can be tackled and also that fix backported, then we could finally move forward to releasing the fixes in 12.10 & 12.04. but it seems complicated. [12:53] btw, I now summarized the Compiz unredirection status at http://losca.blogspot.fi/2012/12/compiz-fullscreen-unredirection-update.html [12:56] Mirv: what graphics hardware are you running ? [13:01] smspillaz: depends on machine... sandybridge quantal, radeon precise machines for example [13:02] smspillaz: if you refer to the display switch / dash pop up, that happens with the hardware key of at least dell xps 13 which is wired to output super+p [13:25] Mirv: I was wondering if you had any machines with nvidia cards [13:25] need testers for the buffer_age stuff [13:25] though I guess it just generally needs testing [13:29] smspillaz: sil2100 now has one, running precise though [13:29] * sil2100 has one [13:29] ah [13:29] It's an old machine though [13:30] And it has precise only [13:30] sil2100: <8300GT ? [13:33] smspillaz: yes, 7400Go if I remember correctly [13:33] sil2100: yeah, they've moved it to -legacy now [13:36] Poor old laptop... :( [13:39] sil2100: I couldn't get the newer version of osx my my desktop machine too (2006 iMac) [13:54] smspillaz, i have one running raring [13:55] smspillaz, GTX 460 if that's any use [13:59] popey: go test ppa:smspillaz/compiz-experimental and file bugs/oddities/whatever with the compiz-experimental-ppa :) [13:59] performance improvements inbound [13:59] (with the compiz-experimental-ppa tag) [13:59] I accidentally a word [14:09] smspillaz, ok [14:12] popey: :) [14:12] smspillaz, anything in particular I should be looking for? [14:12] flickery things [14:13] roger [14:13] its basically a combination of recycling backbuffers (drawing less stuff) partial updates in nux (drawing less stuff) [14:14] any time you get (drawing less stuff) wrong it usually means flickering, bleeding or trails [14:14] popey: the ones I know about are a crash on dragging launcher icons, and flickering when using the workspace switcher [14:24] smspillaz, package in your ppa wants to remove loads of stuff [14:25] smspillaz, paste.ubuntu.com/1450079 [14:31] popey: great, I guess I'll have to refresh the version numbers [14:31] I hate debian packages [14:31] :) [14:31] let me go on the record as saying: debian is the worst distribution ever. [14:31] * smspillaz quickly vacates the room [14:32] /kickban smspillaz [14:33] popey: hmm, I don't really care about the fact that its removing unity-2d ... 1) do you have the staging ppa enabled? 2) could you grab me the output of apt-cache policy unity ? [14:33] popey: okay, so debian is the worst distribution I've ever used BUT [14:33] i have the daily desktop ppa enabled [14:33] i can remove it [14:33] revert to stock [14:33] I've only ever used debian based distros so [14:33] XD [14:33] popey: this one at least depends on ppa:unity-team/staging [14:34] oh, ick [14:34] meh, my system is now in a mess [14:35] its not in a mess until it doesn't boot [14:35] even then its not /really/ in a mess until your kernel image is corrupt and you don't have any other kernel images [14:35] then you're screwed [14:36] * smspillaz has recovered a system from kernel and init=/bin/bash before, not fun [14:38] yeah, need to fiddle a bit [15:13] mterry: ready for your review: https://code.launchpad.net/~3v1n0/bamf/soname-up/+merge/140695 ;) [15:14] trevinho, thanks! [15:41] mterry: I've updated it to 4, since it was never done before... And I'd like to keep it synced with major version... But if that's something too big, I'll move to just 1.0.0... [15:41] synced with major version? [15:42] oh is the version 4.x.x for bamf in general? [15:42] mterry: yes [15:42] Trevinho, well I guess the next question is when do you bump major versions? :) Since it doesn't seem to have been based on SONAMEs before [15:42] Trevinho, so you might get in this same situation again of mismatched version/SONAME [15:43] Trevinho, but regardless, there's no problem with bumping up to 4, I was just curious, and wanted to forstall confusion about the 3 in the libbamf3-0 name [15:43] forestall even [15:43] mterry: yes, that's a possibility I tought... I don't know which is the best approach... for unity (and libunitycore) for example.. we used to bump the soname at every new major version... And that's something we could do here too... [15:44] that's just broken [15:44] mterry: that name was added because of the gtk3/gtk2 thing (that was wrong, since libbamf never depended on gtk) [15:44] mterry: I wanted to change that too... but I asked to didier and he preferred to stay with it [15:45] Trevinho, yeah, now that the 3 is there... I'd just as soon keep it too [15:45] Trevinho, and bumping SONAME when we don't need to is bad. I'd just say keep it de-coupled from major version number to resist the urge to bump it unnecessarily [15:45] Trevinho, speaking of unnecessary... why did we remove the API again? :) [15:46] Trevinho, one could always just make the API a no-op... [15:46] mterry: these apis were totally unneeded... [15:47] Trevinho, sure... But everytime a SONAME is bumped, a kitten dies is all I'm saying :) [15:47] mterry: mh... I wanted to cleanup things that we have in and that were not needed anymore [15:48] mterry: mh, I know... But we have to at some time [15:48] Trevinho, I'm just being a punk. Anyway. I'd say go with 1 for SONAME and update the package names [15:48] ok [15:48] Trevinho, are there any other API cleanups you want to squeeze in while we're bumping anyway? [15:50] mterry: mhmh... probably few additions, but not removal... Even if there's an ABI change in progress by andyrock (not sure because he probably could just use the padding space we have in structs) [15:52] mterry: question: why the gir packaging is currently disabled for bamf? [15:52] Trevinho, mterry https://code.launchpad.net/~andyrock/bamf/bamf-window-tab-mockable/+merge/140704 [15:53] andyrock: since you're there please add some padding to the tab class (window one should already have it) [15:54] Trevinho, not sure [16:01] mterry: I've pushed the updates to the branch... [16:01] mterry: it would be nice to get the gir packaged as well btw [16:02] Trevinho, yeah... Do we not have any python consumers now or are there static bindings for that? [16:03] mterry: I think that who is using it with pyhton just uses the raw DBus API (but loosing some features) [16:03] Trevinho, your last update added an empty chunk to the changelog [16:03] mterry: autopilot does it for example (but also because it was not using gir at all due to some old dependency) [16:07] Trevinho, also you correctly noted that the libglib2.0-dev needed to be updated, but you did 2.30 instead of 2.32 like the Build-Depend. Should probably be same === gatox is now known as gatox_lunch [16:07] mterry: actually the library needs a lower version than bamfdaemon [16:07] mterry: that's why I didn't put the same values [16:07] Trevinho, ah OK [16:08] Trevinho, so has bamf never needed libwnck or what? [16:08] mterry: the daemon yes, the library never [16:08] mterry: the library only depends on dbus and glib [16:08] Trevinho, and does the daemon no longer need it? [16:08] mterry: so... it depends on it since it depends on the daemon, but not strictly [16:09] mterry: so you can link on libbamf even without having libwnck-dev installed [16:10] Oh daemon still needs it, sure [16:10] mterry: oh I forgot to move some debian files... (doing it now) [16:15] mterry: do we really need Depends: ${shlibs:Depends} on libbamf3-dev? [16:15] Trevinho, no I shouldn't think so [16:21] mterry: everything pushed should be ok now [16:22] Trevinho, it's not a big deal, but I do like the the trailing commas on the last item in a dep list [16:22] Trevinho, keeps future diffs shorter and easier to read when we add one at the end [16:22] mterry: i've removed some [16:22] Ah, ok [16:22] sorry... I read a "I don't"... Putting it back === gatox_lunch is now known as gatox [17:42]