[06:44] <pitti> Good morning
[06:47] <larsu> hi pitti!
[06:48] <darkxst> hey pitti, larsu
[06:49]  * pitti waves from South Africa, hello!
[06:49] <larsu> morning darkxst
[06:49] <larsu> pitti: oh, nice!
[06:53] <darkxst> larsu, any thoughts on this comment? https://code.launchpad.net/~noskcaj/gnome-system-monitor/titlebar/+merge/243576/comments/601288
[06:55] <darkxst> pitti, hopefully you getting more sun, than we are, got very soaked riding over the weekend ;(
[06:55] <pitti> darkxst: plenty here :)
[06:58] <Noskcaj> darkxst, rain is very good for AU. 2 years since we've had proper rain
[06:59] <Noskcaj> Although i guess you had reasons to complain, since you had a weekend planned
[06:59] <darkxst> Noskcaj, we have probably had a lot more rain down here than up your way this year!
[07:00] <Noskcaj> lucky
[07:00] <larsu> darkxst: light-themes already style .header-bar and .titlebar
[07:01] <larsu> darkxst: we use it to distinguish between actual title bars and header-bars as primary toolbars
[07:01] <larsu> which is probably a bit wrong, but was a nice heuristic for most apps so far
[07:02] <darkxst> larsu, g-s-m does not get the header-bar styling it seems, it has rounded corners on the widget for example
[07:04] <larsu> darkxst: unset .titlebar, then
[07:04] <darkxst> its header_bar widget has class titlebar, not class header_bar
[07:04] <darkxst> and its not the only app like that either
[07:05] <larsu> right. When you add a patch that hows traditional title bars, you need to s/titlebar/header-bar
[07:05] <larsu> we need some way to differentiate proper headerbars from headerbars-as-toolbars in the theme
[07:12] <darkxst> larsu, obviously can't do that in gtkbuilder file, but guess can use gtk_style_conext_add/remove_class?
[07:20] <larsu> darkxst: you can add classes in the builder file as well: <style> <class name="header-bar" /> </style>
[07:20] <larsu> (I think that's the syntax...
[07:20] <larsu> )
[07:21] <larsu> ) you can't remove them though...
[07:24] <didrocks> morning
[07:24] <larsu> hi didrocks!
[07:25] <didrocks> hey larsu :)
[07:31] <seb128> good morning desktopers
[07:42] <darkxst> larsu, also my g-s-m patch was upstreamed, but doubt they would take a hack that is specific to the ubuntu themes
[07:45] <larsu> darkxst: sure? I think it's reasonable to say that a toolbar should not have .titlebar set...
[07:46] <darkxst> larsu, I meant by hacking the UI file, which can't now which DE is running?
[07:47] <larsu> darkxst: right
[08:19] <darkxst> larsu, seb128 https://bugzilla.gnome.org/show_bug.cgi?id=741236 that should work better
[08:19] <ubot5`> Gnome bug 741236 in general "Don't set "titlebar" class when using headerbar widget as a toolbar" [Normal,Unconfirmed]
[08:21] <larsu> darkxst: commented
[08:26] <seb128> darkxst, the bg issue is not only on the headerbar
[08:27] <darkxst> seb128, where? I'm not seeing any background issues under unity
[08:27] <seb128> in the resources tab
[08:27] <seb128> you can see through the graphs
[08:29] <darkxst> seb128, not here, but I do have many more 3.14 components than the archives
[08:29] <seb128> do you use overlay-scrollbars?
[08:31]  * larsu walks backwards silently
[08:32] <seb128> the magical words?
[08:33] <didrocks> larsu: run, run, and don't look back :)
[08:34]  * larsu runs, runs, and doesn't look back
[08:34] <seb128> ...
[08:34] <seb128> joke aside is that an o-s issue?
[08:34] <seb128> is anyone else seeing it?
[08:35] <larsu> very likely, but I haven't tested yet
[08:35] <seb128> k
[08:35] <seb128> let me know if/when you doi
[08:38] <larsu> okay
[08:46] <willcooke> mornign all
[08:47] <seb128> hey willcooke
[08:47] <larsu> morning!
[08:51] <mlankhorst> good morning
[08:53] <didrocks> hey willcooke
[08:54] <willcooke> mlankhorst, heyhey!  My U8 machine is b0rked.  Seems to be a libmir mismatch :(  I'll have to wait for them to fix it before I can play :D
[08:54] <mlankhorst> probably :P
[09:05] <Laney> hello!
[09:05] <larsu> morning Laney!
[09:05] <larsu> and willcooke, mlankhorst
[09:05] <willcooke> hey Laney larsu
[09:06] <mlankhorst> hey
[09:06] <Laney> what's happening
[09:07] <larsu> nothing got done last week. We missed you
[09:08] <willcooke> same
[09:08] <Laney> ah well that was to be expected
[09:08] <Laney> at least you are still alive
[09:08] <didrocks> morning Laney :)
[09:09] <seb128> hey Laney, wb
[09:09] <seb128> had a good week?
[09:09] <Laney> hey didrocks seb128
[09:09] <Laney> good yes, wouldn't say it was relaxing though ;-)
[09:09] <larsu> ha, how's the place coming along?
[09:10] <Laney> couple of rooms are painted now
[09:10] <Laney> some furniture is in place, some more coming today
[09:11] <Laney> need to get a man around to make a concrete base which i can put a bike shed on
[09:11] <Laney> bringing them inside is lame
[09:12] <Laney> nothing seems to have particularly broken from lp mail :-)
[09:12] <larsu> neat
[09:14] <mlankhorst> willcooke: oh looks unity-system-compositor and qtmir had an update, probably why it borked
[09:16] <willcooke> mlankhorst, it was moaning about:
[09:16] <willcooke> /usr/sbin/unity-system-compositor: relocation error: /usr/lib/x86_64-linux-gnu/libmirplatform.so.4: symbol _ZN3mir7logging3logENS0_8SeverityERKSs, version MIR_COMMON_3 not defined in file libmircommon.so.3 with link time reference
[09:16] <willcooke> s/was/is
[09:16] <mlankhorst> apt-cache policy unity-system-compositor
[09:18] <willcooke> unity-system-compositor:
[09:18] <willcooke>   Installed: 0.0.5+15.04.20141204-0ubuntu1
[09:18] <willcooke>   Candidate: 0.0.5+15.04.20141204-0ubuntu1
[09:18] <willcooke>   Version table:
[09:18] <willcooke>  *** 0.0.5+15.04.20141204-0ubuntu1 0
[09:18] <willcooke>         500 http://gb.archive.ubuntu.com/ubuntu/ vivid/universe amd64 Packages
[09:18] <willcooke>         100 /var/lib/dpkg/status
[09:18] <willcooke>      0.0.5+15.04.20141124-0ubuntu2 0
[09:18] <willcooke>         500 http://ppa.launchpad.net/mlankhorst/ppa/ubuntu/ vivid/main amd64 Packages
[09:19] <mlankhorst> yeah figures
[09:19] <willcooke> oki
[09:19] <mlankhorst> just downgrade or wait a bit while I upload new usc and qtmir
[09:19]  * willcooke can wait
[09:19] <willcooke> :)
[09:19] <willcooke> thanks mlankhorst
[09:34] <darkxst> seb128, no I don't use overlay-scrollbars, they break things ;)
[09:35] <seb128> darkxst, k, well try if you get the bg issue with those
[09:36] <seb128> doesn't happen without them it seems
[09:36] <darkxst> seb128, I will try, but thats probably not something I can fix
[09:36] <seb128> k, fair enough
[09:36] <seb128> still a blocker to update the application
[09:37] <seb128> the issue is not happening with the old g-s-m version
[11:36] <mlankhorst> willcooke: ok I've tried, but touch is not going to be handled particularly well right now until mir hasbeen reworked
[11:38] <willcooke> mlankhorst, sorry, what have you been trying?
[11:38] <mlankhorst> getting input to work inside unity8
[11:40] <willcooke> ahh
[11:40] <willcooke> kk
[11:41] <willcooke> mlankhorst, is it worse than on the desktop?
[11:42] <mlankhorst> I just don't have the information I need right now to create a touch device as needed
[11:44] <willcooke> mlankhorst, ack
[11:44] <willcooke> mlankhorst, did you try to get xmir working on a phone device at all?
[11:49] <mlankhorst> haven't tried yet
[12:02] <willcooke> kk
[12:20] <mlankhorst> I'll try updating when I've finished rebuilding unity-system-compositor, qtmir, and xorg-server for armhf :P
[13:16] <mzanetti> hey. so as we didn't really got to a conclusion last week on how to do this, I've filed a bug https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1400312
[13:16] <ubot5`> Launchpad bug 1400312 in unity8-desktop-session (Ubuntu) "On desktop, windowed mode should be the default" [Undecided,New]
[13:17] <mzanetti> if anyone has some thoughts, please add them to that bug
[13:17] <willcooke> thanks mzanetti.  bregma - FYI ^^
[13:23] <bregma> willcooke, mlankhorst, I believe bschaefer got XMir working on the phone, after a fashion
[13:23] <mlankhorst> ok
[13:24] <bregma> dunno what kind of fashion, not the cnv kind yet
[13:24] <mlankhorst> well I've rebuilt all packages that were out of date
[13:24] <bregma> *vnc*
[13:25] <bregma> yeah, I think there were libs missing that were required to do anything useful, but we'll have to wait for him to appear on the aether to ask
[13:27] <mlankhorst> libprotobuf iirc
[13:27] <mlankhorst> I'll try it
[13:27] <mlankhorst> https://launchpad.net/ubuntu/vivid/armhf/libprotobuf9/2.6.1-1
[13:32] <mlankhorst> oh, also needs libepoxy
[13:37]  * didrocks has a working prototype for xfailsafe under systemd \o/
[13:37] <didrocks> spent some time because the lightdm binary behaves differently if renamed (like in a .real) or put in another directory…
[13:39] <didrocks> popey: #troll ;)
[13:40] <xnox> didrocks: you are using OnFailure= & OnFailureJobMode= right?
[13:40] <didrocks> xnox: yeah ;)
[13:40] <xnox> didrocks: cool =) l33t =)
[13:40]  * didrocks ^5s xnox ;)
[13:42] <desrt> g' morning, kids
[13:43]  * xnox has an urge to install mirc and use scripts to start a auto-kick/ban war with didrocks
[13:43] <didrocks> good morning desrt, good week-end?
[13:44] <didrocks> xnox: ahah, last time I did use mirc was end of 2000/early 2001, don't force me to dive again in my old scripts :)
[13:45] <xnox> most importantly I had colors support enabled, no life without bling
[13:45] <didrocks> yummy flashy green :)
[13:46]  * popey hugs didrocks 
[13:47]  * didrocks hugs popey back
[13:49] <seb128> hey desrt, happy monday
[14:01] <cyphermox> good morning!
[14:13] <seb128> hey cyphermox, how are you?
[14:13] <cyphermox> good, you?
[14:21] <seb128> good as well, thanks!
[14:27] <seb128> cyphermox, what are you working on nowadays? n-m? bluetooth? other?
[14:27] <cyphermox> wpa
[14:27] <cyphermox> I'm doing the low-level changes needed so that we get hotspot to work
[14:28] <cyphermox> making sure there is some way to push the buttons needed to bring it up before someone can do the UI part
[14:29] <seb128> cool ;-)
[14:29] <cyphermox> but more recently than that I was getting my ears destroyed by pulse or rhythmbox messing with volume levels when song changes
[14:29] <cyphermox> ouch ;)
[14:30] <seb128> ouch indeed :/
[14:46] <mlankhorst> hm I broke it
[14:46] <Laney> does anyone get hash sum mismatch quite often now?
[14:46] <Laney> when apt-get updating
[14:46] <Laney> Started a few weeks ago for me
[14:47] <mlankhorst> I used to get it sporadically at least
[14:47] <mlankhorst> don't have it on vivid right now
[14:47] <Laney> seems to be on Translation-en most of the time
[14:48] <seb128> Laney, are those error displayed in update-manager? didn't notice anything but it might be that the graphical ui doesn't warn about those
[14:49] <Laney> don't know
[14:49] <seb128> (that's what I use for doing my updates)
[14:49] <Laney> for me sbuild does an update every time and I see it quite a lot then
[14:50] <Laney> just saw https://launchpadlibrarian.net/192106527/buildlog_ubuntu_trusty_amd64_ubuntu-gnome_FAILEDTOBUILD.txt.gz which reminded me
[15:09] <seb128> would be nice if "restart" would do "systemctl restart" when you run systemd init, rather than throwing a dbus error because it fails to contact upstart
[15:12] <cyphermox> haha yeah :)
[15:13] <cyphermox> muscle memory is a pain here
[15:13] <seb128> it's also easier to type "restart" than "systemctl restart"
[15:13] <seb128> we should make "restart" a wrapper
[15:35] <Laney> wtf
[15:35] <Laney> did the system-settings timezone selector break?
[15:40] <seb128> Laney, touch or desktop?
[15:41] <Laney> trying on my desktop
[15:41] <Laney> after I just saw bug #1400353
[15:41] <ubot5`> bug 1400353 in ubuntu-system-settings (Ubuntu) "Timezone label does not show the correct info" [Undecided,New] https://launchpad.net/bugs/1400353
[15:41] <seb128> u-s-s or u-c-c ?
[15:41] <Laney> uss
[15:41] <seb128> u-s-s I guess
[15:41]  * seb128 tries
[15:41] <Laney> it doesn't go back after I select something
[15:41] <seb128> yeah, I can confirm that
[15:41] <Laney> I think it's not getting the changed signal
[15:41] <Laney> TIMEDATEDDDDDDDDDD
[15:42] <seb128> you think it's a systemd issue?
[15:42] <Laney> dunno
[15:42] <Laney> that's supposed to happen on the propertychanged signal though
[15:42] <Laney> lemme monitor this
[15:42] <Laney> does it work on phone still?
[15:43] <seb128> on rtm yes
[15:43] <seb128> I don't have a vivid device
[15:45] <Laney> huh
[15:45] <Laney> some of the properties have EmitsChangedSignal but not timezone
[15:46] <Laney> that's EmitsChangedSignal("false") though
[15:48] <Laney> indeed I see the signal
[15:48] <Laney> maybe this is in the u-s-s part then ;-)
[15:49] <seb128> weird, I don't think that backend changed at all in vivid
[15:51] <Laney> ah
[15:51] <Laney> I think I see
[15:52] <seb128> nice
[16:05] <willcooke> qengho, heyho!  When I hover over a link in Chromium I dont see the full URL show up at the bottom of the screen.  Has it been that way for a while?
[16:06] <qengho> willcooke: Yes, ages.
[16:06]  * willcooke no like
[16:06] <qengho> Oh, wait, you *don't* see i?
[16:06] <willcooke> ;)
[16:06] <willcooke> yeah, dont see it
[16:06] <willcooke> Googling to look for a fix...
[16:08] <qengho> willcooke: you should see that. Could be a scaling problem, if you have the display-density ratio set not to 1.
[16:08] <willcooke> erm, I don't know what that is, so I'm gonna say no
[16:10] <willcooke> "status bubble" seems to be the thing
[16:10] <qengho> willcooke: $ dconf read /com/ubuntu/user-interface/scale-factor   # is your display "8"?
[16:11] <willcooke> yeah, all 8s
[16:11]  * qengho boggles.
[16:11] <willcooke> I wonder if its an extension
[16:11]  * willcooke tests a theory
[16:12] <willcooke> yarp
[16:12] <willcooke> qengho, works fine in incognito mode
[16:12] <qengho> Weeeird.
[16:12] <willcooke> seems to be just my "home" profile which is doing it
[16:14] <qengho> willcooke: I can reproduce on one computer.
[16:15] <willcooke> qengho, Hrm - I got it working again very quickly by disabling all my extensions, but now it's broken again
[16:20] <willcooke> qengho, odd.  If I open a new *window* it works again
[16:20] <willcooke> new tab in old window, broken
[16:20] <willcooke> ?!?!
[16:21] <willcooke> I'll killall Chromiums later on and see if that fixes it.
[16:22] <mlankhorst> willcooke: ok it seems to work now with the vivid-proposed branch :P
[16:22] <willcooke> mlankhorst, woot!
[16:22] <qengho> willcooke: will you file a bug report, please? I'll add it to my to-do list.
[16:23] <willcooke> qengho, sure thing.  I'll double check it's not just me, and then I'll open one
[16:29] <seb128> didrocks, pitti, hey, is that known that applications fail to start under unity8 desktop-next when using systemd as init, seems that unity8-dash calls to cgmanager and that is not working as it should
[16:31] <didrocks> seb128: that wasn't tested as far as I know and really worth a bug, please!
[16:31]  * didrocks wonders for how long xdiagnose is broken btw
[16:31] <didrocks> I would say 2011, since we switched to lightdm
[16:32] <seb128> didrocks, pitti, other issue, is that know that the keyboard layout is wrong on vts using systemd
[16:32] <seb128> I just noticed it's back to azerty when booting with upstart
[16:32] <seb128> I assumed my config was buggy on that test machine
[16:32] <didrocks> seb128: I know it, didn't log a bug for it yet, just need to find some time to dig in why
[16:32] <seb128> k
[16:32] <didrocks> seb128: not your config, having it as well :p
[16:32] <seb128> opening a bug there as well then
[16:32] <didrocks> thanks
[16:40] <seb128> didrocks, pitti, bug 1400393 and bug 1400394
[16:40] <ubot5`> bug 1400393 in systemd (Ubuntu) "wrong keyboard layout" [Undecided,New] https://launchpad.net/bugs/1400393
[16:40] <ubot5`> bug 1400394 in systemd (Ubuntu) "Unity8 fails to start applications under systemd init (cgmanager issue?)" [Undecided,New] https://launchpad.net/bugs/1400394
[16:41] <Laney> oh, systemd bugs time?
[16:41] <Laney> laney@iota> gdbus call --system --dest org.freedesktop.timedate1 --object-path /org/freedesktop/timedate1 --method org.freedesktop.timedate1.SetNTP true false
[16:41] <Laney> Error: GDBus.Error:org.freedesktop.DBus.Error.FileNotFound: Unknown unit: systemd-timesyncd.service
[16:42] <didrocks> seb128: thanks!
[16:42] <seb128> Laney, indeed!
[16:42] <didrocks> mlankhorst: you told me to not break xdiagnose, but it never worked (maybe for some years) :p
[16:43] <didrocks> mlankhorst: did you try it recently?
[17:20] <seb128> desrt, larsu, Laney, it's fine to have a gsettings override for a schemas which is not installed, right?
[17:20] <desrt> yes
[17:20] <seb128> thanks for confirming
[17:21] <desrt> hmm.  maybe.
[17:21] <desrt> you'll get an error message, but it's not fatal
[17:21] <desrt> oh wait.  that's for missing keys
[17:21] <mlankhorst> didrocks: not really
[17:21] <desrt> for missing schemas you're totally fine
[17:22] <desrt> even has a comment:
[17:22] <desrt>   /* Having the schema not be installed is expected to be a
[17:22] <desrt>    * common case.  Don't even emit an error message about
[17:22] <desrt>    * that.
[17:22] <seb128> great
[17:22] <seb128> I confirmed it doesn't throw errors/warnings
[17:22] <seb128> desrt, thanks
[17:22] <didrocks> mlankhorst: yeah clearly broken since we switched to lightdm. I'll try to have the minimal patch to make it work again on upstart and systemd
[17:23] <didrocks> mlankhorst: but not prettifying this so much as it will probably change with mir
[17:23] <didrocks> (at least, under systemd, it will support all dms, not just gdm)
[17:33] <seb128> cyphermox, btw, saw my comment on https://code.launchpad.net/~mathieu-tl/ubuntu-system-settings/unbreak-hid/+merge/243592 ?
[17:33] <seb128> larsu, how is the gtk update going? I would like to land that this week if we can, before people start being in holidays, etc
[17:34] <larsu> seb128: writing a commit message for the large-icons-in-menus problem
[17:34] <seb128> some other teams, like the GNOME remix one, could probably use the newer version being in the archive before january
[17:34] <seb128> larsu, excellent ;-)
[17:34] <larsu> seb128: unity will have to be updated as well (for the gvim problem)
[17:34] <seb128> hum
[17:35] <seb128> it means gtk changed in an incompatible way that is going to force random clients to change their code to go back to have results similar to what they had before?
[17:35] <larsu> to be fair, it wasn't acting according to the xdg spec before
[17:35] <larsu> now it is...
[17:36] <larsu> we _could_ of course patch it
[17:36] <seb128> yeah
[17:36] <larsu> desrt: what's your opinion on this btw? ^
[17:36] <seb128> non spec compliant behaviour are unfortunate
[17:36] <seb128> it doesn't mean we want to make incompatible changes to fix those
[17:37] <seb128> can we easily revert a commit to go back to the old behaviour if needed?
[17:37] <seb128> oh and more important question
[17:37] <seb128> is there a way to write code that work on old&new gtk the same way?
[17:38] <larsu> no, but going to something that should be 99% of the old behavior is a one line patch
[17:38] <seb128> or is the fix to use a new api/flag that is only in > 3.12?
[17:38] <larsu> (which I proposed but was rejected, since it isn't according to the spec)
[17:38] <larsu> seb128: it will work for both
[17:38] <seb128> ok
[17:38] <larsu> basically you need to explicitely say "I want this icon in that size, regardless of what the theme has"
[17:38] <seb128> I think my vote is to land without revert and see how much issue we get back through report
[17:38] <seb128> similar to the labels wrapping
[17:38] <larsu> "scale it and make it look shitty if needed"
[17:39]  * larsu nods
[17:39] <seb128> if it turns out we think we are not going to fix enough code this cycle we can do the non-spec-compliant change for another cycle
[17:39] <seb128> wdyt?
[17:39] <desrt> larsu: sorry.. not following close enough to have an opinion at the moment
[17:45] <larsu> desrt: gtkicontheme doesn't scale icons anymore if the theme doesn't have icons in the right size. Here's a fix for gtkmodelmenuitem if you have time for a review: https://bugzilla.gnome.org/show_bug.cgi?id=741259
[17:45] <ubot5`> Gnome bug 741259 in .General "gtkmodelmenuitem: force icon scaling" [Normal,New]
[17:45] <desrt> you mean like if a theme installs a 64x64 icon in the 22x22 folder?
[17:46] <larsu> no
[17:46] <desrt> i can't review this patch
[17:46] <larsu> more like if a theme has the icon, but not in the size you requested it in
[17:46] <desrt> beyond saying that i'm pretty sure it's not faithful to the old behaviour
[17:46] <larsu> how do you mean?
[17:46] <desrt> this patch seems to be nicer than the old behaviour
[17:47] <larsu> the old behavior is totally broken right now
[17:47] <desrt> specifically it seems to care about picking the right icon for the current font size
[17:47] <desrt> rather than (more or less) hardcoding "this is the size of icons in menus"
[17:47] <larsu> right, that's the best metric I could think of
[17:47] <larsu> and will make mpt happy
[17:47] <desrt> <- this is my unhappy face
[17:47] <larsu> desrt: well, I could put set_pixel_size(16)  if that makes you happier
[17:48] <desrt> problem is that you still ask for ICON_SIZE_MENU
[17:48] <larsu> I thought I might as well react to font size changes now that I'm at it
[17:48] <desrt> so you could end up getting a 16x16 and scaling it up to 18x18
[17:48] <larsu> right, that's the plan
[17:48] <desrt> on second thought, i will review this :p
[17:49] <larsu> let's talk in #gtk about it, mclasen did the icon change
[17:49] <larsu> and he'll surely have an opinion as wel
[17:49] <mpt> You realize you won’t escape from me by going to #gtk+, right
[17:49] <larsu> I know you're in there as well
[17:50] <larsu> but I don't think you'll be interested apart from "icons in menus will now be scaled to the font size"
[17:50] <larsu> (also when the font size changes)
[17:51] <larsu> mpt: you're welcome to follow the dicsussion, of course ;)
[17:51] <mpt> That’s good as far as it goes, but I’m not sure you should be scaling 16*16 up to 18*18 :->
[17:52] <larsu> but show the small icon instead?
[17:52] <larsu> what would be the threshold at which we start scaling then?
[17:52] <mpt> Well, hmm, I guess when you’re laying out a particular item you don’t know the size of all the resources used in all the other items, do you
[17:54] <larsu> nope
[17:54] <larsu> well, they're all the same actually
[17:54] <mpt> I was thinking, if an icon is “close enough” to ICON_SIZE_MENU, scaling it a small amount would be worse than it being slightly too small … But it being slightly smaller than icons in adjacent menu items would be even worse
[17:54] <larsu> right
[17:55] <mpt> ok
[17:55] <larsu> good themes could specify that you can only use .pngs when the size is exactly right
[17:55] <larsu> and use scalable for the in-between cases
[17:55] <larsu> which is slower and doesn't look as good, but probably better than scaling a png
[17:56] <mpt> So, two things irritate me about menu icon sizes: (A) when they make menu items very slightly taller than normal, so the menu looks slightly wrong but it’s hard to tell why, and (B) when an icon in the menu title is a different size from the same icon in a menu item (e.g. the keyboard menu)
[17:58] <larsu> my approach should fix (A), and we can only solve (B) by making icons in the panel smaller
[17:58] <larsu> or the menu items larger, but we'd need to do that everwhere
[18:00] <mpt> A little bit of both, I think
[18:01] <mpt> but yay for (A) :-)
[18:03] <larsu> mpt: what do you mean by that?
[18:04] <larsu> wouldn't we need to redraw icons in some in-between size, then?
[18:04] <larsu> I think the panel uses exactly one size larger than the menu items
[18:05] <larsu> seb128: can we wait until upstream acks this patch? This is the second approach I'm trying (after lengthy discussion) and I'd prefer it if we backported the solution that we will eventually take
[18:06] <mpt> larsu, as in for the keyboard menu, the title icon looks ~2px too tall while the menu item icons look ~2px too short
[18:06] <seb128> larsu, yes, I would like to upload gtk this week, but there is no hurry
[18:06] <seb128> larsu, we can wait a few days
[18:06] <Laney> is there a new branch?
[18:06] <larsu> seb128: ok, I'll try to hurry it
[18:06] <seb128> larsu, thanks
[18:07] <seb128> Laney, new branch of?
[18:07] <larsu> Laney: no, just the theme fixes and an size-menu-icons-correctly patch
[18:07] <seb128> Laney, there was no change on gtk since you uploaded, only theme work
[18:07] <larsu> Laney: https://bugzilla.gnome.org/show_bug.cgi?id=741259
[18:07] <ubot5`> Gnome bug 741259 in .General "gtkmodelmenuitem: force icon scaling" [Normal,New]
[18:07] <Laney> ok
[18:07] <seb128> Laney, but having ubuntu-themes in the ppa might be a good idea
[18:09] <Laney> ya, where's that then?
[18:09] <larsu> mpt: indeed. and that one does show signs of (A)
[18:09] <mlankhorst> looks like ubuntu-desktop barely fits inside the phone :P
[18:11] <seb128> Laney, the theme work? https://code.launchpad.net/~larsu/ubuntu-themes/gtk-314
[18:12] <Laney> ok
[18:12] <Laney> I'll do that tomorrow
[18:19] <seb128> thanks
[18:32] <Laney> see you!
[18:34] <didrocks> phew, failsafe xorg mostly fixed and working with systemd!
[18:34] <didrocks> (I guess it will make it working back with upstart as well)
[18:34] <didrocks> see you tomorrow guys
[18:52] <Noskcaj> seb128, g-s-m should be fixed now
[19:08] <seb128> Noskcaj, including the fact that the graphs have no bg when using with unity/overlay-scrollbars?
[19:08] <Noskcaj> should be
[19:11] <robert_ancell> willcooke, ready when you are
[19:11] <willcooke> hey robert_ancell
[19:25] <cyphermox> seb128: ok, I responded
[19:26] <seb128> cyphermox, thanks
[19:29] <seb128> Noskcaj, that change is not going to be enough, it's just about the headerbar where it's the page bg which is not displayed
[19:29] <seb128> likely an interaction with the theme or the scrollbars issue
[19:29] <Noskcaj> darkxst, ^
[19:35] <willcooke> gnight all
[20:51] <darkxst> Noskcaj, that is probably not something I can fix
[20:52] <Noskcaj> ok
[20:52] <darkxst> g-s-m was ported to GtkStack, so could be a theme issue related to that I guess
[21:09] <larsu> who packages gvim? Looks like fedora has one with proper icons: https://bugzilla.gnome.org/show_bug.cgi?id=741259#c7
[21:09] <ubot5`> Gnome bug 741259 in .General "gtkmodelmenuitem: force icon scaling" [Normal,New]
[21:17] <seb128> larsu, Debian, https://packages.qa.debian.org/v/vim/news/20141201T013401Z.html should fix it
[21:17] <seb128> larsu, but again, that's a specific case, the fix is not to patch gvim, it's only one software
[21:18] <larsu> seb128: ya, just saying
[21:18] <seb128> larsu, the fix from Debian is http://anonscm.debian.org/hg/pkg-vim/vim/rev/ed3311f256dc
[21:18] <seb128> I'm going to have a look tomorrow
[21:18] <seb128> need to go
[21:18] <seb128> see you tomorrow
[21:18] <larsu> see you!
[21:19] <desrt> seb128: good night!
[21:58] <darkxst> larsu, any idea why overlay scrollbars would make background transparent when switching tabs with GtkStack (in g-s-m)?
[21:58] <darkxst> it does not even draw any overlay scrollbars
[21:58] <darkxst> and the background is drawn correctly at startup
[22:01] <larsu> darkxst: yes, we've had these problems for a while. overlay-scrollbars hacks the scrolled windows (and those of the scrollbar) to be a native, and gtk doesn't properly inherit style classes across those
[22:01] <larsu> which means you get the default background for them, which is transparent
[22:02] <larsu> we fixed those by explicitely setting a background for the widgets that might be scrolled
[22:02] <larsu> the real fix will be to get rid of o-s, or switch to the ones gtk has now
[22:06] <darkxst> larsu, but these are not scrolled windows just GtkBox's
[22:08] <larsu> darkxst: but they're inside the scrolled windows, which don't inherit background, so they don't inherit it either
[22:22] <darkxst> larsu, ok, so I just force a background on GtkStack Widget then?
[22:25] <larsu> darkxst: iirc, we can't do that, becasue it breaks other apps
[22:25] <larsu> this is a bit of a minefield
[22:26] <darkxst> larsu, in g-s-m, not the theme?
[22:26] <larsu> darkxst: in the theme
[22:28] <darkxst> I meant should I force the background in g-s-m?
[22:29] <larsu> and I meant no, in the theme
[22:41] <darkxst> so this need to be fixed in the theme?
[22:45] <larsu> yes
[22:47] <darkxst> ok