=== morphis is now known as morphis|away
=== morphis|away is now known as morphis
[09:32] <tsdgeos> Trevinho: https://bugs.launchpad.net/unity/+bug/1067357 was commited to 6.0 too but does not have the "6.0" subitem in the bug, can i fix that (can't find how to do it) or does that need one of you guys?
[09:32] <ubot5> Ubuntu bug 1067357 in unity (Ubuntu) "Top panel shows "Tauler d&apos;inici" instead of "Taluer d'inici"" [Low,Triaged]
[10:33] <MCR1> duflu, smspillaz: Hi :) Just wanted to say thanx a lot 4 all the reviews. Good to see those fixes in trunk 8-).
[10:34] <duflu> MCR1: No worries.
[10:34] <duflu> And good night
[10:37] <MCR1> sil2100: Hi :) I bet you know where I can check out those Ubuntu specifix distro-patches (*.patch) files that get applied to lp:compiz and change some of the .xml.in files for example...
[10:37] <MCR1> *specific
[10:38] <popey> MCR1, apt-get source <packagename> and look in debian/patches ?
[10:39] <MCR1> popey: I do not know the source of them
[10:39] <sil2100> MCR1: hi!
[10:39] <MCR1> hey
[10:40] <sil2100> MCR1: for compiz it's either lp:ubuntu/compiz or lp:~compiz-team/compiz/ubuntu
[10:40] <sil2100> MCR1: these are the distro packaging branches for R
[10:40] <MCR1> sil2100: Thanks a lot - gotta investigate how this all deb assembly for Compiz exactly works - hard to do without knowledge of those...
[10:41] <MCR1> sil2100: Seems to be a complicated process ;) (for compiz/unity) at least...
[10:47] <sil2100> MCR1: well, theoretically the 2 branches I gave you the links to are ready for creating a package - every time there is a compiz release made, we merge in the respective trunk into it and modify the packaging
[10:47] <sil2100> MCR1: but this will change pretty soon
[10:47] <sil2100> So no need to familiarize yourself here ;)
[10:48] <MCR1> sil2100: I just had this problem that for example expo.xml.in gets *tuned* and *upgraded* for Ubuntu only by applying a *.patch file to it
[10:50] <MCR1> sil2100: This adds options like "X Space", "Y Space" and"Selected Color" to the CCSM tab and also seems to have to change the code itself...
[10:50] <MCR1> sil2100: These options are nowhere to be found in lp:compiz...
[10:50] <MCR1> sil2100: Nor is the code responsible for them...
[10:52] <MCR1> sil2100: See the failure here for example: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1009592-and-1074487-expo-xml-tooltip-fixes/+merge/132754
[10:53] <MCR1> sil2100: The console says: Applying patch 100_expo_layout.patch - patching file plugins/expo/expo.xml.in
[10:53] <MCR1> patching file plugins/expo/src/expo.cpp
[10:53] <MCR1> patching file plugins/expo/src/expo.h
[10:54] <MCR1> sil2100: so important to find those patches to be able to analyze their code - quite a few of them get applied... :)
[11:01] <MCR1> Also - this seems to be a Jenkins failure: https://code.launchpad.net/~mc-return/compiz/compiz.merge-shiftswitcher-one-if-statement-is-enough/+merge/132516
[11:02] <MCR1> It would be nice if someone could reapprove it...
[11:04] <sil2100> MCR1: re-approved, that seemed to be an architecture failure
[11:04] <MCR1> sil2100: yep, thx :)
[11:05] <MCR1> sil2100: Although even better optimization is possible, maybe another commit ;)
[11:05] <MCR1> (probably)
[11:06] <sil2100> Too late!
[11:06] <MCR1> hehe
[11:06] <MCR1> its never too late...
[11:06] <MCR1> ;)
=== MacSlow is now known as MacSlow|lunch
=== MacSlow|lunch is now known as MacSlow
[13:55] <mhall119> mhr3: ping me when you're around
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== _salem is now known as salem_
[14:45] <mhr3> mhall119, sup
[14:48] <mhall119> mhr3: hey, we're going to need a way to send scheduling data for TV programs from a Scope to the Dash
[14:49] <mhall119> which afaik is going to require an extension to the current API
[14:51] <mhr3> mhall119, there was a talk about this earlier, but yea no work done on it really
[14:53] <mhall119> mhr3: what should we do to propose an API change?
[15:10] <conscioususer> tedg: ping
[15:10] <conscioususer> Trevinho: ping
[15:11] <tedg> Howdy
[15:11] <conscioususer> hi Ted
[15:12] <conscioususer> tedg: I seem to be experiencing two bugs with the unity menubar
[15:13] <conscioususer> tedg: particularly when using GMenu in my app
[15:13] <conscioususer> first one is lack of mnemonics, as I wrote here: https://plus.google.com/u/0/115076883960566547239/posts/BYNdKZ5rQtW
[15:14] <conscioususer> second is that the menu items do not seem to always work... clicking on them have no effect
[15:14] <tedg> conscioususer, Yeah, the mneumonics don't work with GMenu. It doesn't support them, we have a work around, but it isn't complete.
[15:14] <conscioususer> is there a work around for app devs?
[15:14] <tedg> conscioususer, I don't know about the second one... is it reproducable in any way?
[15:15] <tedg> conscioususer, Not really, the problem is that GMenu doesn't support any communication from the app to the menubar.
[15:15] <conscioususer> (about the 2nd) seems random :-/ sometimes the menu works, sometimes it does not and I need to restart the app
[15:15] <conscioususer> and when it does not work, the interesting thing is that the actions are accessible via HUD!
[15:15] <tedg> conscioususer, Hmm, interesting.  I mean they're different pathways, so that would make sense.
[15:16] <tedg> conscioususer, I haven't see that... not sure how we'd track it down.
[15:18] <conscioususer> tedg: from my experience, does not seem to be rare
[15:19] <conscioususer> tedg: if I close and reopen my app some times, it does not take long until I experience it
[15:19] <conscioususer> tedg: I'll try to write a mini-example
[15:19] <conscioususer> tedg: about the first issue, if you complete the fix will it be backported to precise?
[15:20] <tedg> conscioususer, Uhm, precise I'm not 100% sure.  I think Quantal would be reasonable for sure.
[15:21] <conscioususer> tedg: hmm, I see
=== salem_ is now known as _salem
[15:25] <conscioususer> tedg: ok, i'll work on the example and brb, thanks so far
=== _salem is now known as salem_
[15:58] <Trevinho> conscioususer: just read...
[16:58] <conscioususer> tedg: still there? I finished the example
[16:58] <tedg> conscioususer, Ah, cool!
[16:58] <tedg> conscioususer, Bug number?
[16:59] <conscioususer> tedg: I didn't file one, I want to make sure I'm not doing something wrong as an app dev first
[17:00] <conscioususer> tedg: http://www.pasteshare.co.uk/p/3dp/
[17:00] <conscioususer> tedg: it's quite minimal, an empty window and an app menubar with a quit item
[17:01] <conscioususer> tedg: if I start the app and quit it repeatedly, sometimes the quit menuitem doesn't work
[17:01] <conscioususer> tedg: via mouse, i mean... the accelerator seems to always work
[17:02] <conscioususer> tedg: I'm on quantal
[17:02] <tedg> conscioususer, Ah, cool.  Have you tried activating the action via dbus and see if that works?
[17:03] <conscioususer> can you give me a one-liner to test that?
[17:03] <conscioususer> never did this before... :P
[17:04] <larsu> conscioususer, you definitely don't want to call gtk_main in the activate handler
[17:04] <larsu> if you're using GtkApplication, call gtk_application_run in your main
[17:06] <conscioususer> larsu: I had some problems with doing this in the past...
[17:07] <tedg> conscioususer, I think this should work: gdbus call --session --dest org.gnome.test --object-path /org/gnome/Test --method org.gtk.Actions.Activate 'app.quit' [] []
[17:08] <jjohansen> is the regression of the window manager not working after the latest update already known?
[17:08] <conscioususer> tedg: I had to rename Test to test, but even so it didn't work
[17:08] <conscioususer> tedg: didn't give any error messages either
[17:08] <tedg> conscioususer, Hmm, larsu, does that command line look right to you?
[17:11] <larsu> tedg, conscioususer, it's missing parameters: gdbus call --session --dest org.gnome.test --object-path /org/gnome/test --method org.gtk.Actions.Activate 'quit' [] {}
[17:11] <tedg> bregma, Are you guys seeing a regression? ^
[17:11] <larsu> also app.quit --> quit
[17:12] <conscioususer> tedg larsu hey, it works
[17:12]  * tedg bitches about the combining of the data in the action name again...
[17:12] <conscioususer> tedg larsu even when the clicking on the item is not working, the command line works
[17:12] <tedg> larsu, Thanks!  :-)
[17:12] <tedg> conscioususer, Ah, okay, so then it's not your app, it's a bug in indicator-appmenu.
[17:14] <conscioususer> tedg: whew :)
[17:14] <conscioususer> tedg: for the record, also happening in Precise, tested via Virtualbox
[17:15] <larsu> same problem on quantal
[17:15] <larsu> conscioususer, still, you shouldn't use gtk_main and gtk_main_quit when you're using gtkapplication
[17:15] <larsu> I'll paste you an updated version of your program in a bit
[17:16] <conscioususer> larsu: thanks... use the "fork this", one of the cool things in pasteshare :)
[17:18] <larsu> conscioususer, http://www.pasteshare.co.uk/p/3dq/
[17:18] <larsu> it creates the actions and menu in startup (so that it's only called once)
[17:18] <larsu> also, it uses g_application_run and g_application_quit
[17:19] <larsu> also, no need to connect to the destroy event of the window anymore, gtkapplication exits by itself if no windows are visible anymore
[17:19] <conscioususer> larsu: visible or non-destroyed?
[17:19] <larsu> conscioususer, sorry, destroye
[17:19] <larsu> destroyed
[17:20] <larsu> once more for clarity: it exits when all windows are destroyed :)
[17:20] <conscioususer> larsu: got it :)
[17:21] <conscioususer> larsu: where do I put a code to raise a window if the application isn't the primary instance?
[17:22] <larsu> conscioususer, in activate
[17:22] <larsu> right now, the activate always creates a new window
[17:22] <larsu> what you probably want is a call to gtk_window_present if there's already a window floating around
[17:23] <conscioususer> does get_is_remote works inside activate?
[17:23] <larsu> no, activate is always called on the primary instance
[17:24] <conscioususer> then how do I know if I should raise the existing window or go through the initialization process?
[17:25] <larsu> ask the app if it already has a window with gtk_application_get_windows
[17:25] <larsu> if yes, present that window
[17:25] <larsu> if no, create a new one
[17:27] <conscioususer> all this inside activate?
[17:27] <larsu> yep
[17:28] <larsu> http://www.pasteshare.co.uk/p/254/
[17:30] <conscioususer> larsu: awesome, thanks!
[17:32] <larsu> conscioususer, yw. GApplication docs have pretty good explanation of how it all fits together: http://developer.gnome.org/gio/stable/GApplication.html#GApplication.description
[17:32] <larsu> same for GtkApplication: http://developer.gnome.org/gtk3/stable/GtkApplication.html#GtkApplication.description
[17:35] <conscioususer> larsu: yeah, but iirc they don't cover very well handling already opened apps
[17:40] <conscioususer> larsu: btw, what's the difference between startup and activate?
[17:41] <larsu> conscioususer, startup is called once on the primary instance, activate is called on the primary instance every time the application is started again
[17:41] <larsu> i.e. activate is the "ping" by the remote instances
[17:42] <conscioususer> larsu: I think I'm finally getting the main picture, thanks
[17:42] <larsu> conscioususer, sure :) Let me know if you have more questions
[17:43]  * larsu is trying to find that menu bug in the mean time... :(
[17:43] <conscioususer> larsu: so shouldn't the main window be created during startup?
[17:46] <larsu> conscioususer, hm, I've never seen this but it certainly makes more sense
[17:47] <conscioususer> larsu: if I understood correctly being inside activate means being inside the lifecycle of the app
[17:48] <conscioususer> so it makes sense that when activate starts, windows already exist
[17:52] <larsu> conscioususer, well, some apps might not want to create windows in all circumstances (e.g. when handling command line arguments)
[17:53] <conscioususer> larsu: ok, makes sense
[17:54] <conscioususer> larsu: ok, I have to go now... should I file bug for the menu thing or someone else is on it alread?
[17:54] <conscioususer> *already
[17:54] <larsu> conscioususer, please file a bug (I can do it though if you're in a hurry)
[17:55] <conscioususer> in unity?
[17:55] <larsu> indicator-appmenu
[18:05] <conscioususer> larsu: https://bugs.launchpad.net/ubuntu/+source/indicator-appmenu/+bug/1075263
[18:05] <ubot5> Ubuntu bug 1075263 in indicator-appmenu (Ubuntu) "Items of a menubar built from GMenu do not always work" [Undecided,New]
[18:05] <larsu> conscioususer, thanks!
[18:05] <conscioususer> larsu: will be watching the progress with great interest, obviously :) anything I can do to help, lemme know
[18:06] <larsu> will do :)
=== francisco is now known as Guest6263
[19:01] <ricotz> Trevinho, hi :), i hope you noticed the two bamf merge proposals?
[19:10] <Trevinho> ricotz: hey, yes.. not checked btw yet :)
[19:13] <ricotz> Trevinho, alright ;)
[19:14] <Trevinho> ricotz: for the user visible thing, could you please do an unity branch that replaces them as well? :)
[19:16] <ricotz> Trevinho, hmm, not really :\
[19:19] <ricotz> Trevinho, btw the inline-debian patch isnt really complete since it is missing 0.3.4
[19:22] <Trevinho> ricotz: rigth
[19:22] <Trevinho> right*
=== salem_ is now known as _salem