[03:58] <jono> smspillaz, you around?
[04:58] <smspillaz> jono: not really, whats up ?
[05:09] <jono> smspillaz, just noticing a lot of Compiz crashes over the last few days
[05:43] <didrocks> good morning
[05:44] <smspillaz> jono: crashes in unity or compiz?
[05:44] <smspillaz> jono: remember that if unity crashes compiz goes with it :)
[05:45] <jono> smspillaz, I suspect maybe Unity
[05:45] <smspillaz> ok :)
[05:45] <jono> but surely compiz should survive a unity crash?
[05:45] <smspillaz> jono: nope
[05:45] <jono> why not?
[05:45] <smspillaz> jono: it's a plugin that's loaded at runtime and runs inside the compiz process
[05:45] <jono> right, but doesn't compiz provide safeguards for bad plugins?
[05:45] <smspillaz> jono: it's impossible
[05:45] <jono> a shitty GEdit plugin doesnt take down GEdit :-)
[05:46] <jono> right
[05:46] <smspillaz> GEdit plugins are written in python which provide exception safety
[05:46] <smspillaz> compiz plugins are in C++
[05:46] <jono> I am just noticing random crashes
[05:46] <jono> I filed a few bugs, particularly when apport caught them
[05:46] <jono> but it feels like stability took a hit since the last Unity update
[05:46] <smspillaz> if you mess up and cause a segmentation fault in C++ attempting to handle the signal results in undefined behaviour
[05:47] <smspillaz> jono: we'll get on to them don't worry :)
[05:47] <jono> gotcha
[05:47] <jono> thanks smspillaz
[05:47] <jono> you guys are doing a great job
[05:47] <smspillaz> np
[05:47] <jono> :-)
[05:47] <smspillaz> oh
[05:47] <smspillaz> and
[05:47] <smspillaz> I fixed the stacking bug YAY
[05:47] <smspillaz> gosh that was a nightmare
[05:47] <smspillaz> let us never speak of that again
[05:48] <jono> haha nice!
[07:54] <oSoMoN> good morning
[07:58] <Saviq> hello
[09:26] <Andy80> hi
[09:27] <ephan> hey Andy80
[09:32] <Andy80> Kaleo: let's suppose I've to add and manage a double click event to the Unity-2D panel. Is it better to add it here: http://bazaar.launchpad.net/~unity-2d-team/unity-2d/oneiric/view/head:/panel/applets/appname/appnameapplet.cpp or here http://bazaar.launchpad.net/~unity-2d-team/unity-2d/oneiric/view/head:/libunity-2d-private/src/unity2dpanel.cpp ? I'm trying to fix this bug #736491
[09:32] <Andy80> nerochiaro: question valid for you too ^_^ p.s: good morning :)
[09:44] <Kaleo> Andy80: good morning
[09:44] <Andy80> Kaleo: good morning :)
[09:45] <Kaleo> Andy80: http://bazaar.launchpad.net/~unity-2d-team/unity-2d/oneiric/view/head:/panel/applets/appname/appnameapplet.cpp
[09:56] <Andy80> Kaleo: uhm... I tried to do it, but even if AppNameApplet is a Unity2dPanel (that is a QWidget itself), it looks like it doesn't have the mouseDoubleClick event :\ I try to committ+push the code so you can see better...
[10:02] <Kaleo> Andy80: ok
[10:07] <Andy80> Kaleo: here you have http://bazaar.launchpad.net/~andreagrandi/unity-2d/panel-doubleclick-bug-736491/revision/715
[10:07] <Andy80> ubot5: shut up! :P
[10:10] <Saviq> Andy80: I'm actually trying to get back on https://bugs.launchpad.net/unity-2d/+bug/661049 - maybe we should join forces
[10:12] <davidcalle> Hi kamstrup, is "model.flush_revision_queue()" in lenses supposed to work ? Doesn't seem to do anything from a python lens.
[10:13] <kamstrup> davidcalle: whether it does anything depends a bit on how it's invoked :-)
[10:13] <kamstrup> davidcalle: Dee.SharedModel will send all changes on DBus when ever control returns to the mainloop
[10:14] <kamstrup> so if you very often return to the mainloop chances are that it does nothing because the revision queue has already been send
[10:14] <Andy80> Saviq: sure! If you already have some code please push it. It should be just a matter of fixing what I've already written, maybe I've defined it in the wrong place. Unmaximizing the window is easy, we can use the WindowHelper class. I just need to understand how to manage the double click properly :P
[10:14] <kamstrup> davidcalle: but if you do some blocking IO scanning 1000 files building a model without ever going out to the mainloop unity wont see the changes before all 1000 items has been added
[10:15] <kamstrup> davidcalle: so if you want to notify unity after the first 50 has been added and then later send the rest of the 950 rows then insert a flush_revision_queue() after 50 items
[10:15] <kamstrup> this will increase the responsiveness the user experiences in the dash
[10:16] <kamstrup> but is not strictly necessary
[10:16] <kamstrup> just changes how fast changes are propagated to unity
[10:16] <Andy80> Kaleo: p.s: the error I get is this one: unity-2d-panel: [WARNING] Object::connect: No such signal AppNameApplet::mouseDoubleClickEvent(QMouseEvent*) in /home/andrea/Documents/development/unity-2d-panel-doubleclick-bug-736491/panel/applets/appname/appnameapplet.cpp:208
[10:17] <davidcalle> kamstrup, I'm adding a flush_revision_queue after populating the model with a part of the sources I'm querying. But I could be doing it wrong.
[10:18] <kamstrup> davidcalle: so if you're updating you model by looping over some data set, then calling flush_rev_q(), and returning control to the mainloop - then it doesn't make a difference
[10:19] <Saviq> Andy80: take a look at my merge request here https://code.launchpad.net/~saviq/unity-2d/unmaximize-on-drag/+merge/61028
[10:19] <kamstrup> davidcalle: as the rev queue will be flushed anyway automatically
[10:19] <Kaleo> Andy80: AppNameApplet is not a QWidget
[10:19] <Saviq> Andy80: I got it working more or less, but had to refactor it and never got to it in the end until today
[10:20] <Kaleo> Andy80: scrap that
[10:20] <Kaleo> Andy80: I am talking crap
[10:20] <Saviq> Andy80: and since there was some changes in unity-2d since that time, it needs to be rewritten a bit
[10:20] <Kaleo> Andy80: it seems Saviq is _the_ person to talk to on this particular topic :)
[10:21] <Saviq> see Aurelien's comments on that mr, too
[10:21] <davidcalle> kamstrup, thanks for the explanation.
[10:21] <Saviq> https://bugs.launchpad.net/bugs/735205 is sooo annoying...
[10:21] <Andy80> Kaleo: ok let me give a look to his merge request :)
[10:24] <Andy80> Saviq: oh you're also managing thr drag event... mmmm.... well it's out of my knowledge then :P I see too much code... I mean, I did think it was just a matter of managing the doubleclick and use the unmaximize() method of WindowHelper but maybe is more complicated. I'll drop my branch then, is it ok?
[10:25] <Kaleo> Saviq: it shall be your first bug fix ;)
[10:25] <Saviq> Kaleo: hopefully
[10:26] <Saviq> Andy80: yeah, drags are a bit more complicated, but what you can do to speed things up, is find where it's best to hook up to the events in the new codebas
[10:26] <Saviq> e
[10:27] <Saviq> where I _think_ the events should go is the MenuBarWidget usually, and sometimes the label, when there is no menubar due to incompatibility
[10:28] <Andy80> Saviq: but you cannot doubleclick the menu usually.... at least on Unity 3D you cannot... you have to double click in the zone not covered by window title or menu
[10:28] <Saviq> Andy80: yes, but that's still the MenuBarWidget, AFAIK
[10:29] <Andy80> Saviq: so why did you modify the appnameapplet.cpp ?
[10:29] <Saviq> but I might be wrong in that, and need to find that out to get that working
[10:30] <Saviq> Andy80: because the MenuBar is initialized there and also to handle the other case - when there's no menu bar
[10:30] <Andy80> Saviq: first obvious question: is your code working or is it just a concept?
[10:30] <Saviq> it was working
[10:30] <Andy80> ok
[10:30] <Saviq> back in 3.0
[10:30] <Saviq> it needs rewriting now and finding a better place to handle the events
[10:32] <Andy80> Saviq: we can have a single SLOT, but if appname and appmenu are two separate widget we need to catch both doubleclick events, we cannot do it just in one of two
[10:32] <Saviq> Andy80: yes, and that's where the mentioned eventFilters come in
[10:33] <Andy80> Saviq: oh, I missed it, sorry :) let me read the code better...
[10:33] <Saviq> we need a separate class, say TitleBarHelper, that will implement eventFilter(QObject *, QEvent *)
[10:33] <Saviq> Andy80: read Aurelien's comments first
[10:34] <Saviq> that filter will then get installEventFilter()ed on the relevant widgets
[10:34] <Saviq> and that should be it
[10:48] <Andy80> Saviq: I'll give it a look better after lunch :)
[10:49] <Saviq> k
[10:53] <Kaleo> apinheiro: https://bugs.launchpad.net/unity-2d/+bug/846441 any idea?
[10:53] <apinheiro> Kaleo, reading
[10:54] <apinheiro> Kaleo, ups
[10:54] <apinheiro> Timeout error
[10:54] <apinheiro> Sorry, something just went wrong in Launchpad.
[10:54] <apinheiro> well, it seems that I can read it
[10:55] <apinheiro> Kaleo, unity-2d uses the panel-service as well?
[10:55] <Kaleo> apinheiro: yes
[10:55] <apinheiro> so the a11y support there is the one implemented at unity,right?
[10:55] <Kaleo> apinheiro: I did not mean to ping you actually :)
[10:55] <apinheiro> Kaleo, ;)
[10:55] <apinheiro> ok
[10:55] <Kaleo> apinheiro: for the panel yes :)
[10:56] <Kaleo> Trevinho: https://bugs.launchpad.net/unity-2d/+bug/846441 any idea?
[10:56] <apinheiro> so then I will forgot that, and going lunch
[10:56] <Kaleo> apinheiro: disfruta
[10:56] <apinheiro_lunch> Kaleo, thanks
[12:56] <mterry> smspillaz, heyo.  Last Friday we were talking about bug 732997, and you thought it may have been fixed by trunk.  I just tested, and it's not
[12:56] <mterry> smspillaz, there's a test case in the bug for ease-of-testing
[13:08] <smspillaz> mterry: hm ok
[13:08] <smspillaz> mterry: I fixed it last cycle, maybe the fix got dropped somewhere
[13:48] <hicham> any progress on upstreaming ubuntu menu proxy patch ?
[14:08] <agateau> hey, looking at bug #821290, it seems to affect unity 3d as well. Can anyone confirm this?
[14:08] <Andy80> Saviq: finally I had time to read all comments, but... I don't understand the "event filter" stuff... I mean, is there already a class in Unity-2d or is it something Qt related?
[14:08] <Saviq> Andy80: doc.qt.nokia.com/stable/eventsandfilters.html#event-filters
[14:08] <Saviq> add a http:// to that
[14:10] <Andy80> Saviq: ok, so if I understand well, from a single point you want to intercept both events for appname and menuwidget, is it right?
[14:10] <Saviq> yes, that's the idea
[14:10] <Saviq> to abstract an event handler / filter
[14:16] <Andy80> ok
[14:49] <apinheiro> jaytaoko, you here?
[14:49] <jaytaoko> apinheiro: hello
[14:49] <apinheiro> jaytaoko, hello, just a question
[14:50] <apinheiro> some time ago you added the signal:
[14:50] <apinheiro>     sigc::signal<void, BaseWindow*> sigVisibleViewWindow;
[14:50] <apinheiro> and his "hidden" equivalent
[14:50] <apinheiro> in order to know when any window is shown
[14:50] <apinheiro> but, I tried to connect to it and I don't receive anything
[14:50] <jaytaoko> apinheiro: right
[14:50] <apinheiro> after a grep on nux code
[14:50] <apinheiro> I didn't find a emission of this signal
[14:50] <apinheiro> jaytaoko, is this signal implemented?
[14:51] <jaytaoko> apinheiro: let me check...
[14:51] <apinheiro> jaytaoko, ok thanks
[14:52] <kamstrup> njpatel: at your leisure I have some review work for you :-) https://bugs.launchpad.net/ubuntu/+source/unity-2d/+bug/838023
[14:53] <kamstrup> njpatel: another fruit from the updated architecture for the lenses :-D
[14:55] <jaytaoko> apinheiro: you are right, the signals are not emitted.
[14:55] <apinheiro> jaytaoko, urgh, ok
[14:56] <apinheiro> well, I will create a bug for that
[14:56] <njpatel> kamstrup, lol, I was looking at the same bit in the .lens file thinking "damn, did I forget to port this to the new stuff?" :D
[14:56] <jaytaoko> apinheiro: however, these signals are implemented on BaseWindow themselves: sigVisible and sigHidden
[14:56] <apinheiro> and workaround that
[14:56] <apinheiro> in order to use that on the next cycle
[14:56] <apinheiro> jaytaoko, yes, but in order to use them
[14:56] <apinheiro> you need the specific BaseWindow instance
[14:56] <jaytaoko> apinheiro: right!
[14:56] <apinheiro> I wanted to use that signal to get when a new BaseWindow appears
[14:57] <apinheiro> in order to add them to the list of active windows
[14:57] <njpatel> kamstrup, oh, filters!
[14:57] <njpatel> kamstrup, ignore me
[14:57] <jaytaoko> apinheiro: I believe I can fix the problem...
[14:59] <apinheiro> jaytaoko, really? I don't want to compromise the current cycle, taking into account where we are right now
[15:00] <njpatel> kamstrup, both approved
[15:00] <jaytaoko> apinheiro: it is alright, there are just 2 lines to add... then you can be free to use the signal in this cycle if you want
[15:02] <apinheiro> jaytaoko, ok, thanks
[15:14] <jaytaoko> apinheiro: I have pushed the changes to nux trunk. You may now connect to these signals: GetWindowCompositor().sigVisibleViewWindow and GetWindowCompositor().sigHiddenViewWindow
[15:21] <apinheiro> jaytaoko, as I said Im  already connected to those signals ;)
[15:21] <apinheiro> jaytaoko, thanks
[15:21] <apinheiro> I will test them right now
[15:22] <jaytaoko> apinheiro: let me know how it goes
[15:24] <Kaleo> Trevinho: since your patch from last week in Unity 2D we get a crash regularly: https://bugs.launchpad.net/ubuntu/+source/unity-2d/+bug/846836
[15:42] <apinheiro> jaytaoko, it is working, thanks
[15:43] <apinheiro> njpatel, one question about the name on the BaseWindow
[15:43] <apinheiro> are they used?
[15:43] <apinheiro> could I use that name as the accessible name of the Window?
[15:43] <njpatel> apinheiro, sure
[15:43] <njpatel> no, not used really
[15:44] <apinheiro> njpatel, so no problem if I change the current name of the  Launcher window, right?
[15:44] <apinheiro> right now is "LauncherWindow"
[15:44] <njpatel> apinheiro, nope, DBO ?
[15:44] <apinheiro> I should also mark that name to be translatable though
[15:47] <jaytaoko> apinheiro: don't use "BaseWindow" this name could change
[15:48] <apinheiro> jaytaoko, what do you mean? I shouldn't use the class "BaseWindow" or I shouldn't use that name?
[15:48] <apinheiro> because about the class, I0m already using it
[15:48] <jaytaoko> apinheiro: I mean the name "BaseWindow" :-D
[15:48] <apinheiro> jaytaoko, ok, no problem
[15:49] <apinheiro> I want to use the name to give the window a meaningful name
[15:49] <apinheiro> something like "Panel", "Launcher" "Quicklist"
[15:49] <apinheiro> so when the window is being activated any orca user could listen "Launcher Window"
[15:49] <apinheiro> at this moment Im setting the name manually on the a11y object
[15:50] <jaytaoko> apinheiro: well you can if you want, but all I meant to say is that I have been thinking at a new name for "BaseWindow", because I don't think the name is quite right
[15:50] <apinheiro> it would be easier to just use the name from BaseWindow itself
[15:50] <apinheiro> yeah, and for the user listening "BaseWindow" should be also not really meaningful
[15:51] <jaytaoko> apinheiro: feel free to do so, nut just understand that the class name "BaseWindow" may change. but that won't affect the BaseWindow code
[15:53] <apinheiro> jaytaoko, ok thanks
[16:00] <kamstrup> lamalex: at your leisure https://code.launchpad.net/~kamstrup/unity-lens-music/sorted-filters/+merge/75030
[16:02] <kamstrup> lamalex: i wans't sure though if the current ordering was hard coded by design, so feel free to ignore - but it was definitely a bug for the apps lens :-)
[16:07] <lamalex> kamstrup, i just copied the mockups
[16:16] <apinheiro> njpatel, jaytaoko I have just realized that in the end you use the name of the basewindow
[16:16] <apinheiro> EnableInputWindow(true, "Dash",
[16:16] <apinheiro> it seems that on nux is used to know the window to activate, so I guess that also to search
[16:16] <apinheiro> could you confirm that?
[16:17] <jaytaoko> apinheiro: let me check...
[16:18] <apinheiro> the issue is that if this is true, I can't use that name, as the use case is to be shown to user
[16:18] <apinheiro> so need to be a translatable string
[16:18] <apinheiro> so I couldn't replace
[16:18] <apinheiro>   window_ = new nux::BaseWindow("Dash");
[16:18] <apinheiro> for
[16:18] <apinheiro>   window_ = new nux::BaseWindow(_("Dash"));
[16:22] <jaytaoko> apinheiro: right unity uses the name of the base window, like "Dash", "launcher"...
[16:23] <apinheiro> jaytaoko, ok, I will discard the idea of use current BaseWindow name as the accessible name then
[16:23] <apinheiro> jaytaoko, thanks
[16:24] <jaytaoko> apinheiro: however, I am not sure that latter in in the code there is a comparaison of strings to look for a BaseWindow name
[16:29] <apinheiro> jaytaoko, ok, anyway just in case, for the moment I will  not use that name
[16:29] <jaytaoko> apinheiro: I need to check with DBO...
[16:30] <DBO> I'll be here in a minute
[16:30] <apinheiro> jaytaoko, ok, anyway not a big issue right now, as normally if you open a window, usually one of the objects inside the window get the focus
[16:30] <apinheiro> the window just provide more information about the context
[16:39] <lamalex> what's the envar to set to debug glib runtime warnings/criticals?
[17:07] <Trevinho> Kaleo: I'll give a look to these bugs
[17:12] <Trevinho> Kaleo: are you already working on the bug related to the crash?
[17:14] <lamalex> can i get a review? https://code.launchpad.net/~alexlauni/unity-lens-music/846013/+merge/75044 1 line change
[18:12] <AlanBell> is there an example of a python based lens with packaging for oneiric?
[19:56] <davidcalle> AlanBell, there will be one soon. Tomorrow night I hope.
[20:01] <davidcalle> AlanBell, do you want me to point you to the branch when it's done?
[20:14] <jono> davidcalle, howdy
[20:14] <jono> how is the lens coming along?
[20:16] <davidcalle> Hey jono
[20:17] <davidcalle> Take a look http://img.ly/8fPQ
[20:18] <jono> davidcalle, nice!
[20:19] <davidcalle> I'm cleaning the code tonight, will push the branch tomorrow.
[20:19] <jono> davidcalle, sounds great!
[20:58] <AlanBell> davidcalle: that would be great
[21:25] <AlanBell> I think I am seeing a fairly major fail with the screensaver and unity, not sure who is at fault and where to file the bug
[21:26] <AlanBell> if I leave the dash open and wander off until the screensaver cuts in the dash stays on top of the screensaver and the screensaver login window is behind the dash and can't be typed in
[21:36] <jono> AlanBell, I think that would be a Unity bug
[21:39]  * AlanBell files bug 848336
[21:40] <AlanBell> why is the system settings thing not a lens?
[21:41] <davidcalle> AlanBell, I would say: because it closes after a click. IMHO it would be a pain when you want to configure different settings;
[21:43] <AlanBell> um, but it does close after a click!
[21:43] <AlanBell> oh, no it doesn't quite
[22:03] <AlanBell> the thing just looks like it should have been a lens but someone didn't get the memo