[00:00] <RAOF> kais58: gnome-session-save --logout :)
[00:00] <RAOF> (Unity *is* a GNOME session ☺)
[00:01] <kais58> but does it report as gnome or unity in $DESKTOP_SESSION?
[00:03] <kais58> ok, thanks theres something else wrong with this script then
[00:04] <kais58> oh, and another thing, is it possible to lock the menu bar?
[00:09]  * RAOF is not sure what you mean by “menu bar”
[00:09] <hicham> how to get the menus on the panel ?
[00:09] <RAOF> hicham: As in the global menu bar?
[00:10] <hicham> RAOF: show the menu bar on the panel
[00:10] <hicham> RAOF: yes
[00:10] <hicham> RAOF: how do I enable that ?
[00:10] <kais58> the thing on the left that slides out
[00:11] <RAOF> kais58: That's referred to as “the launcher”, and you can change its autohide behaviour in CompizConfig Settings Manager - look for the Unity plugin.
[00:11] <hicham> RAOF: I installed indicator-application, but no go
[00:12] <RAOF> hicham: From memory, you need a GTK patch to enable the functionality, have a GTK module loaded to actually export the menus, and then there's something like a unity-panel-service on the other end to draw them in unity.
[00:13] <hicham> RAOF: where can I find that patch ?
[00:13] <RAOF> In Ubuntu's GTK packages, certainly; I'm not sure where else.
[00:14] <hicham> so only gtk software can draw the menu on the panel ?
[00:18] <RAOF> hicham: No, I believe Qt can too.
[00:18] <RAOF> hicham: I don't think athena apps can, though :)
[00:19] <hicham> RAOF: are you a unity dev ?
[00:19] <RAOF> No.
[02:29] <Th3Pr0ph3t> Greetings, I think I have discovered a way to make compiz crash like crazy...
[02:30] <Th3Pr0ph3t> Opening ccsm: Window Decorations
[02:30] <Omega> Submit a bug report.
[02:30] <Th3Pr0ph3t> sure ^_^
[02:32] <hicham> just enable/disable Window Decorations ?
[02:35] <RAOF> There's a known crasher when enabling or disabling plugins with the Unity plugin loaded (that's really annoying!)
[02:35] <Th3Pr0ph3t> no, I was explaining but yes, a bug report is more reasonable
[02:36] <Th3Pr0ph3t> so I'll report a bug (what was I thinking :$)
[02:38] <aquarius> RAOF, heya. I just wanted to let you know; since upgrading yesterday to the latest everything, the compiz hanging in __poll problem has got a lot, lot worse -- compiz has hung, needing killing, fourteen times today so far :(
[02:39] <RAOF>  !!!
[02:40] <aquarius> yeah. It's, shall we say, quite annoying :)
[02:40] <RAOF> aquarius: :(.  DBO worked around one extremely common manifestation of that bug.
[02:40] <aquarius> it *seems* to be related to new windows opening, or chromium, or both, but I don't have any real evidence for that
[02:41] <RAOF> Well, I'm gdb-ing both sides of the compiz/X connection; hopefully that'll provide a useful pointer.
[02:41] <RAOF> The testcases that I've tried to build haven't managed to reproduce the problem so far.
[02:42] <aquarius> cool. I was in two minds about whether to mention it, since I don't have anything useful to add other than just to be whiny about it, but I thought you might want to know :)
=== yofel_ is now known as yofel
[03:02] <DBO> RAOF, howdy
[03:03] <RAOF> DBO: Hey, ho.  Sigh.
[03:03] <DBO> i am not a ho
[03:04] <DBO> RAOF, any luck?
[03:18] <RAOF> DBO: Appologies.  The OOM killer decided to wander in.
[03:18] <DBO> its okay
[03:18] <DBO> so, any luck?
[03:19] <RAOF> DBO: Not just yet, sorry.
[03:19] <RAOF> GAH!  Stupid damned “value optimized out”
[03:20] <DBO> cant you compile it to not do that?
[03:20] <DBO> -O0
[03:36] <DBO> RAOF, do you have any theories?
[03:41] <RAOF> My current theory is that (one of) compiz's Xserver client is being throttled by the server, possibly pending a reply on one of compiz' other clients.
[03:42] <DBO> why would the server throttle compiz?
[03:42] <RAOF> Compiz does a bunch of DRI2 stuff that results in a client getting throttled.
[03:42] <RAOF> As in: by *design* a bunch of the DRI2 calls throttle the client until $CONDITION.
[03:42] <RAOF> Things like DRI2WaitMSC, for example.
[03:43] <RAOF> But!  That should only effect that particular connection, not compiz' other connections.
[03:44] <DBO> well are we sure the hang happens on non-compiz connections?
[03:44] <RAOF> As in: on compiz' gtk connection?
[03:44] <DBO> yeah
[03:45] <DBO> how do you know which connection is what?
[03:45] <RAOF> By the magic of printf "Connection: %p",dpy :)
[03:46] <RAOF> But you're right; that doesn't make it clear whether it's GTK's connection or not.
[03:46] <RAOF> But I believe maximise hang *was* gtk's connection, because it was going through gdk_do_stuff.
[03:46] <DBO> yeah but how many connections were you seeing
[03:47] <DBO> I hear rumors that gtk actually grabs the "default connection"
[03:47] <DBO> which I didn't even know what possible
[03:47] <RAOF> Oh.
[03:47] <RAOF> I was *seeing* 2 connections.
[03:48] <DBO> you were only ever seeing 2 connections?
[03:48] <DBO> i mean the compiz one should be easy to spot
[03:48] <DBO> it does fuckloads of stuff
[03:49] <RAOF> Right.
[03:49] <RAOF> I was only checking in the Undecorate() case, so I could have missed one of the connections.
[03:52] <DBO> ah
[03:56] <DBO> RAOF, is it possible that the dri2 call throttles ALL x calls until some other call is made?
[03:59] <RAOF> A quick bit of gdberry says: yes, compiz has at least 3 display connections.
[04:00] <RAOF> DBO: Yes and no.  It *does* throttle all X calls *made by that client* , but compiz has 3 distinct clients happening.
[04:01] <RAOF> (One X client per X connection)
[04:02] <DBO> well thats weird
[04:03] <RAOF> That's not exactly been an uncommon phrase :)
[04:08] <DBO> RAOF, look if you have managed to find internet in the sunken continent of Australia, I am sure you can find this bug :)
[04:08] <RAOF> Yeah.  Let's play ‘watch the X server and compiz at the same time to match up display connections!’
[04:09] <RAOF> This will be *fun*!
[04:09] <DBO> this is a team activity
[04:09] <DBO> we need to get this up on a projector
[04:09] <DBO> and then do it that way :P
[04:10] <soreau> Can anyone running compiz/unity test amsn? Another user showed it crashes compiz on opensuse 11.4 and it happens here too on maverick
[04:11] <soreau> It crashes compiz, then after restarting compiz, the windows are the smallest they can be, like a vertical line the height of the decorator
[04:11] <soreau> Here is his backtrace http://pastebin.com/Q64yxcdC
[04:12] <soreau> And the one I get here http://sprunge.us/YURQ
[04:13]  * RAOF breaks out the notepad to keep track of display connections.
[04:13] <soreau> I was wondering if there's any other apps that use wish to test with, but I couldn't google it because 'wish' is a really bad name for a program :P
[04:14] <soreau> Does this happen on natty too? (I'm about to test)
[04:28] <RAOF> Wow.  How many connections does compiz actually open!
[04:38] <DBO> RAOF, i dont know
[04:38] <DBO> should be 1
[04:38] <DBO> then 1 for nux
[04:38] <DBO> then 1 for gdk
[04:39] <RAOF> Starting compiz seems to cause about 8 connections to be opened.  I'm not sure where :)
[04:39] <DBO> really...
[04:39] <DBO> are you check to see if some of them dont quickly die?
[04:44] <RAOF> Oh, some of them probably *do* quickly die.
[04:44] <RAOF> I think you're right in that the compiz process calls XOpenDisplay 3 times.
[04:47] <RAOF> Bah.  Maybe some tea will make this less annoying.
[04:48] <RAOF> For comparison: starting gnome-screensaver-preferences results in 7 calls to AllocNewConnection :)
[04:50] <DBO> O_o
[04:50] <DBO> so at that rate we should be able to open *counts* 24 applications
[05:09] <DBO> RAOF, do X connections even communicate their parent process?
[05:09] <DBO> RAOF, can X tell that one app opened multiple X connections?
[05:10] <RAOF> DBO: It can, I think, but it currently doesn't.
[05:10] <RAOF> It would make it easier if it did, because then I could just filter out all the connections which don't have compiz on the other end!
[05:11] <DBO> ha
[05:13] <RAOF> Oh, would you believe it?  Geis also opens a display connection.
[05:13] <DBO> wtf
[05:13] <DBO> why would it do that...
[05:13] <DBO> it has its own fd
[05:14] <DBO> so we are using 4 of the 256 X connections
[05:14] <DBO> if every application starts using geis, each app uses 2
[05:14] <DBO> so thats immediately down to what, 126 application instances?
[05:14] <DBO> god thats dumb
[05:15] <RAOF> Yay (small) arbitrary limits!
[05:15] <RAOF> Ok.  Now I know all the connections on both sides: which Display in the compiz process corresponds to which Client in X.
[05:16] <DBO> awesome
[05:19] <RAOF> Ok.  So, as expected, Compiz' client is getting blocked all the time; each time it calls WaitMSC.
[05:21] <RAOF> Man, it does that a lot.
[05:23] <RAOF> At 60Hz, in fact :)
[05:30] <DBO> so, every draw
[05:30] <DBO> what does that clal do?
[05:33] <RAOF> DBO - it's the ‘wait for vblank’ call.
[05:34] <DBO> oh
[05:34] <DBO> then yeah
[05:34] <DBO> that makes sense
[05:34] <RAOF> It does indeed.
[05:34] <DBO> but that call should just block right?
[05:34] <RAOF> From the X protocol side of things - no.
[05:34] <RAOF> I'm not sure if libGL wraps it so it blocks.
[05:35] <RAOF> It *will* block any further X commands, though.
[05:35] <DBO> i thought it blocked to be honest
[05:35] <RAOF> libGL might turn it into a blocking request.
[05:35] <DBO> does disabling the sync to vblank fix the freeze for you?
[05:36] <DBO> that would disable that call
[05:36] <RAOF> I don't know.  However, I've got it to freeze in Undecorate again, and none of the clients are actually ignored, so it doesn't appear to be that.
[05:37] <DBO> does X actually send a reply back?
[05:37] <RAOF> For WaitMSC?
[05:39] <RAOF> Yes, but the reply is the current MSC data.
[05:41] <DBO> RAOF, no when it blocks
[05:41] <DBO> so it blocks in poll right
[05:41] <RAOF> Right.
[05:41] <DBO> so does X actually send a reply back
[05:42] <RAOF> Well, it doesn't appear to; it's blocked in poll :).  I'm scooting through the X-side client to see what's what.
[05:45] <RAOF> Hm.  The gdk client has some input.
[05:51] <DBO> RAOF, so you are saying its gdk's fault
[05:51] <RAOF> Sorry.  The X server's client corresponding to gdk's Display has some input.  I'm not sure if that's expected, though.
[05:56] <DBO> when it freezes?
[05:58] <RAOF> Yeah.
[06:02] <DBO> could it be that xcb_wait_for_reply fails if there is already stuff n the queue???
[06:12]  * DBO gives RAOF the keg of glory
[06:21] <RAOF> Good.  And, just to check, the all of compiz's clients *actually* have different fds :)
[06:59] <DBO> RAOF, do me a favor, when you call it quite today
[06:59] <DBO> if I am not online by that time (probably wont be considering time zones)
[07:00] <DBO> can you email me a quickie status report?
[07:00] <RAOF> DBO: Certainly.
[07:00] <DBO> RAOF, nothing interesting yet? :(
[07:01] <RAOF> Not apart from EVERYTHING SEEMS TO BE OK, GODDAMNIT.
[07:01] <DBO> I am wondering if its not possible to make XCB just gracefully fail
[07:01] <DBO> i mean its stupid to just poll forect
[07:01] <DBO> forever
[07:03] <RAOF> That's a breaking ABI change, though.
[07:03] <RAOF> What are appse going to do inresponse?
[07:03] <RAOF> Mmmm, IRC lag.
[07:03] <DBO> every major call *already* has a fail condition
[07:03] <DBO> like XGetWindowProperty for instance
[07:03] <DBO> *can* fail
[07:03] <RAOF> Apart from the bit where it DOESN'T WORK.
[07:04] <DBO> yeah this is fucked up
[07:04] <RAOF> Hm.  A… 3 minute IRC lag :)
[07:04] <RAOF> That was from my other system.
[07:04] <DBO> O_o
[07:04] <DBO> RAOF, you'll fix it :) I have faith
[07:04] <DBO> and if you don't
[07:04] <DBO> well, thats what fire was made for
[07:05] <RAOF> :)
[07:05] <RAOF> A superior being such as myself has only one option: burn them.
[07:05] <DBO> actually we will just have to collect ever condition this happens in
[07:05] <DBO> and juggle which x connection gets used
[07:05] <DBO> OH!
[07:05] <RAOF> To avoid the madness.  Yah.
[07:05] <DBO> interesting fact I found
[07:05] <DBO> I forgot about this till now
[07:05] <DBO> might be relevant
[07:06] <DBO> we had a similar issue to this in nux once
[07:06] <DBO> basically what would happen is nux would lock up just like this
[07:06] <RAOF> This does sound interesting, yes.
[07:06] <DBO> it calls XQueryKeymap or some shit when it processes events
[07:06] <DBO> so its all normal when it's just nux
[07:07] <DBO> but it started screwing up when we began processing events that came from compiz
[07:07] <DBO> after looking at it more, we determined that by using the Display provided by the XEvent, the locking stopped
[07:07] <DBO> no idea why
[07:07] <RAOF> Yeah, that's going to be the same problem.
[07:07] <RAOF> Or, probably is.
[07:08] <DBO> yeah
[07:08] <DBO> but it somehow has to do with using X calls from a different Display when compiz is processing events
[07:08] <DBO> the fix for the maximize issue was pretty simple
[07:08] <RAOF> However - if you write a small testcase that does nothing but call XGetWindowProperty on Display x in response to PropertyNotify on Display y then you won't lock up.
[07:08] <DBO> all I did was make it use the compiz display
[07:09] <DBO> yes I imagine it must be somehow in response to what compiz is doing when processing events
[07:09] <RAOF> Yeah.
[07:11] <DBO> okay I know I am just kinda throwing random shit out there right now
[07:11] <DBO> but lets assume for the moment that the issue is some X call compiz is making somewhere
[07:11] <DBO> the most logical thing to do is to slim down compiz *as much as possible*
[07:11] <DBO> so disable every plugin you can but still have unity running
[07:11] <DBO> then see if it still happens
[07:12] <DBO> you probably already did that
[07:12] <RAOF> Actually, I didn't.
[07:12] <RAOF> Because it crashes each time I want to disable a plugin :)
[07:13] <DBO> yes, start metacity
[07:13] <DBO> THEN do the plugin juggle
[07:13] <DBO> then restart compiz
[07:14] <DBO> RAOF, okay if I dont go to bed now i am going to be murdered by a small blonde woman
[07:15] <RAOF> DBO: Go to your mistress!  I can hold the fort here :)
[07:15] <DBO> while this would indeed be a net win for the world, it would be a decided net loss for me
[07:30] <oSoMoN> good morning
[08:01] <RAOF> Whaaargfl.  You think you have identified some interesting behaviour, but then when you look it's gone away!
[08:05] <MacSlow> greetings everybody
[08:11] <didrocks> good morning
=== daker_ is now known as daker
=== davidcalle_ is now known as davidcalle
=== zyga_ is now known as zyga
[11:29] <ssn> hi guys. in my natty installation, my laptops touchpad is mistaken for a touchscreen (absolute vs relative). how do i change this and how do i report this bug?
=== MacSlow is now known as MacSlow|lunch
[12:59] <danyR> njpatel: hi. I've a question: does unity update launcher's icons on-the-fly (i.e., if there have been changes on the desktop file)?
[12:59] <njpatel> No, I don't believe that works this cycle
[13:06] <danyR> njpatel: ah, bummer. otherwise it would be really easy to create a little neat weather-checking application.
[13:07] <njpatel> heh, indeed
[13:08] <njpatel> danyR, it's probably a good feature to have if your interested in working on it
[13:08] <njpatel> GFileMonitor makes it easier than you'd think it would be
=== MacSlow|lunch is now known as MacSlow
[14:05] <om26er> njpatel, Hi! do you think bug 722178 is bitesizeable? for your convenience see https://launchpadlibrarian.net/64772865/Screenshot.png the window title is being cut by the invisible systray, as the problem does not happen when skype is running.
[14:05] <ubot5> Launchpad bug 722178 in unity (Ubuntu) "window's title does not fade in the right position" [Undecided,Confirmed] https://launchpad.net/bugs/722178
=== API is now known as Guest27319
[14:05] <njpatel> om26er, yeah, bitesizable
[14:06] <om26er> thx
[14:06] <vish> njpatel , om26er: isnt that by design?
[14:06] <vish> or should that be even closer to the indicator?
[14:06] <om26er> vish, hmm no it is supposed to fade at the very end
[14:06] <njpatel> I don't think the extra space is by design
[14:06] <vish> ah!
=== Guest27319 is now known as apinheiro
=== jackneill is now known as Jackneill
[14:42] <kenvandine> ted, what's in your queue for releases today?
[14:44] <tedg_> kenvandine, Still building that list, but for sure indicator-application, dbusmenu and indicator-datetime.
[14:44] <tedg_> kenvandine, I think that there's a indicator-appmenu patch as well.
=== seb128_ is now known as seb128
[14:45] <tedg_> kenvandine, Lots of little fixes all over the place.
[14:45] <seb128> indicator-session has a g_error turning to g_warning, appmenu-gtk for the desktop menu race
[15:19] <om26er> good morning lamalex
[15:19] <lamalex> hey om26er
[15:19] <lamalex> how's it going
[15:19] <om26er> everything's great
[15:21] <om26er> lamalex, there are a lot of bugs like bug 752157 for AMD open-source driver, is it under someone's radar?
[15:21] <ubot5> Launchpad bug 752157 in unity (Ubuntu) "graphical corruption in launcher" [Undecided,New] https://launchpad.net/bugs/752157
[15:21] <om26er> for ref https://bugs.launchpad.net/unity/+bug/752157/+attachment/1986199/+files/corruption.png
[15:21] <om26er> this white corruption have been there from the inception of compiz unity iirc
[15:27] <lamalex> om26er, i usually assign jaytaoko
=== jackneill is now known as Jackneill
=== clarita_ is now known as clarita
[16:02] <kim0> After 2 days of usage, Xorg is constantly taking ~25% cpu .. Everything feels slower (switching windows, gnome-terminal tabs, thunderbird messages...etc) .. Does this qualify as a bug of unity?
=== bregma is now known as bregma|away
[16:38] <BigWhale> Greetings
[16:38] <BigWhale> when I install an application manually to /opt/foo or whatever, how do I make it appear in Application lens?
[16:41] <BigWhale> there used to be menu editor... (which I noticed is still present, but has no effect...)
[17:10] <kim0> BigWhale: wild guess .. would creating a .desktop file for it help
[17:14] <kim0> woah! unity --reset   really helps
[17:56] <BigWhale> kim0, probably, but where to put it?
[18:03] <Matso> Hi i relly like the new ui. the only thing i dont like about unity is where you have put the launcher. it would be way better if you would have made it like docky.  best regards
[18:07] <Mikoar> I enabled magic lamp effect for minimizing in Unity, but it doesn't work.
[18:07] <Mikoar> Please help
[18:07] <Mikoar> Other effects do work however
[18:08] <Mikoar> like shadows for windows
=== daker is now known as daker_
[18:45] <BigWhale> A question! How do I run something from Applications as root? AMD Control Center in this particular case.
[18:46] <vish> BigWhale: gksudo before the application command
[18:46] <vish> so it would be $ gksudo AMDWHATEVER
[18:46] <BigWhale> Uhm... Not from the terminal. I know how to do that... :)
[18:47] <BigWhale> I was thinking more of a CTRL+SHIFT+CLICK on the icon
[18:47] <vish> BigWhale: edit the launcher properties :D
[18:47]  * BigWhale sighs.
[18:47] <BigWhale> I though so
[18:47] <BigWhale> I'll go file a feature request
[18:48] <vish> BigWhale: in Unity?
[18:48] <BigWhale> yes
[18:48] <vish> BigWhale: it would be more of a bug in AMD Control Center, because it does not run as root
[18:48] <vish> not a bug in Unity
[18:49] <BigWhale> Uhm
[18:49] <BigWhale> what if I want to run nautilus as root?
[18:49] <vish> not something that is advisable unless you know what you are doing ;)
[18:50] <BigWhale> Yes, I know that.
[18:50] <vish> ie: should not be as easy as just ctrl+shift+click
[18:50] <vish>  making such things easy is a recipe for disaster
[18:51] <BigWhale> If there's a popup that tells you "YOU'RE GOING TO HELL ... etc etc" I see no reason why not ...
[18:52] <vish> yea, a popup like that would be awesome.
[18:54] <BigWhale> It really is annoying sometimes that you HAVE to open terminal or fumble around with ALT-F2 and gksudo especially if you don't know the command name :)
[18:54] <vish> mpt: not fair! you dint file this bug! » http://twitter.com/#!/mptbugs/status/58580035749167104  /me unfollows
[18:55] <mpt> vish, blame Launchpad, it's just syndicating http://feeds.launchpad.net/~mpt/latest-bugs.atom
[18:55] <vish> ha!
[18:57] <vish> almost always if something is wrong in Ubuntu, there will be LP to blame somewhere.. ;p
[18:57] <mpt> One of these decades, Nautilus will integrate PolicyKit for admin actions, so nobody ever wants to run Nautilus as root any more
[18:58] <BigWhale> Hmm, I wonder if this bug for dev build chromium is related to unity or not ... I can't drag tab from one window to another
[19:00] <vish> One of these decades, file-managing will become redundant and we will have no use for Nautilus ;)
[19:02] <om26er> gord, Hi! will the fix to bug 741584 (targetted for next release) also fix 752727 or both a different ?
[19:02] <ubot5> Launchpad bug 741584 in unity (Ubuntu) "Selecting a different lens should open it, instead of closing the current lens" [Medium,In progress] https://launchpad.net/bugs/741584
[19:02] <om26er> bug 752727
[19:02] <ubot5> Launchpad bug 752727 in unity (Ubuntu) "Cannot switch to different dash modes once open" [Undecided,New] https://launchpad.net/bugs/752727
[19:21] <htorque> loicm: hi, should your work on the ccsm plugin crasher already fix something? i'm at nux r330 and unity r1141 and still getting the crashes.
=== tedg_ is now known as tedg
=== bregma|away is now known as bregma
[23:15] <zniavre> http://imgur.com/5xKUz.png   there is a bug with prelight of application selected items
[23:23] <zniavre> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/761201
[23:23] <ubot5> Ubuntu bug 761201 in unity (Ubuntu) "prelight of items in dash" [Undecided,New]
[23:24] <zniavre> the title and details are not well describe but the screenshot is clear (sorry )
[23:36] <BigWhale> Funny, If I run an openGL game that switches to full screen AMD driver will display two big red boxes with number 1 and 2 on each of my monitors.