[06:34] <didrocks> thomi: hey, still around by any chance?
[08:22] <didrocks> sil2100: hey, how are you?
[08:26] <sil2100> didrocks: hi! Sleepy, but alright - how about you?
[08:26] <didrocks> sil2100: I'm good thanks!
[08:26] <sil2100> didrocks: I'm looking at builds 76 and 77 now :)
[08:26] <didrocks> sil2100: yeah, I wanted to update you that 77 is showing the same
[08:27] <didrocks> sil2100: maybe the new autopilot is too fast for the intel machine :p
[08:33] <sil2100> ;)
[09:11] <didrocks> sil2100: does it seem to be time-related/easily fixable?
[09:18] <rye> Hi, https://bugs.launchpad.net/unity/+bug/1102410 - should I reopen the bug? I don't see how the blur became faster. It is quite the same speed as the old one before the nux fix
[09:19]  * rye curses every time he hits the "Super" key now because of that and https://bugs.launchpad.net/unity/+bug/1099787
[09:30] <smspillaz> rye: there are a number of things which could cause blur to be slow
[09:30] <smspillaz> rye: it would be better if we changed the description of that bug to "reduce the number of samples taken for the dash blur"
[09:32] <smspillaz> rye: the best approach to making blurs faster IMO would be to use a cache to reduce re-blurring so many fragments on each frame
[09:32] <smspillaz> That would require nux to be able to do geometry clipping, which appears to be a challenge in itself
[09:35] <sil2100> didrocks: it should be feasible, just give me a few more moments to finish up some things :)
[09:35] <didrocks> sil2100: sweet! :)
[09:38] <rye> smspillaz: aha, it reblurs everything on every frame draw? This is consistent with what I am seeing for the dash previews, even the unaffected regions take time to draw
[09:38] <smspillaz> rye: yes. Nux doesn't have a concept of partial texture redraws
[09:39] <smspillaz> I had a look into what it would take to add partial texture redraws like we have in compiz, but it would be very complicated and I suspect we'd have to repeat ourselves a lot in the code
[09:39] <smspillaz> because there's no central "draw a texture" function in nux
[09:40] <smspillaz> rye: to clarify: it reblurs the background of any window intersected by any new damage events
[09:40] <smspillaz> for the dash, this happens to be full-screen (for uninteresting reasons)
[09:41] <smspillaz> for the switcher this happens to be parts of the screen
[09:42] <rye> smspillaz: originally there was blur_passes = 1, then it was removed (default is 1 anyway, hm). But I don't see how that would affect the speed drastically. I am actually thinking we are using the wrong blur now, not the faster one
[10:01] <luv> Trevinho: good morning, would you have a sec to see the new diff here https://bugs.launchpad.net/unity/+bug/1107866 ?
[10:02] <luv> i mean here https://code.launchpad.net/~lukas-vacek/unity/bamficon_windowlist-raring/+merge/145676
[10:02] <luv> oh
[10:02] <luv> you already did! :-)
[10:12] <luv> Trevinho: great, i appreciated your comments; btw the fact that I copy WwindowPtr and not the id is because Windows() used to return the id back in unity-5.0
[10:14] <luv> oh and i dont think MAXIMUM_LABEL_WIDTH_PROPERTY is an integer ... because I indeed used an integer originally but it wouldn't compile so I checked the type in the src code and it requires const char * so i changed that and it works fine
[10:15] <luv> yeah and thanks for your superfast answer! Those are all small changes and I will get tham sorted tonight.
[10:55] <smspillaz> rye: we should be using the faster one
[10:55] <smspillaz> rye: it would be called QRP_GLSL_LSBlur or something
[11:22] <yaraju> hi all!
[11:22] <yaraju> Though I've tried following the forums online, i find that when I add a new launcher using "Alacarte" it won't show up on my Unity Dash search. Can anyone help me figure out what's going on?
[12:03] <MCR1> JohnLea: Hi :) Please comment on bug 1116538.
[12:06] <didrocks> MCR1: hey, did you check to finish the work on the minimize/maximize?
[12:06] <didrocks> like exposing to g-c-c
[12:07] <didrocks> as we are in a middle ground right now, some part are not yet reviewed by smspillaz
[12:07] <JohnLea> MCR1; re that bug, does "Strg" = "Ctrl"?
[12:07] <MCR1> didrocks: I am still waiting for smspillaz' input.
[12:07] <didrocks> smspillaz: ^
[12:07] <didrocks> MCR1: otherwise, I'll revert the change for coherence
[12:08] <MCR1> didrocks: Why revert domething that works ? The only problem remaining is that you just can change shortcut via CCSM now...
[12:08] <didrocks> MCR1: it doesn't work
[12:08] <didrocks> it doesn't migrate the right keys
[12:08] <didrocks> and there is no way to change the shortcut as we did
[12:08] <MCR1> didrocks: I do think reverting is counterproductive -> ofc it works
[12:08] <didrocks> so the "having something working everyday" rule is broken
[12:09] <didrocks> MCR1: right, but we have half changes
[12:09] <didrocks> so it doesn't work for the reasons above ^
[12:09] <didrocks> MCR1: and CCSM isn't an official tool
[12:09] <MCR1> as I said, I am commited to fixing it fully
[12:09] <didrocks> yep, please get in sync with smspillaz ASAP
[12:09] <MCR1> sure - I have not forgotten it ;)
[12:10] <smspillaz> JohnLea: the only modifier I can think of as equavilent to Control is Primary
[12:10] <MCR1> JohnLea: No, that bug is about having 2 restore window functions instead of one, so for grid-resized windows we currently use another shortcut to restore than for all the other windows
[12:11] <MCR1> smspillaz: Hi
[12:11] <smspillaz> yeah I saw
[12:11] <smspillaz> hang on
[12:11] <MCR1> smspillaz: Cool, thanx
[12:12] <smspillaz> MCR1: you've reminded me that we really should autogenerate the keybindings glue code
[12:12] <MCR1> JohnLea: IMHO we need just Ctrl+Alt+Down and it should work for all windows (first restore, then minimize), no ?
[12:12] <MCR1> smspillaz: Oh, that would be great
[12:12] <smspillaz> its a pain to get right though
[12:13] <MCR1> smspillaz: Because currently changing shortcuts is like visiting hell ;)
[12:13] <smspillaz> MCR1: only if you want to expose them in gnome-control-center
[12:13] <JohnLea> MCR1; agreed we should standardise, also agree with getting rid of the "Ctrl + Alt+ R" shortcut and replacing it with "Ctrl + Alt + Down".  I was just wondering why the bug didn't mention Ctrl and was talking about Strg instead, but never mind, I'll update the bug description
[12:13] <smspillaz> the current code is actually partially autogenerated
[12:13] <smspillaz> though I don't know where the script I used to do it was
[12:14] <MCR1> JohnLea: Because the reporter is from Germany
[12:14] <MCR1> JohnLea: And there Strg==Ctrl
[12:14] <MCR1> Steuerung
[12:14] <JohnLea> MCR1; anyhow, it's a good change, I'm just updating the bug now
[12:14] <MCR1> JohnLea: Thx
[12:15] <JohnLea> MCR1; done
[12:19] <MCR1> JohnLea: Thx
[12:20] <smspillaz> hmm
[12:20] <smspillaz> MCR1: this:
[12:20] <smspillaz> 21	-    { "unmaximize_window_key", "unmaximize" },
[12:20] <smspillaz> 22	+    { "unmaximize_or_minimize_window_key", "unmaximize or minimize" },
[12:20] <smspillaz> will probably cause some trouble
[12:20] <MCR1> smspillaz: The big question is-> if I added a new function + new shortcut, what do we exactly need to adjust to make g-c-c work with the new shortcut
[12:20] <smspillaz> you probably wanted unmaximize_or_minimize
[12:20] <yaraju> Any help with why my launcher added using "alacarte" won't showup on a Unity Dash search?
[12:21] <MCR1> smspillaz: ok
[12:21] <smspillaz> (the current version won't work with gconf, and changes won't get propogated back to compiz from gsettings if it changes directly in gsettings)
[12:21] <MCR1> smspillaz: Isn't that the description only ? So the spaces do not matter ?
[12:22] <smspillaz> MCR1: no, its the name of the foreign gnome key with underscore separated identifiers (instead of dashes)
[12:22] <MCR1> ok
[12:22] <smspillaz> (we just translate _ to - for the gsettings case)
[12:22] <MCR1> yep, I understood that
[12:23] <smspillaz> MCR1: if you want unmaximize_or_minimize_window_key to integrate with the existing org.gnome.desktop.wm.keybindings:unmaximize key
[12:23] <smspillaz> then you should leave that declaration as
[12:23] <smspillaz>     { "unmaximize_or_minimize_window_key", "unmaximize" },
[12:24] <MCR1> well, that is what didrocks suggested (I think), but imho this would be confusing, no ? Wouldn't it be better to name the key correctly ?
[12:25] <MCR1> ofc if you also say that it should be done that way. I'll do it that way
[12:26] <smspillaz> MCR1: creating a new key would be a pain
[12:26] <MCR1> ok, then let's go with this version...
[12:26] <smspillaz> you'd then have unmaximize and "unmaximize_or_minimize" next to each other, and then you'd have to update org.compiz.integrated and then also .convert files and .keybindings files and blah blah blah
[12:26] <smspillaz> not all that fun
[12:27] <MCR1> ok, let's do it the more easy way
[12:27] <smspillaz> almost more painful than I'm finding rails development at the moment
[12:27] <MCR1> hehe
[12:28] <smspillaz> "you wanted to add a new page? oh, I guess you'll have to update routes.rb, the controller, the seed.rb, pages_model.rb" blah blah blah
[12:28] <MCR1> urgh
[12:28] <smspillaz> "oh its not working - run rake db:seed you tard"
[12:29] <smspillaz> I don't understand how a framework that embodies DRY as a core value doesn't encourage the use of constants
[12:31] <smspillaz> how much longer until feature freeze
[12:31]  * smspillaz wonders if its worth even trying to get people to look at the gesture test refactoring code
[12:32] <smspillaz> or if the plan is just "ignore until it goes away"
[12:34] <MCR1> smspillaz: Oh, thanks 4 the other review, btw. :)
[12:34] <MCR1> smspillaz: Probably this will also eliminate some of the Coverity static analyzer bugs...
[12:35] <smspillaz> maybe, although coverity checks for different kinds of things
[12:36] <MCR1> smspillaz: I am having slight problems to implement the damaging from scratch in workspacenames and at the same time workspacenames gets featured everywhere and still has this nasty flickering bug, which I've already fixed...
[12:36] <MCR1> smspillaz: Would it be okay to get this fix in first and implement the damagerect in a subsequent MP ?
[12:37] <MCR1> smspillaz: I am confident I can get it done until FF (hopefully)
[12:37] <MCR1> smspillaz: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix-1075578-workspacenames-flickering-during-display/+merge/133124
[12:38] <MCR1> ^^ this just fixes the flickering for now :-[
[12:38] <MCR1> smspillaz: Example for feature: http://www.iloveubuntu.net/how-easily-add-names-workspaces-ubuntu-1210
[12:38] <smspillaz> yeah doing that is not such a great idea
[12:39] <smspillaz> full-screen redraws all the time == dead batteries
[12:39] <MCR1> smspillaz: Could you help me implement it then ?
[12:39] <smspillaz> MCR1: was the "timer" variable a bool? or what
[12:39] <MCR1> smspillaz: Yes, I know - it is not ideal
[12:39] <smspillaz> CompTimer ?
[12:39] <smspillaz> CompTimer *?
[12:40] <MCR1> smspillaz: unos momentos
[12:41] <MCR1> smspillaz: No, it is a simple int
[12:41] <MCR1> int		timer;
[12:42] <smspillaz> MCR1: ... what is it supposed to represent? Where else is it used ?
[12:45] <MCR1> well, it is used for different things in workspacenames, but in the case I've corrected it is timer = optionGetFadeTime () * 1000;
[12:46] <smspillaz> MCR1: is it decremented anywhere ?
[12:46] <MCR1> timer -= msSinceLastPaint;
[12:46] <MCR1> WSNamesScreen::preparePaint (int msSinceLastPaint)
[12:47] <MCR1> It means it will only damage the screen during fade, but not during display anymore
[12:48] <MCR1> as far as I understand... and as the flickering fix shows
[12:48] <smspillaz> MCR1: hmm
[12:49] <smspillaz> MCR1: in any case, your best bet is to find the condition in which the text is actually meant to be displayed, and then call cScreen->damageRegion (textRectangle); in donePaint on the same condition
[12:49] <MCR1> smspillaz: I just saw that I have to remove the dependency on mousepoll as well, it is still there...
[12:50] <MCR1> smspillaz: Ok, I'll try to fully fix it, before I'll ping you again ;) I have to understand how damageRegion works exactly anyway...
[12:51] <smspillaz> MCR1: damageRegion means "this area of the screen will be redrawn"
[12:51] <MCR1> yes, I understand the theory ;)
[12:52] <smspillaz> you need to do it because core uses that information to copy from the scene framebuffer to the backbuffer
[12:54] <MCR1> smspillaz: First I'll have to fix the shortcut-thingy or else didrocks will kill me ;)
[12:54] <smspillaz> didrocks doesn't kill people
[12:54] <smspillaz> he hugs them to death
[12:54] <MCR1> phew
[12:54] <smspillaz> which is slightly different
[12:54] <didrocks> different approach :-)
[12:55] <MCR1> hehe
[12:56] <MCR1> smspillaz: I also have a fix for the cylinder rendering of the Cube Gears: http://imagebin.org/245474
[12:57] <smspillaz> great
[12:57] <MCR1> smspillaz: Here you can see that they are rendered wrongly ^^
[13:07] <MCR1> smspillaz, didrocks: *Should* be okay now, hopefully: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1115128-expose-unmaximize_or_minimize_key-in-g-c-c/+merge/146384
[13:11] <smspillaz> MCR1: have you tried it to make sure it works ?
[13:11] <smspillaz> I haven't got time to manually test merge proposals atm
[13:12] <MCR1> smspillaz: No, and I am not sure how as g-c-c integration here is a bit broken atm...
[13:17] <luv> Trevinho: ping ;-)
[13:17] <luv> Trevinho: what the hell^W^W is the deal with the AP/unit tests?
[13:17] <Trevinho> luv: 1 sec I'll be back to you
[13:23] <Trevinho> luv: ok, I'm here...
[13:23] <luv> great  ..
[13:23] <Trevinho> luv: so, I'd prefer an unit test as it's less prone to failures
[13:23] <Trevinho> and should also be quite easy here...
[13:23] <luv> alright, well ... got to hear ... almost feel like giving up :-/
[13:24] <luv> good to hear
[13:24] <smspillaz> MCR1: describe 'broken'
[13:24] <Trevinho> luv: what you need is adding a new tet case to test_application_launcher_icon.cpp
[13:25] <luv> alright what should the test case do ... how do i simulate what Windows() return ?
[13:25] <Trevinho> It should be enough to: do ...
[13:25] <Trevinho> auto win = std::make_shared<MockApplicationWindow>(g_random_int());
[13:25] <Trevinho>   mock_app->windows_ = { win };
[13:25] <smspillaz> MCR1: it should 'just work' when you change WM realted options in gsettings
[13:25] <MCR1> smspillaz: I have flat-file CCSM config here and g-c-c does not seem to recognize it
[13:26] <smspillaz> MCR1: you need to use gsettings
[13:26] <luv> and then I compare the values from win with what my function returns ... ok
[13:26] <MCR1> smspillaz: then CCSM crashes on me/ does not like gsettings
[13:26] <luv> still not super excited about that though :-)
[13:26] <Trevinho> luv: then you only have to do mock_icon->GetMenus()... that will return a list of dubsmenu items...
[13:26] <smspillaz> MCR1: COMPIZ_CONFIG_PROFILE=ubuntu ccsm
[13:26] <Trevinho> luv: you've to ensure that there's one matching your window name
[13:27] <luv> um, ok, im lost again :-)
[13:27] <Trevinho> luv: err.. actually if you add one window you should ensure that no item is there, while if there are two windows (add one more), it has the menus
[13:28] <MCR1> smspillaz: It does not work here -> once I change (in CCSM) from flat-file to gsettings, CCSM simply closes
[13:28] <luv> um so how many tests should i write?
[13:28] <luv> is it enough to write a test for each ...  0,1,2 windows?
[13:28] <MCR1> smspillaz: Once I reopen it, it uses flat-file again
[13:28] <smspillaz> luv: test for code coverage
[13:29] <smspillaz> luv: so, you should ensure that every possible path in your change is covered by some kind of test
[13:29] <smspillaz> MCR1: I guess you can force it, by editing ~/.compiz-1/compizconfig/config
[13:29]  * MCR1 is not sure if he wants that...
[13:31] <luv> well, i haven't done any unit test _for unity_ yet so please bear with me
[13:32] <MCR1> smspillaz: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1117311-gears-cylinders-not-rendered-correctly/+merge/146853
[13:33] <smspillaz> MCR1: yeah I saw
[13:33] <smspillaz> MCR1: in any case, please find a way to switch to using gsettings and test the integration code
[13:33] <luv> do I want to test GetMenus or EnsureMenuItemsWindowsReady ? In case I want to test GetMenus - should I check all created dbusmenuitems have all properties set exactly as they should or is it enough to see that they are not/available?
[13:33] <MCR1> smspillaz: Ok, I'll try
[13:34] <luv> im trying to shorten this endless merge review ping-pong, that's all ....
[13:37] <luv> smspillaz: kinda not enough, because cases like bunch of windows with same titles, bunch of windows with different titles but same shorten titles are not covered in the code (explicitly)
[13:37] <smspillaz> bregma: get in touch when you can :)
[13:38] <luv> s/covered/expressed/
[13:38] <Trevinho> luv: sorry, I missed your messages
[13:39] <Trevinho> luv: so, two tests are enough in your case
[13:39] <Trevinho> luv: one that checks that there are no window items, another one that checks that there are
[13:40] <luv> great, i will add an extra one which tests for windows with same title as well - that should be handy too
[13:40] <luv> Trevinho: thanks
[13:40] <luv> I will do that tonight and we can go through next round of the ping pong tomorrow ;-)
[13:43] <MCR1> smspillaz: Could you please comment on bug 1101198 - I would like to know how you want that fixed...
[13:44] <smspillaz> MCR1: I don't really know "how" it should be done, as I don't know the ccsm codebase
[13:44] <MCR1> smspillaz: Well, there are cases for everything there, but not for a soft dependency...
[13:45] <MCR1> smspillaz: So we could a) extend CCSM to understand a recommend in the xml
[13:45] <smspillaz> it sounds like a good idea but I don't really know exactly how to do it
[13:45] <MCR1> smspillaz: Or b) scratch that and make (in this case text) a hard dependency
[13:46] <smspillaz> MCR1: of workspacenames ?
[13:47] <MCR1> smspillaz: Currently it will just say "plugin x needs feature textrendering, which is provided by plugins a and b, Do you want to activate a or b or deactivate plugin x ?"
[13:48] <MCR1> smspillaz: No, it is about: scaleaddon, stackswitch, shift, scalefilter, thumbnail, ring
[13:48] <smspillaz> better to make it optional *shrug*
[13:48] <MCR1> smspillaz: They all need text, but will also work without
[13:49] <smspillaz> yeah, just leave it optional
[13:49] <MCR1> smspillaz: Yeah, the best thing would be a soft dependency. I will have to learn some Python ;)
[13:49] <MCR1> smspillaz: Currently nothing happens and the user is not informed about text...
[13:49] <MCR1> smspillaz: So all text-related options silently fail
[13:50] <MCR1> smspillaz: if text plugin is disabled
[13:50] <MCR1> smspillaz: Then something like this happens to users: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1099100-thumbnail-title-text-issues/+merge/143042/comments/310279
[13:52] <MCR1> smspillaz: Seems CCSM coders have thought about everything, just not that ;)
[13:53] <smspillaz> MCR1: there had been talk of that for a long time in compiz
[13:53] <smspillaz> many years back
[13:53] <smspillaz> eg cube should "suggest" rotate
[13:54] <MCR1> smspillaz: yeah, exactly -> soft dependencies with the user deciding
[13:55] <MCR1> recommends feature x which is provided by plugin y, should we enable plugin y or do you want the feature x to stay disabled ?
[13:59] <MCR1> smspillaz: I will implement that in the next weeks...
[13:59] <MCR1> smspillaz: Let's make CCSM perfect :)
[14:00] <smspillaz> MCR1: have a look at how some of the other tags are handled in libcompizconfig and the xml
[14:01] <MCR1> yes, I already did that :)
[14:01] <smspillaz> I think if you want to add a new tag, you need to update the .proto, compiz.cpp (in compizconfig), compizconfig.pyc, and Settings.py
[14:01] <MCR1> that is why I am confident about implementing it
[14:01] <MCR1> thx 4 the info :)
[14:02] <mterry> sil2100, so enough unity tests failed last night to stop the daily build
[14:03] <MCR1> smspillaz: I do not want to nerve, just FYI: There is another related problem -> for example water plugin needs FBO to be enabled to work, but we cannot check for a special setting via CCSM <- I am still thinking about how to fix that best
[14:03] <smspillaz> MCR1: TBH we should remove that setting
[14:03] <MCR1> nooooooooooo
[14:04] <smspillaz> MCR1: it makes sense to - and here is why
[14:04] <MCR1> Here Compiz is fast with FBO turned off and slow like sh*t when turned on
[14:04] <MCR1> with fglrx or gallium-radeon
[14:04] <smspillaz> "always swap buffers" is basically the option that 99% of users would care about
[14:05] <MCR1> but FBO turned on (which is default) makes stuff really slow here
[14:05] <MCR1> and that is with a fast system and very fast gfx card
[14:05] <smspillaz> MCR1: it doesn't have any impact if core or plugin code is not using it
[14:05] <smspillaz> if "always swap buffers" is off, there's no reason to use framebuffer objects for rendering
[14:05] <smspillaz> (at least in the basic case)
[14:06] <MCR1> IMHO FBO should be off by default, but that is just my 2 cents from testing on ATI
[14:07] <smspillaz> MCR1: I think what you meant to say was "always use glXSwapBuffers, even if it means backing up the previous frame" should be off by default
[14:07] <smspillaz> and that would be a bad idea regardless, because it tears like crazy
[14:07] <didrocks> MCR1: tbh, I would prefer you ensure it's working on a fresh account if needed :)
[14:07] <didrocks> MCR1: the g-c-c integration should work there ;)
[14:07] <MCR1> didrocks: ok
[14:07] <didrocks> thanks!
[14:08] <MCR1> didrocks: please give me a little bit of time...
[14:09] <didrocks> sure
[14:09] <smspillaz> MCR1: Iunno if we can do it for this release, but it might be worth looking into how hard it would be to implement GLX_EXT_buffer_age for the root-window-only case on the mesa drivers
[14:09] <MCR1> didrocks: it is high up on the priority list
[14:09] <didrocks> thanks MCR1 ;)
[14:10] <smspillaz> krh said he wouldn't support it on X because compositing + reparenting makes it hard to support, but I know that logic makes no sense for the root window, because there's no reparenting or compositing involved there
[14:10] <MCR1> didrocks, yw ;)
[14:11] <MCR1> smspillaz: It would be great to support additional OpenGL features, I agree 100%
[14:12] <smspillaz> well, buffer_age in particular means we don't need to resort to crazyness in order to support glXSwapBuffers/glXSwapControlEXT
[14:14] <MCR1> is buffer_age working on all main drivers ?
[14:14] <smspillaz> only nvidia at the moment
[14:14] <MCR1> hmm
[14:14] <smspillaz> its trivial to support in a driver though
[14:15] <MCR1> Well, you know that I am still missing OpenGL knowledge to make judgements here...
[14:15] <smspillaz> the graphics system has to give you a new backbuffer on glXSwapBuffers, its not hard for the driver to tell you when it was last displayed
[14:15] <didrocks> hey fginther, around?
[14:15] <fginther> didrocks, morning!
[14:16] <didrocks> how are you?
[14:16] <fginther> sleepy, need some coffee :)
[14:16] <didrocks> ahah ;)
[14:16] <didrocks> fginther: once, you are awaken, did you see https://code.launchpad.net/~ps-jenkins/bamf/latestsnapshot/+merge/146765? It seems that it didn't go with the fastrack (in addition to failing
[14:16] <MCR1> smspillaz: But we had excellent OpenGL feature detection in UFO:AI. It might make sense to look at that code and see what we could use...
[14:17] <smspillaz> MCR1: feature detection doesn't really matter in this case
[14:17] <fginther> didrocks, I'll get it going.
[14:17] <didrocks> sil2100: hey hey! did you get any progress or the failures look ugly?
[14:17] <smspillaz> MCR1: the fact is that if you have tearing in a compositor, you're kinda doing it wrong
[14:17] <MCR1> smspillaz: yep - the good ol' tearing problem...
[14:17] <didrocks> fginther: thanks, then, all projects will have the fasttrack (in unity, webapps, webcreds, oif, indicators… ?)
[14:18] <smspillaz> bregma: you around ? .....
[14:19] <MCR1> afk, bbl
[14:20] <fginther> didrocks, I'm still waiting on a review for the fasttrack changes. keep your fingers crossed :)
[14:20] <didrocks> fginther: heh, ok :)
[14:46] <ritz> hi Mirv, busy ? looking for assistance with  https://launchpad.net/bugs/1096954
[15:12] <kenvandine> mhr3, did you see my valgrind log from yesterday?
[15:13] <kenvandine> mhr3, http://ubuntuone.com/0AQvy3yDmcQCLz3Ejxn6pE
[15:13] <mhr3> nope
[15:13] <mhr3> will check out
[15:17] <kenvandine> mhr3, thanks
[15:19] <ritz> ping didrocks
[15:20] <sil2100> didrocks: will give you an update in a moment, been on lunch and didn't see your ping :)
[15:21] <didrocks> sil2100: no worry
[15:21] <didrocks> hey ritz
[15:21] <ritz> hi didrocks, busy ? looking for assistance with  https://launchpad.net/bugs/1096954
[15:21] <ritz> unity 2d
[15:22] <ritz> forcing  compositing as off seems to fix the issue
[15:22] <ritz> in code
[15:22] <ritz> any clue on how I could proceed further in this ?
[15:25] <didrocks> ritz: kind of busy TBH ;) you should retarget the package from unity to unity-2d btw ;)
[15:25] <didrocks> ritz: not really sure, does it happens with other QML apps?
[15:25] <ritz> hmm, have not tested this with other qml apps
[15:27] <didrocks> maybe that will give an hint
[15:27] <ritz> thanks, will try this
[15:31] <sil2100> didrocks: I think I have a hint what might be wrong, since those failures I can reproduce locally - so they're not 'hopeless' ;)
[15:31] <didrocks> sil2100: sweet, I hope that we can have an unity daily release tomorrow passing tests at least :)
[15:31] <didrocks> ritz: yw ;)
[15:53] <sil2100> Ha!
[16:03] <sil2100> didrocks: I know how to fix some of those failures, so I'll submit some fixes and get them merged till EOD
[16:05] <sil2100> mterry: hi! If anything, I have a fix for the preview-related AP failures in the unity release task
[16:05] <sil2100> So that we don't step on eachother's toes
[16:23] <jibel> didrocks, would it be possible to land the introspection modules of autopilot daily into raring or is it not done on purpose?
[16:35] <didrocks> jibel: introspection modules? sorry out of context
[16:35] <didrocks> you mean the -gtk and -qt ones?
[16:35] <jibel> didrocks, yes autopilot-(gtk|qt)
[16:35] <didrocks> IIRC, some work were needed (like the qt one is dep on qt 5), I think some tests or something on the -gtk ones were not working, cyphermox would know more? ^
[16:36] <cyphermox> well there were issues initially with the -qt one
[16:37] <cyphermox> and further work on -gtk to make sure the module would be installable properly, I'll check again to see how ready that is
[16:37] <cyphermox> I think it can land today
[16:38] <jibel> cyphermox, what do you mean by "installable properly"?
[16:38] <cyphermox> there were issues with how the package was built, now it was updated to make it a proper gtk module IIRC and just clean up the packaging
[16:39] <jibel> k
[16:39] <mpt> Cimi, yo, could you join #ubuntu-design?
[16:40] <cyphermox> jibel let me run it through sbuild now and I'll be able to tell you exactly how ready I think it is to land
[16:41] <jibel> cyphermox, thanks
[16:41] <cyphermox> there's a minor copyright issue I'll fix now
[16:42] <cyphermox> didrocks: I can sponsor the first upload and we'll make it autoland after?
[16:43] <didrocks> cyphermox: well, let's do autolanding right away :)
[16:43] <cyphermox> ok, I thought it was better to have the first-ever upload manually ;)
[16:45] <didrocks> no no :)
[17:26] <MCR1> hrmpf, didrocks is gone...
[19:07] <andyrock> mpt, the panel-tray branch should land in trunk soon ;)
[22:24] <luv> hey, how can i executed tests/test_application_launcher_icon.cpp ?
[22:25] <luv> oh and how was the trick to add pseudo windows to mock_app ??
[22:34] <luv> hmm and how can i get dbusmenuitems off it anyway?