[06:18] morning [06:19] good morning [06:19] good morning spikeb [07:46] morning everyone [07:48] DBO: the paint attributes ? [07:48] DBO: gWindow->paintAttrib () [07:48] smspillaz, yes [07:48] (sorry about the delay( [07:49] oh I can just set that anytime? [07:49] no you can't just set it any time [07:49] that's the *last [07:49] *last [07:49] arhg [07:49] *last* paint attribu [07:49] to set it you have to wrap either glPaint or glDraw and do it there [07:50] if it's in the unity plugin I suggest wrapping glDraw, and then doiing GLFragment::Attrib fA (fragment); [07:50] and then modifying it, eg fA.setSaturation (foo); [07:50] its a const in glPaint [07:50] and then passing the chain [07:50] DBO: that's the point [07:50] OH! [07:50] DBO: you copy it, modify it and then call the gWindow->glPaint (myAttribute, foo); [07:50] DBO: wrap chains [07:51] DBO: I would wrap glDraw though [07:51] since wrapping two functions is more expensive than one [07:51] yes but onestone made it very clear to me that doing any modifications like that in gldraw is evil [07:51] because other plugins don't catch it [07:51] this is correct [07:52] however, since we are loaded last, that doesn't really matter [07:52] DBO: do it in glDraw unless you want the fade plugin to automatically fade your modifications [07:53] DBO: I think "dock" and "sticky" conflict and make core stack it like a normal window [07:53] nope [07:53] checked that [07:53] at least it was something and dock that conflicted [07:53] its acting right now that I made the windows input/output [07:53] weird [07:54] DBO: might be doing weird things because it's not attrib.is_viewable [07:54] DBO: be warned though, I hate touching the stacking code [07:55] it's such a bloody mess [07:55] so in reality I am doing a very big favor for you :) [07:55] good morning [07:56] DBO: window.cpp:2051 [07:56] smspillaz: Do you want to debug your intel problem sometime? [07:57] RAOF: yeah, but not right now [07:57] RAOF: I can boot in safe mode and work from there [07:57] DBO: err priv->attrib.map_state [07:57] Ok. In your own time :) [07:57] RAOF: thx [07:57] kamstrup: good morning. feeling better now? [07:58] didrocks: I got the GFile stuff done btw [07:58] smspillaz, Im working on this shiz I almost got it working right [07:58] kvalo: yeah, a bit. Will start your review now [07:58] DBO: I hate the stacking code with a passion [07:58] smspillaz: oh nice! for both backend I guess? Did you get some testing? [07:58] didrocks: yes it works fine [07:58] didrocks: patches are in your inbox [07:59] smspillaz: nice! [07:59] smspillaz: btw, I finally understand the "profile" system [07:59] cool :) [07:59] smspillaz: and why we get this "bug" yesterday [07:59] in fact, it's a bug, and we don't need my patch :) [08:00] cool [08:00] what was the bug? [08:00] looking at the code, the "profile" as the environment variable set (the "general_") is adding a new "session tpe" [08:00] so, general_unity is a session type [08:00] yeah, that's the point [08:00] if you change the profile there, it will affect the profile= in general_unity [08:01] so, you're safe for other session [08:01] smspillaz, how do I just make a window not draw then? [08:01] it's just a shame that both notions are called "profile", so confusing :) [08:02] DBO: this is a massive hack and half, but wrap glPaint and do mask |= PAINT_WINDOW_NO_CORE_INSTANCE_MASK [08:02] what? [08:02] there is no way to make a window just not paint? [08:02] DBO: there's a variable called "mask" in glPaint, if you do that then it won't be painted period [08:02] DBO: err you could be a little smarter actually [08:03] DBO: do you mind if I can see your code and write something to do that? [08:03] greetings erverybody [08:03] DBO: basically we'll just pop your nux windows from the paint list [08:03] hey smspillaz [08:03] MacSlow: hi [08:03] smspillaz, painting with 0 opacity works too [08:03] but it seems to paint regardless [08:03] DBO: yeah, I'll do my solution [08:04] DBO: push your code to some branch and I'll do the bits to pop it from the paint stack [08:04] smspillaz, https://pastebin.canonical.com/40163/ [08:04] DBO: push your code to some branch and I'll do the bits to pop it from the paint stack [08:04] ;-) [08:04] ah fuck I just want to know how to make its opacity 0 [08:04] why does that not work? [08:04] you can do your thing after I learn [08:04] DBO: making the opacity zero is one way to do it but you are still darwing the window with opengl = stupid [08:05] no no [08:05] it does not work [08:05] the window is still drawn [08:05] thats what I am saying [08:05] hey DBO [08:05] hey MacSlow [08:06] DBO: try copying attrib [08:06] smspillaz: looking at your patch [08:06] why? [08:06] salut didrocks [08:06] DBO: eg GLWindowPaintAttrib fA (attrib); [08:06] smspillaz: you don't remove .config/compiz-1/compizconfig for existing users? [08:06] DBO: this is how the other plugins do it, just try it [08:06] didrocks: no, we just merge the old config [08:06] smspillaz: so it will end as .config/compiz-1/compizconfig/compizconfig, isn't it? [08:06] smspillaz: oh ok :) [08:06] nice, (just had a quick lookà [08:07] Guten Morgen MacSlow [08:07] * didrocks enjoys tooltips :) [08:07] still paints it [08:07] kvalo: it's this one right? https://code.launchpad.net/~kvalo/indicator-network/libconnman-backend/+merge/41734 [08:08] smspillaz: waow, it's a very C++ way of using glib :) but looks good! [08:08] DBO: weird. maybe it hates you [08:08] didrocks: hehe [08:08] DBO: did you pass fA to glDraw instead of attrib ? [08:08] yes [08:08] hmm wtf [08:08] kamstrup: hey dude! feeling better? [08:08] kamstrup: yes, that's it [08:09] DBO: stick an fprintf on line 11 and make sure it is actually changing the opacity [08:09] DBO: also make sure the screen is damaged [08:09] i did [08:09] or window rather [08:09] its hitting [08:09] didrocks: yeah, I manage, not fully back to normal, but I think I can code :-) [08:09] argh wtf [08:09] kamstrup: unstoppable! [08:09] DBO: use fire to trigger full screen repaints and see if it is actually damaging [08:09] doing it glPaint worked [08:10] DBO: yeah, weird [08:10] whatev [08:10] it works now [08:10] DBO: oh right, I think you need to set PAINT_WINDOW_BLEND_MASK or something for it to work [08:10] and glPaint will do that [08:10] * smspillaz has a look at the code [08:11] okay whatever [08:11] the point is it works [08:11] and much nicer [08:11] DBO: cool [08:11] DBO: however, I know of a better way to do this [08:11] you can fix it after I push [08:11] DBO: push your code somewhere [08:11] hey kvalo, kamstrup [08:11] kamstrup, so feeling a bit better now? [08:12] didrocks, everything should even look nicer by monday [08:12] MacSlow: hi [08:12] DBO: actually, I think the way core was stacking the windows the way it was is because there is no usecase for invisible dock windows [08:12] well inputonly ones [08:12] smspillaz, I dont want to mess with core stacking [08:12] we can use inputoutput windows [08:12] its safer [08:12] yeah fair enough [08:13] still seems like hack to me though [08:13] it is [08:13] * smspillaz hears kittens dying [08:13] but there are two options here [08:13] DBO: hey are you using the glibmm branch? [08:13] MacSlow: you mean, working QL with pin/unpin? :) [08:13] A) Fix compiz handling of invisible dock windows [08:13] B) Use visible dock windows and get sane stacking [08:14] A) is correct but wont be ready for Natty [08:14] B) is a hack but works right now [08:14] DBO: actually, inputOutput sort of makes sense in terms of a broader future [08:14] I choose b [08:14] didrocks, not working on the logic right now... but this will come too of course [08:14] smspillaz, the changes are in trunk [08:14] you must update nux and compiz [08:15] nux and unity rather [08:15] smspillaz, I am not using glibmm [08:15] did you merge that into the master DBO branch? [08:16] DBO: no I have not yet [08:16] DBO: there is some stupid bug [08:16] fix that, then do so :) [08:16] calls to null timers [08:16] yeah [08:16] the problem is [08:16] I can't figure out how to reproduce it reliably [08:17] i was wondering if you had [08:21] no [08:21] I have sent an email to the dx-team list explaining the change to InputOutput windows [08:22] cool [08:22] can we enforce window resizing on map? [08:22] so that if a window is too big for the screen, it resizes down [08:23] DBO: in core? [08:23] in place I would assume [08:23] DBO: I think place does it already [08:23] it fails [08:23] or more accurately, it doesn't take panels into account [08:23] only for certain window types though [08:23] yeah well resizing panels makes no sense [08:23] actually [08:23] panels should be smarter than that ;-) [08:24] do we sitll have the panel shadow hack? [08:24] no [08:24] you can task me to port that patch though [08:25] DBO: still no mail re the inputoutput windows [08:26] I just got it [08:26] so it worked [08:31] alright I think thats it for me [08:35] reboot, brb [08:43] DBO: night [08:44] DBO: BTW one thing you'll come to love about compiz is that you can change the paint list to anything you like [08:44] like, anything [08:44] the order in which windows are painted is completely pluggable [08:44] also you can change the stacking order [08:48] smspillaz: I hate this profile thing! With the latest backend, I couldn't get the gconf key picked up (and yes, I have /options at the end this time :p) [08:48] (under compizconfig-1 of course) [08:49] and it says it starts the "unity" profile [08:55] smspillaz: if I try to add it to ccsm, it added it to the "Default" profile, even if I have the unity profile selelcted in ccsm… [08:55] does anyone actually like any aspect of this? ;) [08:56] smspillaz: also, it's dumping the it under compiz-1/general*/options/active_plugins … sounds like a mess :) [09:02] didrocks: with the transition thing? [09:02] didrocks: soudns like a bug [09:02] smspillaz: I think it's not impacted by the transition thing [09:02] yeah, sounds like a bug :) [09:02] one sec, run after some plug [09:02] didrocks: sure [09:04] ok so [09:04] I've resetted all my gconf tree for /apps/compiz* [09:04] first, I have a leftover to /apps/compiz, even after the reset [09:04] sounds like there is a schema installing something there [09:05] * didrocks greps [09:06] ok, they come from compiz-gnome [09:06] which is part of compiz-core [09:06] and they all install in /apps/compiz [09:07] ok, ./xslt/compiz_gconf_schemas.xslt needs to be updated [09:07] smspillaz: fixing and pushing [09:08] didrocks: ahhhh right [09:08] yes good find [09:10] well, not the source of the issue but at least, will help to get a cleaner gconf view of it :) [09:12] kvalo: ! [09:12] kvalo: phew, I'm done :-) [09:12] kvalo: very nice, although there where a few leaks so I marked it needsfixing [09:14] kamstrup: yeah, it was a long one :( [09:14] kvalo: it's ok. The code is quite nicely structured that helps a lot [09:14] kamstrup: cool [09:15] kamstrup, feeling better? [09:15] smspillaz: I think that's why as well compizconfig-plugin-main and unity didn't install their gconf schemas recently [09:15] didrocks, morning dude [09:15] hey njpatel! [09:15] njpatel: it's ok, not fully steaming yet, but good enough to hack :-) [09:16] kamstrup: I need help with gvariant and "a(oa{sv})". do you know any examples how to properly parse that beast? [09:17] smspillaz: really, the first day I have some time for hacking, I'll split the 2 "profiles" notion to get "session_type" and "profile"… the code will look so much cleaner [09:17] having one word for two things makes the debugging sooooo confusing [09:18] didrocks: you could also try to profile the profile code ;-) [09:18] kamstrup: sure, but which part of the "profile code", the profile one or the other profile one? :) [09:18] * kamstrup blows up [09:19] didrocks, NNNOOO you killed kamstrup ! [09:19] :) [09:19] He still has places work to do! [09:19] As I told jason yesterday, "you can't be unwell, it's not convenient for me" [09:19] haha [09:20] excellent! that's team work :) [09:21] kamstrup: and actually I don't know how to even create such a variant. I'm trying to implement a simple test case for this. [09:21] hum? why sladen uploaded unity? [09:21] it was not the problem… [09:22] and of course, it blows a non working unity because of it [09:23] sladen: please, I discussed that publicly in #ubuntu-desktop yesterday to tell to anyone to fix the FTBFS, it was intentional… [09:24] kvalo: sure. that's easy [09:24] someone review and merge this https://code.launchpad.net/~canonical-dx-team/unity/unity.remove-io-from-pl/+merge/41936 [09:25] didrocks: I'll update the glibmm branch to account for your changes [09:25] smspillaz: ok, but I take that as a distro-patch for now, just rebuilding everything there first [09:26] didrocks: did you commit the gconf xml builder upstream ? [09:26] err xslt [09:26] njpatel: can you review ^^^ [09:26] smspillaz: not yet, I'm finishing to rebuild every schema to ensure it's building right things [09:26] didrocks: sure [09:26] so unity is broken in natty now… thanks sladen [09:27] smspillaz, taking a look now [09:28] didrocks, what's wrong? [09:28] MacSlow: sladen fixed a ftbfs due to a wrong compiz gconf schema compiler [09:29] MacSlow: I let it FTBFS yesterday when leaving and told on public chan to not fix it and wait for the new compiz [09:29] but well… apparently some people just thought "let's remove the gconf schema"… [09:29] didrocks, *sigh* [09:29] of course, there is no update in the bzr vcs packaging, let's discare people working on it [09:33] I won't add that renaming closed bug is worthless… but well [09:44] kamstrup: sorry, but it's not easy for me :) [09:46] kamstrup: I would imagine creating a variant is like this, but no luck: http://paste.ubuntu.com/536612/ [09:46] kvalo: ok, so it's about parsing it right? [09:46] kamstrup: parsing is what I need, but I got also interested about creating [09:55] kvalo: just cooking up an example [09:56] kamstrup: thank you very much [09:58] smspillaz, approved [10:00] njpatel: thanks [10:00] njpatel: also I know what is causing that timers bug in glibmm [10:00] njpatel: timer gets destroyed and glib tries to call the timeout callback func [10:01] at which point it fails miserably when we start reading free'd memory [10:01] this is not good [10:01] no [10:01] it's no good :) [10:01] the thing is, I have no idea really how to fix it other than change the timer model [10:02] since it doesn't look like there's a way to force remove a timer from a source [10:02] remove a timeout from glib? [10:02] in glibmm [10:02] g_source_remove [10:03] GLib::Source::Remove ;) [10:03] and that will work 100% ? [10:03] g_timeout_add returns a guint [10:03] g_source_remove (uint) will remove it [10:03] I'm talkking about glibmm though [10:04] all I can find is destroy () [10:04] which could very well work [10:07] kvalo: something ala http://paste.ubuntu.com/536622/ it's probably not the most optmized way of doing this, but it should work (although it's completely untested) [10:07] kvalo: I use that technique in libzeitgeist at least [10:08] kvalo: There are some fairly complex marshalling in libzeitgeist you can look at [10:08] kamstrup: thanks a lot! don't worry about testing, I can do that [10:08] kvalo: especially in zeitgeist-event.c [10:08] kamstrup: thanks, I'll write that down :) [10:09] smspillaz, sorry, network issues [10:09] smspillaz, I'm not sure about glibmm sorry [10:09] quick look at the source cpp would figure that out [10:10] yeah [10:11] smspillaz, njpatel: We need g_source_remove() because we don't have pointers to the GSource which are required by g_source_destroy() I take it? [10:17] smspillaz: wow, gsource handling in glibmm does not look very nice... [10:18] This is why I mentioned this bug yesterday: [10:18] https://bugzilla.gnome.org/show_bug.cgi?id=561885 [10:18] Gnome bug 561885 in general "Glib::Source - mistunderstanding of the 'destroy' from C GSource -> bad impl + memory problems?" [Major,New] [10:18] but I guess you must consult the documentation of sigc::connection on how to disconnect a handler. Given that you connect the timeout with Glib::signal_timeout().connect(sigc::ptr_fun(&timeout_handler), 1000);? [10:18] Timeout handlers can be disconnected just by returning the right true/false, surely? [10:19] gobj() can get your the GSource*, if that helps. [10:20] murrayc_: yeah that might work [10:20] as a last minute hack [10:20] I was thinking of changing CompTimer to PIMPL though and removing the priv bits when needed [10:20] (I have not looked at that bug in detail. I have not particular thoughts about it because I don't use that API myself and I don't have much time.) [10:20] I'll do that when I get back [10:22] murrayc_: BTW that's not the bug [10:22] thje bug is my fault [10:24] smspillaz: Well, I'd generally like it to be much clearer what all this remove/destroy stuff is about. It's not clear to me in the C docs either. [10:26] And I really have no idea what it's even used for. [10:29] I guess GSource is just a way to use a timeout or idle callback with a non-default GMainLoop? [10:46] kamstrup: thanks, I have the beast in control now :) [10:49] didrocks: hey Didier; i've just had a compiz crash, but it was not automatically restarted by the session [10:49] didrocks: is that in the new packages? [10:49] kamstrup: do you prefer I describe the class structure in a separate doc (eg readme) or in each source file? [10:49] dbarth: hum, it should, not sure, I've on other fish right now but will check later… [10:50] dbarth: what do you have as required_components on gconf? [10:50] checking [10:51] window_manager is there, and is set to compiz elsewhere [10:52] so maybe a but in gnoime-session then [10:52] ahj sorry, metacity was first in the list [10:52] dbarth: well, the respawn should work, if you want, let's discuss that later, the gconf backend of compiz is totally broken and I have to fix it today… [10:52] sure === Cimi__ is now known as Cimi [10:52] Cimi, hey, i got a question - do you have docky installed? [10:53] no [10:53] oh no, I have [10:53] not running though [10:53] cool, could you run it and open the settings window [10:54] hum, it seems libcompizconfig is asking for the profile before setting the new default… nice [10:54] mhr3: what's the problem? [10:54] Cimi, there when you do to docklets, i see that the component that is being used has very bad contrast in maverick with the default theme [10:54] yeah known bug [10:54] I guess it's a bug in dicky [10:54] *docky [10:55] Cimi, yea, we use the same component elsewhere, could you give me a few hints how to fix it? [10:55] sure [10:55] Cimi, basically it's painting the bg using paint_flat_box() with detail cell_odd [10:55] and the labels have StateType.SELECTED [10:56] I fixed that in software center [10:57] got a link to revision with the diff that fixes it? :) [11:01] here we go mhr3 : http://bazaar.launchpad.net/~cimi/software-center/fix-lp-bug-635208/revision/1243 [11:05] Cimi, thanks [11:13] current_profile = Schema (type: `string' list_type: '*invalid*' car_type: '*invalid*' cdr_type: '*invalid*' locale: `C') [11:13] hum, I think I found something :) [11:14] * didrocks likes monolog in detective mode :) [11:16] w00t! [11:16] I have a compiz that no longer segfaults! [11:16] adding tooltips to the launcher even :-) [11:17] kamstrup, you know what the issue with the tooltips was? [11:17] njpatel: nope? [11:17] kamstrup, "%s %.2f" is "Ubuntu 12,00" on some locales [11:17] (comma) [11:17] which breaks pango [11:17] lol! [11:18] njpatel: let me politely ask how on earth that could break Pango? [11:18] njpatel: oh, it's for configuring the font [11:18] yep [11:18] kamstrup: I was the guinee pig for that, they have made me compile horrible stuff, if you knew! [11:18] so pango doesn't get the font string proper so it decides to ignore it completely [11:19] and will still see that njpatel hates French :) (and so, not only French it seems :)) [11:19] it's not really pangos fault, but something I've never come across [11:19] didrocks, MacSlow coded that :) [11:19] He hates the french too [11:19] ;) [11:19] njpatel: well, I don't doubt it as well :) [11:19] really - Unity should not support i18n or l10n. No a11y or Unicode. Strict ASCII and monospace fonts everywhere [11:20] And only one resolution as well of course [11:20] 800 x 600 one [11:20] yep, whatever is perfect for my screen [11:20] indeed [11:21] * njpatel will change it before release weekly [11:21] 1440x900 [11:21] njpatel: yeah, you should be tech lead on Unity [11:21] njpatel: oh, wait... you are ;-) [11:21] heh, coding style and screen resolution: the two perks of tech lead [11:21] * didrocks will distro-patch njpatel's change :) [11:22] \o/ [11:22] njpatel, didrocks: So Unity is basically a Hello World in Gtk+. The rest is just a huge distropatch [11:22] kamstrup: what else it can be? :-) [11:22] didrocks, that's fine, I'll just use the "pure" packaging from debian :p [11:22] kamstrup, lol [11:23] njpatel: ahah, raphael proposed me to maintain unity in debian! :-) [11:23] you're stuck, dude! [11:24] you won't espace from Monkey Isl… oh wait! [11:26] nooooooo [11:30] lol, I love the attention call from the launcher :-D [11:30] the icon just peeks in from the left, only half way in... Looks like "Uh, I'm most sorry to bother you, but there's thing... I think you need to check it out" [11:31]