[01:56] <bcurtiswx> Hey all, I think https://bugs.edge.launchpad.net/ubuntu/+source/empathy/+bug/642894 is not an empathy bug, but the indicator-applet.  Can someone take a look and confirm?
[01:56] <ubot5`> Launchpad bug 642894 in empathy (Ubuntu) "bubble twice text (affected: 1, heat: 107)" [Low,Confirmed]
[11:14] <Cimi> OT, didrocks, did someone add me to the wiki?
[11:14] <Cimi> opd
[11:14] <Cimi> ops :D
[11:15] <Cimi> was playing with weechat history
[11:15] <didrocks> :)
[11:15] <didrocks> Cimi: still a lot of people are complaining about the light themes not making items visible, did you see it?
[11:16] <Cimi> yeah but I have opened a new branch
[11:17] <Cimi> it's more important to fix compiz btw
[11:17] <Cimi> it breaks the inactive window frames
[11:46] <Cimi> hi chaotic
[11:48] <chaotic> hi Cimi
[11:55] <Cimi> chaotic: we still need to deal with few bugs
[11:56] <Cimi> chaotic: people are complaining about inactive text in menus: https://bugs.launchpad.net/bugs/617192
[11:56] <ubot5`> Launchpad bug 617192 in light-themes (Ubuntu) "[maverick-beta] Disabled menu items unreadable (affected: 21, heat: 129)" [Medium,Confirmed]
[11:56] <Cimi> and chaotic the patch for compiz was wrong, we *must* upload a new package https://bugs.launchpad.net/bugs/634417
[11:57] <ubot5`> Launchpad bug 634417 in compiz (Ubuntu) "[UIFE] tweaks to compiz for maverick (affected: 2, heat: 24)" [Undecided,In progress]
[12:00] <chaotic> Cimi: I did say there isn't enough contrast
[12:02] <Cimi> chaotic: so?
[12:20] <chaotic> Cimi: we might have to change the way the diasabled menu items work
[12:24] <Cimi> chaotic: it's not something easily doable with dark menus
[12:24] <Cimi> we might want to change the position of the shadow
[12:24] <chaotic> Cimi: I think we'll probably have to do something like this http://launchpadlibrarian.net/56501674/tb-menu.png
[12:24] <Cimi> /inset
[12:24] <chaotic> but a little more contrasted
[12:25] <Cimi> I find that less usable btw
[12:25] <Cimi> I can barely see which are active and which of them arent'
[12:26] <chaotic> as I said - but a bit more contrasted
[12:27] <chaotic> Cimi: will do a quick mockup
[12:28] <Cimi> we will still have the issue with the shadow
[12:28] <Cimi> we might want to do an inset
[12:28] <Cimi> on the pixels at the top
[12:29] <Cimi> http://launchpadlibrarian.net/56501197/current-vs-branch.png
[12:29] <Cimi> at the bottom the latest branch I created
[12:29] <Cimi> I can clearly see them
[12:30] <Cimi> but the attention goes to the active ones, I like that
[12:34] <chaotic> Cimi: but they are not easily read which makes for bad usability
[14:43] <Cimi> davidbarth: ping
[14:48] <davidbarth> Cimi: pong
[14:48] <Cimi> davidbarth: I made a mistake patching compiz
[14:49] <Cimi> used 1 instead 1.0 in the patch :) I broke the inactive window deco
[14:49] <Cimi> we need to upload the new package
[14:49] <Cimi> but kenvandine is on vacation I guess
[14:51] <Cimi> there's also another issue to deal with
[14:52] <Cimi> please poke me when you have 5 mins
[14:52] <davidbarth> oops
[14:52] <davidbarth> seb128: ^^ we need an emergency patch on compiz apparently
[14:53] <Cimi> yeah
[14:53] <Cimi> sorry guys
[14:53] <seb128> didrocks, ^
[14:53] <Cimi> I thought ken tested my package but apparently he didn't
[14:53] <didrocks> seb128: on it too
[14:54] <didrocks> (the day will be long long… :))
[14:54] <didrocks> Cimi: what's the patch? did you read my comments about the ubuntu-light package?
[14:54] <Cimi> here is the debdiff: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/634417/+attachment/1633401/+files/compiz_0.8.6-0ubuntu8_lp634417.debdiff
[14:54] <ubot5`> Launchpad bug 634417 in compiz (Ubuntu) "[UIFE] tweaks to compiz for maverick (affected: 2, heat: 24)" [Undecided,In progress]
[14:55] <Cimi> didrocks: which comment in particular?
[14:55] <didrocks> Cimi: a lot of people commented on the bug you're assigned about the inactive menu item still not being visible
[14:55] <Cimi> yeah
[14:55] <didrocks> I think you should have received some bug reports about it :)
[14:56] <Cimi> I had
[14:56] <didrocks> I think you should either answer on the bug or change something :)
[14:56] <Cimi> I have replied to them the whole weekend :)
[14:56] <Cimi> I don't think we could go to a bright midgrey color for maverick
[14:57] <Cimi> it's too late and requires patching the engine as well in order to get it done correctly
[14:57] <didrocks> Cimi: ok, just wanted to know what was your position, thanks!
[14:57] <Cimi> so for the moment I have increased the darkness of the color, in order to have more contrast
[14:57] <Cimi> and I have created a new branch
[14:58] <didrocks> Cimi: oh (seeing your diff) that's why the unfocused window was still transparent :)
[14:58] <Cimi> don't know who takes decisions here, but for me it would be cool to merge it and release a new package
[14:58] <didrocks> Cimi: hum, so you have a fix somewhere?
[14:58] <Cimi> for the insensitive menuitems?
[14:59] <Cimi> https://code.launchpad.net/~cimi/light-themes/more-contrasted-disabled-menuitems
[15:00] <Cimi> davidbarth: I also have a new branch with rounded corners, if someone wants it: https://code.launchpad.net/~cimi/light-themes/rounded-bottom-corners
[15:00] <didrocks> Cimi: yeah
[15:00] <didrocks> hum, don't change everything
[15:01] <didrocks> but I think taking the contrasted ones make sense
[15:01] <Cimi> me too
[15:02] <didrocks> Cimi: do you have the bug report about the constract handy? that will help me a lot :)
[15:03] <Cimi> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/634417
[15:03] <ubot5`> Launchpad bug 634417 in compiz (Ubuntu) "[UIFE] tweaks to compiz for maverick (affected: 2, heat: 24)" [Undecided,In progress]
[15:03] <Cimi> ops
[15:03] <Cimi> https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/617192+
[15:03] <ubot5`> Launchpad bug 617192 in light-themes (Ubuntu) "[maverick-beta] Disabled menu items unreadable (affected: 21, heat: 129)" [Medium,Confirmed]
[15:04] <Cimi> without the plus
[15:05] <didrocks> Cimi: thanks a lot :)
[15:05] <didrocks> Cimi: will sponsor both
[15:06] <Cimi> compiz is essential :)
[15:07] <didrocks> Cimi: is it crashing? it's not there
[15:08] <Cimi> no
[15:08] <Cimi> but makes window decoration transparent
[15:08] <didrocks> yeah (and I liked that TBH :))
[15:08] <didrocks> you know, critical is crash :p
[15:08] <didrocks> here, it's maybe "high" for a designer point of view  ;)
[15:09] <Cimi> critical for my designer point of view :)
[15:09] <Cimi> didrocks: can we get this uploaded today?
[15:10] <didrocks> Cimi: it will be uploaded today, but I already have a queue of 10 pendings upload
[15:10] <Cimi> before people will start breaking their gconf installations
[15:10] <Cimi> ok
[15:10] <didrocks> Cimi: it won't break gconf installation, as default aren't copied
[15:10] <didrocks> default is default, it will be changed on update
[15:11] <Cimi> it will if you'll play with gconf-editor
[15:11] <Cimi> as I did :)
[15:11] <Cimi> i had to run gconftool-2 --recursive-unset /apps/gwd
[15:11] <didrocks> yeah, but even the new one won't overwrite that if you play with gconf-editor
[15:11] <didrocks> same for everything… not only for those keys
[15:11] <didrocks> if you change defaults, you change defaults… :)
[15:11] <Cimi> but
[15:12] <Cimi> if you change the value
[15:12] <Cimi> it still gets the old default
[15:12] <Cimi> don't know why
[15:12] <didrocks> no, it gets the changed value
[15:12] <Cimi> maybe because it was int/float
[15:12] <Cimi> here, even after changing the default
[15:12] <Cimi> didn't work until I run gconftool-2 --recursive-unset /apps/gwd
[15:12] <didrocks> ?
[15:13] <didrocks> don't understand
[15:13] <didrocks> you have one default value
[15:13] <Cimi> i installed compiz
[15:13] <didrocks> then, you change to your custom value
[15:13] <Cimi> the broken one
[15:13] <Cimi> "oh shit, let's set it to 1.0 trough gconf-editor"
[15:13] <didrocks> well, you change with gconf-editor, you choose whatever you want
[15:13] <Cimi> didn't work
[15:13] <didrocks> right
[15:13] <Cimi> ok, so let's patch the defaults
[15:13] <Cimi> patched
[15:13] <Cimi> "damn, doesn't work"
[15:13] <didrocks> weird, it should work, at least at restart
[15:14] <Cimi> even after playing tieh gconf.editor again
[15:14] <didrocks> oh, patching the defaults
[15:14] <Cimi> didn't work until I run gconftool-2 --recursive-unset /apps/gwd
[15:14] <didrocks> you change the default file?
[15:14] <Cimi> iirc yes
[15:14] <didrocks> sure, you have to launch a script to take it into account
[15:14] <didrocks> that's how gconf is working on debian and ubuntu
[15:29] <bratsche> vish: Actually I think jimmac had talked about symbolic icons for years.
[15:29] <bratsche> vish: And the code was implemented by hadess and mclasen.
[15:29] <bratsche> So, not really sure how we contributed that. :)
[15:31] <vish> bratsche: yea, jimmac *always* likes monochrome colors because of obvious personal reasons.. ;)  but never not "symbolic" icon are how we planned it.. if you see the earlier shell mockups all the icons were color.. it was only after we started it for humanity and people liked it . that gnome used the idea..
[15:31] <vish> s/not//
[15:32] <vish> jimmac likes greyscale rather..
[15:33] <bratsche> I thought someone had talked about colorized mono icons several years ago.. maybe I forgot who it was, but I thought it was him.
[15:34] <vish> bratsche: he attended the symbolic icon session and pushed the idea in gnome.. IMO, its because of his backing it got more traction in gnome ;)
[15:35] <bratsche> Okay, cool.
[22:54] <Cimi> bratsche: ping
[23:20] <bratsche> Cimi: pong
[23:20] <bratsche> Hey dude.
[23:36] <Cimi> bratsche: hi :)
[23:37] <Cimi> would it be hard to patch GtkTreeview::odd-row-color to accept symbolic colors?
[23:37] <Cimi> Gtk-Message: (for origin information, set GTK_DEBUG): failed to retrieve property `GtkTreeView::odd-row-color' of type `GdkColor' from rc file value "((GString*) 0x93c62d0)" of type `GString'
[23:37] <Cimi> this is the error I have when using shade (0.96, @base_color)
[23:39] <bratsche> Hmm.
[23:40] <bratsche> Cimi: I don't think I can answer you right now, but I can try to find out.
[23:40] <Cimi> no worries
[23:40] <Cimi> thank you
[23:42] <bratsche> I need to look at the symbolic color implementation for another project of mine, so thanks for reminding me of this.
[23:46] <Cimi> oooh ok :D
[23:46] <bratsche> Cimi: You're up hacking pretty late tonight aren't you dude? :)
[23:47] <bratsche> Hope it's something fun. :)
[23:49] <Cimi> listening to music and studying for the job interview i'll have with seb
[23:49] <bratsche> Oh nice!  What's the job you're applying for?
[23:49] <Cimi> design engineer
[23:49] <bratsche> Cool
[23:49] <bratsche> Good luck!
[23:49] <Cimi> thanks ;)
[23:49] <bratsche> Listening to anything good?
[23:50] <Cimi> just searching for new artists
[23:50] <Cimi> i'm gonna listen some acoustic sounds tonight
[23:52] <bratsche> Cimi: What's the advantage of setting GtkTreeView::odd-row-color to a symbolic color?
[23:52] <Cimi> because right now
[23:52] <bratsche> I mean, either way you're setting it to a static color right?
[23:52] <Cimi> if you set, i,e to #f5f5f5
[23:52] <Cimi> but you change the base color in gnome appearance capplet
[23:53] <Cimi> you'll have your cool new color for base
[23:53] <Cimi> but the #f5f5f5
[23:53] <Cimi> will still be present
[23:54] <bratsche> I guess I don't understand.. that's true with every widget part isn't it?
[23:54] <bratsche> In the appearance capplet you can change to a different theme, but you can't really change individual widget pieces right?
[23:54] <Cimi> yep
[23:55] <Cimi> but you have control over the colors in the gtkrc
[23:55] <bratsche> I'm just trying to understand the use case still.