[07:02] <ricotz> racarr, hi, please consider this bamf change or similar http://paste.debian.net/plain/197585
[08:25] <tsdgeos> Trevinho: what defines glib::Timeout ?
[08:29] <gord> tsdgeos, https://bazaar.launchpad.net/~unity-team/unity/trunk/view/head:/UnityCore/GLibSource.h#L133
[08:29] <tsdgeos> gord: ahhh, i thought it was in glibmm or something and couldn't find it anywhere
[08:29] <tsdgeos> didn't think to look inside unity itself ^_ ^
[08:29] <tsdgeos> tx
[08:29] <gord> yeah unity doesn't use glibmm, so anytime you see something like that, it'll be inside unitycore
[08:33] <gopu> Hi all
[08:33] <gopu> My unity is having some problem working in 3D
[08:33] <gopu> Compiz is taking 100 % Cpu in 3D
[08:34] <gopu> Any idea
[08:36] <gopu> Anyoone here
[08:39] <tsdgeos> gord: Trevinho suggested to change g_timeout_add to glib::Timeout, but the first takes a void* with data and the second not, what's the recommented way of using glib::Timeout? Do i inherit from it to stuff in my data?
[08:43] <tsdgeos> gord: ok, i see how to use it
[08:50] <didrocks> sil2100: Mirv: can you review/approve https://code.launchpad.net/~didrocks/unity/workspace-switch-translation/+merge/128440 please?
[08:50] <didrocks> I'm cherry-picking it in 6.0 meanwhile
[08:56] <sil2100> didrocks: ok, one moment
[08:56] <didrocks> thanks :)
[09:01] <Trevinho> tsdgeos: glib::Timeout can also be called with a lambda function, so you can pass to it anything you want
[09:01] <tsdgeos> yep yep, found that, tx
[09:01] <Trevinho> tsdgeos: I suggest you to check test_glib_source to see better ways to use it or just grep the unity code :)
[09:02] <tsdgeos> yes, did that 15 minutes ago ;-)
[09:02] <Trevinho> tsdgeos: ok, nice :)
[09:11] <tsdgeos> Trevinho: do i really have to move to glib::DBusProxy? calling g_dbus_connection_call_sync really helps and shouldn't hurt in a test
[09:11] <Trevinho> tsdgeos: i tought it was simpler to read/write, but if you want continue with that it's ok..
[09:11] <Trevinho> tsdgeos: what's the problem with the glib:: one?
[09:12] <tsdgeos> well, the thing is that i trigger the resync and then ask via dbus if it has sent already to know when to end the waiting loop, but to ask via dbus the function that returns a bool i'm using the sync method that is really convinient
[09:12] <tsdgeos> if i don't have the sync method i need a waiting loop inside the waiting loop
[09:13] <tsdgeos> which is a bit weirdish
[09:13] <Trevinho> tsdgeos: ah, ok
[09:14] <Trevinho> tsdgeos: or feel free to add a CallSync method to glib::DBusProxy too :)
[09:14] <tsdgeos> ok, i'll have a look at it
[09:15] <Trevinho> tsdgeos: otherwise another way is just to use the async way.. but after calling it you can just add a utils::WaitForTimeoutMSec(msecs); without the need of adding a new loop
[09:15] <tsdgeos> yeah, just didn't want to add a random number in that wait
[09:17] <tsdgeos> i'll try to add the callsync method
[09:17] <tsdgeos> shouldn't be that hard
[09:17] <tsdgeos> last famous words
[09:19] <Trevinho> tsdgeos: hehe :), if it causes too troubles, using the way you're using it's fine as well.. Maybe just add an utility method in TestDBusIndicators, to call a method without repeating all the common parameters (i.e. you pass to it only a method name)
[10:00] <ricotz> mhr3, hi :)
[10:01] <mhr3> ricotz, hey
[10:01] <ricotz> mhr3, you have a moment for bamf?
[10:01] <mhr3> Trevinho, does ;)
[10:01] <mhr3> well.. might ;)
[10:01] <Trevinho> mhr3, ricotz yeah... I have :)
[10:01] <ricotz> mhr3, i already pinged racarr about it
[10:02] <ricotz> ;)
[10:02] <ricotz> i really want to have the webapps dependency optional
[10:02] <ricotz> Trevinho, so maybe you could consider that http://paste.debian.net/plain/197585
[10:03] <Trevinho> ricotz: well, yes.. I tought the same few days ago...
[10:03] <Trevinho> ricotz: looking
[10:03] <ricotz> Trevinho, it is pretty easy and even doesnt touch the lib
[10:03] <Trevinho> ricotz: looks fair
[10:04] <Trevinho> ricotz: please do a MR for that
[10:05] <ricotz> Trevinho, the depcheck could be done more elegant of course by introducing a real --enable-* flag, but this automatic choice is working
[10:08] <Trevinho> ricotz: one thing, add another bamfdaemon_webapps_headers += ... and don't move the shared headers to bamfdaemon_sources
[10:08] <ricotz> Trevinho, https://code.launchpad.net/~ricotz/bamf/optional-webapps/+merge/128456
[10:09] <ricotz> Trevinho, yeah
[10:11] <didrocks> sil2100: https://code.launchpad.net/~didrocks/unity/workspace-switch-translation/+merge/128457
[10:14] <sil2100> didrocks: ugh, ok
[10:15] <didrocks> sil2100: it's better, we don't have anything to do with the manual upload :)
[10:17] <sil2100> didrocks: ok then ;)
[10:20] <tsdgeos> Trevinho: implemented all your suggestions
[10:22] <Trevinho> tsdgeos: cool
[10:27] <ricotz> Trevinho, updated the merge
[10:33] <Trevinho> ricotz: approved
[10:35] <ricotz> Trevinho, thanks :), feel free to merge it then
[10:36] <Trevinho> ricotz: automerger will do that in some minutes
[10:36] <Trevinho> (hopefully) :)
[10:36] <ricotz> Trevinho, alright
[10:37] <ricotz> Trevinho, another problem is for sure that if gtk2 is enabled webapps must be disabled
[10:37] <Trevinho> ricotz: mh probably...
[10:38] <ricotz> Trevinho, not sure if there are plans to drop gtk2 support which would solve this problem of course
[10:38] <Trevinho> ricotz: however I was wondering if we could drop bamf-gtk2...
[10:38] <ricotz> right
[10:40] <Trevinho> even if ginn still depends on it...
[10:41] <ricotz> Trevinho, ah, don't worry the daemon doesnt really have a gtk2 flavor so it isnt broken currently with enabled webapps
[10:41] <Trevinho> ricotz: yeah, i know
[11:00] <Trevinho> tsdgeos: looks good overall, comments added
[11:03] <tsdgeos> Trevinho: the lambdas are actaully different
[11:05] <Trevinho> tsdgeos: mhmh
[11:05] <tsdgeos> Trevinho: i don't get what you mean with "fix the parameters indentation."
[11:05] <Trevinho> tsdgeos: well.. the is-connected one should be called anyway for all tests
[11:06] <mhr3> aaaaaah
[11:06] <mhr3> CallSync in UnityCore
[11:06] <mhr3> nooooooooooooooooo
[11:06] <mhr3> kill it!
[11:06] <mhr3> kill it now!
[11:06] <tsdgeos> Trevinho: well, i mymiced the hud tests, that only do the is connected for the first one
[11:06] <tsdgeos> mhr3: well it was Trevinho that suggested it
[11:07] <tsdgeos> i did not have it originally i'm just doing what you guys ask
[11:07] <Trevinho> tsdgeos: in GLibDBusProxy.cpp there's a missing space..
[11:07] <tsdgeos> Trevinho: which line?
[11:08] <Trevinho> tsdgeos: 108 in the diff
[11:08] <Trevinho> tsdgeos: about callsync btw why do you added also the g_main_loop thing?
[11:09] <tsdgeos> ah right in the declaration
[11:09] <tsdgeos> Trevinho: because that's how the function you asked me to replace
[11:09] <tsdgeos> works
[11:09] <tsdgeos> callsync is sync
[11:09] <tsdgeos> and thus will wait for the session to be stabilished
[11:09] <tsdgeos> not fail because you're still not connected
[11:10] <Trevinho> just call that... and eventually just make it protected so it won't be mis-used... or if mhr3 really doesn't want it, move back to the old one (but put it into a TestClass method)
[11:10] <mhr3> tsdgeos, Trevinho, it'd be much better to implement a sync-capable subclass somewhere in tests
[11:10] <Trevinho> tsdgeos: yes, sure but this shuould be handled by the client
[11:11] <tsdgeos> ?
[11:11] <Trevinho> tsdgeos: I mean, if the bus is not there, it should not be a problem of glib::Proxy, make the caller function to ensure that
[11:12] <tsdgeos> you mean move the check to the test?
[11:13] <mhr3> Trevinho, acquiring the proxy is still async, that's why there's that awful thing
[11:14] <Trevinho> mhr3: yes, sure... but checking for IsConnected is enough
[11:14] <Trevinho> tsdgeos: yes
[11:14] <mhr3> tsdgeos, but yes pls, move it to tests, having the sync variant just breaks half of DBusProxy assumptions
[11:14] <tsdgeos> mhr3: well, you're asking me to move the whole function, not what Trevinho says
[11:14] <tsdgeos> can i have a single direction plz? ;-)
[11:15] <mhr3> i say no DBusProxy::CallSync()
[11:15] <Trevinho> tsdgeos: ok, remove that... and move it back to the test (but inside an utility function)
[11:15] <mhr3> i'm fine with test::SyncDBusProxy : glib::DBusProxy {...}
[11:16] <mhr3> as it's indeed useful in test environment
[11:16] <mhr3> then again you can just have a wrapper method that will be sync, but call the async method
[11:17] <mhr3> tsdgeos, afterall that's what you did in there with the main loop spinning
[11:17] <tsdgeos> mhr3: not really
[11:17] <tsdgeos> my spinning was for bus connecting
[11:17] <tsdgeos> but the dbus call was also async
[11:18] <tsdgeos> err
[11:18] <tsdgeos> sync
[11:18] <mhr3> sure, but you can do the same thing for the call
[11:18] <tsdgeos> yeah
[11:18] <tsdgeos> well
[11:18] <tsdgeos> as said already
[11:18] <tsdgeos> i *had* that
[11:18] <tsdgeos> and i was asked to change it back
[11:18] <tsdgeos> i don't mind going back
[11:19] <tsdgeos> but being 'blamed' for something i did because i was asked feels a bit ackward
[11:19] <mhr3> sorry, Trevinho likes adding stuff, i'm always more inclined to keep out things that can lead to misuse
[11:21]  * tsdgeos digs the old code
[11:23] <mhr3> tsdgeos, but your old code used the gio methods directly, right?
[11:24] <tsdgeos> g_dbus_connection_call_sync
[11:25] <mhr3> i do agree with Trevinho that it should use the c++ wrapper, otherwise there's just more risk of forgetting to unref the connection or something
[11:25] <ricotz> Trevinho, type and annotation fixes - http://paste.debian.net/plain/197659
[11:25] <mhr3> tsdgeos, Utils::WaitUntil() ftw ;)
[11:26] <ricotz> mhr3, maybe something for you to look at too ^
[11:27] <mhr3> the diff looks fine
[11:32] <tsdgeos> mhr3: how do you want me to use WaitUntil in my case?
[11:33] <mhr3> with lambda
[11:34] <mhr3> bool call_finished = false; proxy.Call([&] { .... call_finished = true; }); Utils::WaitUntil(call_finished);
[11:35] <tsdgeos> oh, i thought you meant for the other parts of the test where i do have my own timers
[11:35] <mhr3> didn't look throughly, maybe it'd make sense elsewhere as well
[11:35] <mhr3> timers are flaky
[11:36] <mhr3> +WaitUntil has a timeout by default
[11:38] <mhr3> would be awesome if WaitUntil could take a method that returns bool, is that doable with some std::function magic Trevinho?
[11:38] <Trevinho> mhr3: yes, I tought the same
[11:39] <Trevinho> mhr3: it should be easy to do
[11:39] <Trevinho> a std::function<bool()> parameter should be fine
[11:39] <tsdgeos> ok, i'll do that
[11:40] <mhr3> Trevinho, and then sigc::mem_fun?
[11:40] <mhr3> or how would the calling side look like?
[11:44] <Trevinho> mhr3: yes sigc::mem_fun is fine
[11:45] <Trevinho> ricotz: fine, please do a MR
[11:45] <ricotz> Trevinho, done, with some more additions
[11:45] <Trevinho> mhr3: also std::mem_fn is fine
[11:45] <ricotz> Trevinho, https://code.launchpad.net/~ricotz/bamf/type-fixes/+merge/128472
[11:45] <Trevinho> tsdgeos: see http://en.cppreference.com/w/cpp/utility/functional/mem_fn
[11:46] <tsdgeos> yes, i know i've that already
[11:47] <Trevinho> tsdgeos: cool
[11:47] <mhr3> Trevinho, i find mem_fn a bit weird, cause the instance is not part of the functor
[11:47] <tsdgeos> Trevinho: i'm still a bit confused as of what exactly you want with the dbus part of the test though
[11:48] <Trevinho> tsdgeos: what you mean?
[11:49] <Trevinho> tsdgeos: ah about the g_dbus_connection_call_sync ?
[11:49] <tsdgeos> Trevinho: yep
[11:50] <Trevinho> tsdgeos: it would be nice if you'd add a TestDBusIndicators::CallPanelMethod(std::string const& name, GVariant* parameters = nullptr) so that by default does
[11:51] <Trevinho> g_dbus_connection_call_sync(session, "com.canonical.Unity.Test", "/com/canonical/Unity/Panel/Service", "com.canonical.Unity.Panel.Service", name.c_str(), NULL, params, /* ret type */ G_DBUS_CALL_FLAGS_NONE, -1, NULL, NULL);
[11:52] <tsdgeos> ok, that works for me
[11:52] <Trevinho> (of course that requires that you initialize the proxy on setup, but that's fine)
[12:10] <ricotz> didrocks, hi, i think the next bamf 0.3.4 package is ready to be built with introspection and vala bindings
[12:20] <Trevinho> tsdgeos: for the wait-until thing you can just add this: http://pastebin.ubuntu.com/1267338/
[12:50] <ricotz> Trevinho, this would make the gir/vala-api nicer -- http://paste.debian.net/plain/197685
[12:54] <Trevinho> ricotz: probably it would be nice to add also a GLIB_DEPRECATED in the header
[12:54] <didrocks> ricotz: hum, do you intend that for quantal? Seems for R or SRU :)
[12:54] <Trevinho> didrocks: I'd bet for R
[12:55] <Trevinho> didrocks: we'd need a trunk branch for bamf too, not to mess with the Q things
[12:55] <ricotz> didrocks, yes R, but i dont see a problem for a SRU here
[12:55] <didrocks> Trevinho: I think Mirv did a quantal branch
[12:56] <Trevinho> didrocks: not yet
[12:56] <Trevinho> didrocks: I asked btw
[12:56] <ricotz> Trevinho, yeah, but i wanted to see if this is reasonable
[12:56] <Trevinho> ricotz: yes, it's fine for me
[12:57] <ricotz> Trevinho, so i guess it seem better to replace the old method body with calling the new one and change the internal usage of too
[12:58] <Trevinho> ricotz: yes, but leave that as it is for now... or it will break a lot some stuff I'm still working on :)
[12:58] <tsdgeos> Trevinho: sure, i had that already, but thanks for confirming i did it right :-)
[12:59] <ricotz> Trevinho, ok
[13:02] <ricotz> Trevinho, although using GLIB_DEPRECATED will bump the depend to 2.32
[13:05] <Trevinho> ricotz: for R it should be fine
[13:16] <ricotz> Trevinho, do you want a MR for this too?
[13:17] <ricotz> it will break the current build though if deprecations arent disabled
[13:18] <ricotz> Trevinho, http://bazaar.launchpad.net/~ricotz/bamf/replace-user-visible/revision/490
[13:38] <tsdgeos> Trevinho: ok, i think i'm done with the updates (second round :D) https://code.launchpad.net/~aacid/unity/do_not_reuse_menus_on_order_change/+merge/128243
[13:53] <Mirv> Trevinho: creating a R branch for bamf as well now
[13:55] <tsdgeos> does anyone know who should i ask about hints to where to start looking for https://bugs.launchpad.net/indicator-sound/+bug/1029219 ?
[13:59] <Mirv> Trevinho: done
[14:14] <Trevinho> Mirv: thanks
[14:15] <Trevinho> tsdgeos: could you add to your WaitUntil the extra bool parameter as the one I've pasted to you? So it can be used to check both functions returning false and true
[14:17] <Trevinho> tsdgeos: for the rest is fine now :)
[14:18] <Trevinho> tsdgeos: the last thing it would be using glib::Object to handle session and DBusIndicators::Ptr for the indicators (so you can avoid also the TearDown()) method, but this is optional :)
[14:20] <tsdgeos> ok, let me try that
[14:24] <tsdgeos> Trevinho: if i do that i have to make the setup not create them the second time setup is called, no?
[14:24] <Trevinho> no...
[14:25] <Trevinho> tsdgeos: gtest does for every test -> Constructor() -> Setup() -> Test() -> TearDown()
[14:25] <tsdgeos> right
[14:25] <tsdgeos> but if i have no teardown
[14:25] <Trevinho> (and ~dtor)
[14:25] <tsdgeos> and just a smart pointer
[14:25] <tsdgeos> ah
[14:25] <Trevinho> the destructor will do that
[14:25] <tsdgeos> it destructs the test class too?
[14:25] <tsdgeos> ok
[14:25] <Trevinho> yes
[14:26] <Trevinho> tsdgeos:  fyi also std::bind will work other than sigc::mem_fun (http://pastebin.ubuntu.com/1267338/), but they're fine as well
[14:27] <tsdgeos> ok
[14:40] <tsdgeos> Trevinho: param + smart pointers added
[14:41] <Trevinho> tsdgeos: cool, thanks... Approved!
[14:47] <tsdgeos> Trevinho: now should this be added to precise and quantal at least, no?
[14:49] <Trevinho> tsdgeos: not directly, to get that you need to provide branches for unity-6.0 (should be easy) and unity-5.0 (it could probably be more difficult, due to changed code)
[14:50] <tsdgeos> sure, i meant if you'll accept patches for those
[14:50] <tsdgeos> sorry for being unclear
[14:58] <Trevinho> tsdgeos: yes, sure
[15:03] <Trevinho> tsdgeos: I've assigned to you the bug for the other series
[15:03] <tsdgeos> great thanks
[15:04] <Trevinho> sil2100: did you get my ping last week about backporting this to precise: https://bugs.launchpad.net/bamf/+bug/1026426?
[15:07] <sil2100> Trevinho: one moment ;)
[15:07] <sil2100> Ah, yes
[15:08] <sil2100> We're expecting this one even - we had a talk about how nice it would be to have for an SRU
[15:09] <sil2100> Trevinho: last week was a really busy time...
[15:09] <Trevinho> sil2100: yeah, I know, don't worry :)
[15:10] <sil2100> Trevinho: is it possible to get it ported easily?
[15:11] <Trevinho> sil2100: very easily: https://code.launchpad.net/~3v1n0/bamf/libbamf-safer-factory-rematch-2.0/+merge/128518
[15:11] <sil2100> Trevinho: awesome!
[15:12] <Trevinho> sil2100: ups, that MR is not valid... need to change the target branch, but it's just one line btw
[15:14] <Trevinho> sil2100: this is good https://code.launchpad.net/~3v1n0/bamf/libbamf-safer-factory-rematch-2.0/+merge/128519
[15:57] <Dude-man> Hey guys... I'm trying to understand how the HUD is implemented... so developers don't have to make changes to their code... can anyone point to the souce, generally to start looking ? Thanks
[16:02] <tsdgeos> Trevinho: mmrazik: any idea what this error means ? https://jenkins.qa.ubuntu.com/job/automerge-unity/1502/console
[16:03] <tsdgeos> Trevinho: mmrazik: oh wait i was looking at the wrong place
[16:03] <Trevinho> tsdgeos: that log seems related to packaging issues
[16:03] <tsdgeos> no no
[16:03] <tsdgeos> /tmp/buildd/unity-6.8.0+bzr2814stagingfutureubuntu0+793/plugins/unityshell/src/unityshell.cpp:2462:31: error: base operand of '->' has non-pointer type 'unity::WindowManager'
[16:04] <tsdgeos> that doesn't seem to be "mine"
[16:04] <tsdgeos> as in caused by my patch
[16:04] <tsdgeos> but i'll merge and push
[16:09] <tsdgeos> Trevinho: wops, actually that line also fails to build here, any idea how that happened?
[16:10] <Trevinho> tsdgeos: merge with trunk...
[16:10] <Trevinho> or...
[16:11] <tsdgeos> i did merge with trunk
[16:11] <tsdgeos> that's actually what broke it :D
[16:14] <Dude-man> Anyone know anything about HUD ?
[16:15] <Trevinho> tsdgeos:  ah, ok... tests were compiling fine
[16:15] <tsdgeos> anyhow, eod here, next try tomorrow if master compiles :-)
[16:21] <davmor2> Dude-man: probably best to just ask
[16:23] <Dude-man> davmor2, How da mean ?
[16:23] <Dude-man> davmor2, I'm trying to find out how the HUD is working... internally ? just wanted to scratch an itch
[16:24] <ricotz> Trevinho, some more things ;) http://paste.debian.net/plain/197758
[16:24] <Dude-man> I'm looking to find which souce files to start with... I'm on archive.ubuntu.com looking through packages etc but if anyone has a quick answer to a dev doc or something It would help
[16:25] <Trevinho> ricotz: ok, MR it! ;)
[16:25] <ricotz> Trevinho, i am not sure about bamf_tab_source_get_tab_preview though
[16:26] <ricotz> especially the element-type
[16:26] <Trevinho> ricotz: it should basically return the thumbnail of the webpage referred by the tab
[16:26] <ricotz> Trevinho, so the garray constain actual pixel-data in some format
[16:27] <ricotz> *contains
[16:30] <Trevinho> ricotz: yes, but the format depend on unity_webapps_context_request_preview
[16:30] <Trevinho> so it's libunity-webapps thing, I don't know the internals
[16:33] <ricotz> Trevinho, i see, so i hope transfer-none is the right thing to do here, otherwise it will leak like hell
[16:42] <ricotz> Trevinho, https://code.launchpad.net/~ricotz/bamf/annotation-fixes/+merge/128544
[17:14] <Trevinho> ricotz: i think no one will be affected, since the tab_preview is not implemented by any tab-source method yet
[17:14] <Trevinho> ricotz: you know one thing you could help? :)
[17:24] <ricotz> Trevinho, heh, i see ;)
[17:37] <Trevinho> ricotz: I meant... We have an issue with the build system: it does not deletes the generated .c files on make dist(check)...
[17:37] <Trevinho> ricotz: and this is not a good thing when making tarballs...
[17:38] <Trevinho> ricotz: would you like to look fix that? :)
[17:40] <ricotz> Trevinho, so you dont want to ship the generated files at all?
[17:40] <Trevinho> ricotz: yes, no generated file should be kept
[17:40] <ricotz> seems easy to fix
[17:42] <ricotz> Trevinho, i will take a look later or tomorrow
[17:43] <ricotz> this reminds me too of the messy .bzrignore file ;)
[17:54] <Trevinho> ricotz: yeah, we have lots of things to clean... :)