15:06:24 <jreznik> #startmeeting kde-sig -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2012-01-17
15:06:24 <zodbot> Meeting started Tue Jan 17 15:06:24 2012 UTC.  The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:06:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:06:32 <jreznik> #meetingname kde-sig
15:06:32 <zodbot> The meeting name has been set to 'kde-sig'
15:06:42 <jreznik> #topic roll call
15:06:48 <jreznik> hi, who is here?
15:06:51 * rnovacek is here
15:06:54 * ltinkl is present
15:07:02 <rdieter> here
15:07:09 <Kevin_Kofler> Present.
15:07:14 <than> present
15:08:07 * nucleo is here
15:08:16 <jreznik> #chair nucleo rnovacek ltinkl rdieter Kevin_Kofler than
15:08:16 <zodbot> Current chairs: Kevin_Kofler jreznik ltinkl nucleo rdieter rnovacek than
15:08:30 <jreznik> #info Kevin_Kofler jreznik ltinkl nucleo rdieter rnovacek than present
15:08:45 <jreznik> #topic Agenda
15:08:56 <jreznik> we have a few topics on agenda today, anything else?
15:10:47 <jreznik> seems like we can start
15:10:59 <jreznik> #topic oxygen-gtk3 by default – how to implement
15:11:15 <Kevin_Kofler> So we're still at the point where we left off last week.
15:11:30 <Kevin_Kofler> We agreed we want this, but we still don't know how to do it.
15:11:33 <Kevin_Kofler> The issue is:
15:11:40 <ltinkl> isn't there a README somewhere in oxygen-gtk3? :)
15:11:47 <Kevin_Kofler> * doing this through XSettings breaks support for using a different theme in GTK+ 2 than in GTK+ 3
15:12:00 <Kevin_Kofler> Only oxygen-gtk and Adwaita are available for both.
15:12:09 <Kevin_Kofler> So it basically restricts theme selection to those 2 at this time.
15:12:40 <jreznik> with a lot of apps moving to gtk3 I don't see it as constraint
15:12:42 <Kevin_Kofler> * doing this through config files is global, i.e. it affects not only KDE Plasma sessions, but all sessions not using their own XSettings
15:12:51 <nucleo> README http://fpaste.org/4OeD/raw/
15:13:16 <jreznik> but affecting another sessions is bad...
15:13:22 <Kevin_Kofler> ltinkl: The oxygen-gtk3 README can't really help here, the problem is the restrictions in GTK+ 3.
15:13:24 <ltinkl> local config file?
15:13:55 <Kevin_Kofler> ltinkl: GTK+ 3 supports only 2 hardcoded paths for settings, ~/.config/gtk-3.0/settings.ini and /etc/gtk-3.0/settings.ini, that's it.
15:14:07 <Kevin_Kofler> And XSettings, where Net/ThemeName is used for both GTK+ 2 and 3. :-/
15:14:34 <Kevin_Kofler> There's no equivalent to GTK2_RC_FILES, which was used previously.
15:14:54 <ltinkl> file a bug report and request GTK3_RC_FILE?
15:15:00 <Kevin_Kofler> Oh, the theme can also provide a settings.ini, but obviously that doesn't help for setting the theme.
15:16:13 <Kevin_Kofler> ltinkl: Can you do this, diplomatically? :-)
15:16:22 <than> Kevin_Kofler: imo adding GTK2_RC_FILES is a clean solution
15:16:26 * Kevin_Kofler somehow always comes off as rude. :-(
15:16:41 <ltinkl> so, using $HOME/.config/gtk-3.0/settings.ini, does gtk-theme-name = oxygen-gtk in theory support multiple themes
15:16:54 <ltinkl> like gtk-theme-name = oxygen-gtk, adwaita
15:17:00 <Kevin_Kofler> No.
15:17:04 <Kevin_Kofler> It wouldn't help, anyway.
15:17:25 <Kevin_Kofler> Maybe one could code a magic metatheme which loads another theme based on parameters, but that sounds like an ugly hack to me!
15:17:44 <jreznik> :)
15:18:01 <Kevin_Kofler> (gtk-theme-name=maybe-oxygen ^^)
15:18:08 <ltinkl> my idea was the config file parser would fall back to the second entry when the 1st one isn't available
15:18:12 <Kevin_Kofler> (where maybe-oxygen would then figure out what desktop is running, ugh…)
15:18:38 <Kevin_Kofler> ltinkl: I don't think that's a good solution.
15:18:53 <jreznik> the metatheme neither
15:18:55 <Kevin_Kofler> We want KDE SC and GNOME to coexist without them breaking each other's settings.
15:19:12 <Kevin_Kofler> The metatheme isn't even coded, so I don't think that's a serious option. ;-)
15:19:19 <nucleo> GNOME not uses settings.ini
15:19:35 <Kevin_Kofler> True, GNOME overrides the settings through XSettings anyway.
15:19:42 <ltinkl> nucleo: what does it use?
15:19:54 <Kevin_Kofler> ltinkl: XSettings through gnome-settings-daemon
15:20:02 <Kevin_Kofler> (which is why it doesn't support separate GTK+ 2 and 3 themes)
15:20:11 <ltinkl> so, gtk2 apps look alien in gnome 3? :)
15:20:27 <Kevin_Kofler> They have Adwaita for GTK+ 2.
15:20:41 <Kevin_Kofler> It isn't exactly the same as Adwaita for GTK+ 3, but just a slightly modified Clearlooks.
15:20:48 <Kevin_Kofler> But it has the same name.
15:20:56 <Kevin_Kofler> Which is how XSettings works.
15:21:05 <rdieter> we've discussed it in #fedora-kde a few times already, my own conviction is that xsettings-kde is the best viable option right now.
15:21:19 <Kevin_Kofler> There are several environments which aren't using XSettings and we WOULD affect them by setting settings.ini directly.
15:21:37 <ltinkl> I see
15:21:44 <ltinkl> rdieter: probably yes
15:21:47 <Kevin_Kofler> I can implement the xsettings-kde stuff, but it'll likely mean no separate theme setting for GTK+ 2 and 3.
15:21:54 <rdieter> without changes in gtk3 to support it better anyway
15:22:05 <Kevin_Kofler> Unless we can get gtk3 to add a Gtk3/ThemeName XSetting, with fallback to Net/ThemeName.
15:22:06 <rdieter> Kevin_Kofler: right, same as gnome
15:22:17 <jreznik> Kevin_Kofler: as I said, it's not an issue to have same gtk2/3 theme, actually it makes sense
15:22:35 <Kevin_Kofler> jreznik: But there's no Bluecurve for gtk3… ;-(
15:23:12 <Kevin_Kofler> I did the Qt 4 port, but I don't feel competent to do the gtk3 port, sadly.
15:23:41 <Kevin_Kofler> Looking at how many changes oxygen-gtk3 needed, it'd be a lot of work.
15:23:53 <rdieter> as an aside, need to poke the mandriva/mageia folks currently hosting xsettings-kde and get it into projects.kde.org
15:23:59 <Kevin_Kofler> But I'm probably the only one who still cares about Bluecurve anyway. ^^
15:24:13 <Kevin_Kofler> So if we go with the XSettings approach, that'll mean:
15:24:32 <Kevin_Kofler> 1. I'll unapply the GTK+ 3 patch from Rawhide's kcm-gtk, restoring the single theme dropdown.
15:24:36 <Kevin_Kofler> and
15:25:02 <Kevin_Kofler> 2. I'll patch xsettings-kde to set Net/ThemeName from that .gtkrc-2.0-kde4 file kcm-gtk writes out.
15:25:14 <Kevin_Kofler> Comments? Objections?
15:25:39 <Kevin_Kofler> (other than "there can't be separate GTK+ 2 and 3 themes anymore", I know that, it is why I've been opposed to doing this through XSettings all this time, but…)
15:26:23 * jreznik expects a lot of app to be ported to gtk3 already... it's like supporting qt 3 apps
15:26:38 <rdieter> Kevin_Kofler: oh, parsing .gtkrc may or may not be fun (probably the latter).  didn't think of that.  longer term, kcm-gtk may need to save that in kconfig somewhere
15:27:24 <rdieter> but that's just an implementation detail, whatever as long as it works
15:28:36 <Kevin_Kofler> I think parsing the gtkrc will be the least of the worries.
15:28:59 <jreznik> Kevin_Kofler: I'm +1 for your proposal
15:29:24 <Kevin_Kofler> So, other ±1 (yes/no) votes for/against the proposal?
15:29:46 <rnovacek> +1
15:30:26 <ltinkl> plus one
15:31:26 <Kevin_Kofler> Last implementation detail: What do I do if there's no gtkrc-kde4 from kcm-gtk, or if there's no theme name in it? (1) Nothing, i.e. leave Net/ThemeName unset and let GTK+ fallback to gtkrc/settings.ini or the builtin (ugly) default? (2) Set Net/ThemeName=oxygen-gtk? or (3) Set Net/ThemeName=Adwaita?
15:31:56 <Kevin_Kofler> (It shouldn't affect us because we have a default setting in kde-settings, but it affects the xsettings-kde code.)
15:32:35 <rdieter> Kevin_Kofler: my common-sense-o-meter says if it's unset, do nothing
15:33:01 <Kevin_Kofler> Yeah, nothing in, nothing out. :-)
15:33:09 <Kevin_Kofler> (i.e. Not My Problem :-p)
15:33:38 <rdieter> agreed
15:35:43 <Kevin_Kofler> Next topic?
15:36:15 <rdieter> eep
15:36:32 <rdieter> #topic KWin desktop effects on llvmpipe
15:36:36 <rdieter> better
15:37:18 <rdieter> so, looks like some whitelisting is required to make kwin effects work on llvmpipe
15:37:38 <Kevin_Kofler> I think we should 1. enable this in Rawhide ASAP and 2. lobby to get this enabled upstream.
15:37:39 <rdieter> in short, need someone to lead/champion this effort
15:37:47 <Kevin_Kofler> llvmpipe is now expected to work with desktop effects.
15:37:54 <rdieter> and coordinate with kwin upstream
15:38:07 * jreznik tried it, works in VM (with checks disabled)
15:38:14 <Kevin_Kofler> Mesa upstream tests gnome-shell, at least.
15:38:22 <rdieter> any sucker^M^M^M, volunteer?
15:38:40 * jreznik can try but can't promise that ASAP
15:39:26 <rdieter> relatedly, kde-settings-4.8-1+ dropped the kwinrc [Compositing] Enabled=false
15:39:53 <ltinkl> rdieter:  how is this handled now, everything enabled?
15:40:21 <jreznik> I'm still not convinced we should enable effects by default... drivers are still not ready
15:40:22 <rdieter> ltinkl: I believe unpatched kwin disables all software effects, including llvmpipe
15:40:50 <rdieter> that's why it requires some work and coordination here
15:41:13 <Kevin_Kofler> Yes, there's a blacklist on software renderers which includes llvmpipe now, it needs to be unblacklisted.
15:41:25 <rdieter> jreznik: that is a valid concern
15:41:49 <Kevin_Kofler> Then check what effects are too slow, if any, and disable them by default.
15:42:00 <Kevin_Kofler> One KWin developer claimed Blur is too slow on llvmpipe, to be verified.
15:42:13 <Kevin_Kofler> (Blur IS GPU-intensive, indeed.)
15:42:22 <jreznik> rdieter: on my workstation it leads to lockups, on laptop and netbook it's too slow (even with nearly all effects disabled...)
15:42:33 <ltinkl> jreznik: blur?
15:42:40 <jreznik> ltinkl: turned off
15:42:41 <Kevin_Kofler> jreznik: GNOME has been enabling desktop effects by default on Fedora for a couple releases, KDE upstream for even longer.
15:42:51 <Kevin_Kofler> We're the only ones who disabled them.
15:43:14 <jreznik> Kevin_Kofler: yep, but gnome-shell is unusable on my hw as it's incredibely slow (when I tested it)
15:43:29 <Kevin_Kofler> And KDE upstream wants to require compositing for more and more things.
15:43:42 <jreznik> I know, I don't have latest greatest fastest machines :)
15:43:53 <Kevin_Kofler> You can disable the effects. :-)
15:43:54 <jreznik> Kevin_Kofler: yep, that's unfortunate :(
15:44:18 <Kevin_Kofler> Secure screen locking in 4.9, Aurorae window decorations in 4.9 (or later, but probably 4.9) etc.
15:44:32 <rdieter> ok, so the option to enable/disable effects by default can be part of this coordination with upstream
15:44:39 <jreznik> Kevin_Kofler: I know how to do it but if it crashes, even colleagues here are f*d up :(
15:44:40 <Kevin_Kofler> (We might even pick up the new screen locker earlier through Plasma Active patches.)
15:45:00 <ltinkl> Kevin_Kofler: no reason to rush that :)
15:45:01 <jreznik> for 4.9 it's the must, really
15:45:24 <Kevin_Kofler> ltinkl: I think the new screen locker should wait for having at least some screensavers to offer to the screensaver fans. :-)
15:45:44 <jreznik> #info we want llvmpipe support, coordination with upstream is needed because of blacklisting/whitelisting
15:46:01 <ltinkl> Kevin_Kofler: well the screen locker is rather trivial, I'm waiting to see the Device Notifer and Battery applets :)
15:46:24 <Kevin_Kofler> ltinkl: No need to backport those…
15:46:43 <Kevin_Kofler> AIUI, Plasma Active works fine with the old C++ applets, too.
15:46:45 <jreznik> ok guys - I think I can try to poke around about llvmpipe, so I'll be that sucker :)
15:46:54 <ltinkl> Kevin_Kofler: nope, I want to see them work first, knowing the number of fixes I had put into those 2 in the past
15:47:29 <rdieter> jreznik: you don't have to do all the work, but it helps just to have a 'leader' to coordinate the efforts.
15:47:30 <Kevin_Kofler> We should only apply the patches to shared Plasma components from Active where they're needed to make Active work properly, not mindlessly backport stuff.
15:47:54 <Kevin_Kofler> jreznik: Maybe the effects on llvmpipe might actually work better than on hardware rendering for you. :-)
15:48:17 <Kevin_Kofler> It might make sense to have some way to get KWin and only KWin started with LIBGL_ALWAYS_SOFTWARE.
15:48:17 <jreznik> Kevin_Kofler: that's why I volunteer :) but it's even old cpu... but on ws it could be ok
15:48:40 * jreznik will try to poke upstream
15:48:41 <Kevin_Kofler> (There is some support of that kind for LIBGL_ALWAYS_INDIRECT, so…)
15:49:19 <jreznik> #action jreznik to coordinate LLVM pipe/desktop effects by default effort
15:50:14 <Kevin_Kofler> Next topic?
15:50:32 <rdieter> #topic FTBFS trainwreck
15:51:02 <rdieter> got a lot of work to do, thankfully most of the fixes required are relatively simple
15:51:51 <rdieter> our own biggest concern initially is qt, of course
15:52:14 <Kevin_Kofler> The legacy stuff (kdelibs3 etc.) is also quite broken, I'll try to fix that.
15:52:24 <Kevin_Kofler> But also some modern packages FTBFS.
15:52:41 <Kevin_Kofler> g++ has once again broken the world. :-(
15:53:02 <than> ltinkl: any news about build failure with gcc-4.7 in qt?
15:53:15 <ltinkl> than: unfortunately not
15:53:34 <ltinkl> tried to poke Jakub several times on IRC, no reply to my email either :/
15:53:51 <jreznik> do we have a list?
15:53:57 <than> ltinkl: as i know i was on vacation last week
15:54:01 <than> s/i/he
15:54:05 <jreznik> ltinkl: he was on vacation
15:54:10 <ltinkl> than: that might explain it
15:54:15 <ltinkl> I will try again
15:54:23 <than> ltinkl: he will to contact him
15:54:24 <siddvicious> meeting over ?
15:54:27 <rnovacek> http://ausil.fedorapeople.org/f17-failures.html
15:54:31 <siddvicious> ltinkl: hiya
15:54:49 <than> qt is not on the list!
15:55:17 <Kevin_Kofler> Maybe it's already fixed? Let me check in Koji.
15:55:25 <than> Kevin_Kofler: not yet
15:55:41 <than> Kevin_Kofler: i have tried to build with new gcc
15:55:53 <than> Kevin_Kofler: same errors
15:56:04 <ltinkl> qt-webkit fails with: g++: error: unrecognized command line option '-fuse-ld=gold'
15:56:24 <ltinkl> what is that? :)
15:56:25 <than> ltinkl:  it's a bug in gcc
15:56:33 <Kevin_Kofler> Looks like Qt was not included in the mass rebuild for some reason.
15:56:47 <Kevin_Kofler> Which is why it doesn't show up in the list of failures.
15:56:59 <than> ltinkl: -fuse-ld=gold is used to save memory by linking
15:57:04 <Kevin_Kofler> ltinkl: It's qt-webkit attempting to force gold as the linker.
15:57:13 <Kevin_Kofler> And apparently the flag it uses for that is not valid.
15:57:38 <than> Kevin_Kofler: we need to check
15:57:38 <Kevin_Kofler> Either GCC is broken for no longer supporting the flag, or QtWebKit is using an invalid flag and thus broken.
15:58:08 <rdieter> I assume that's the same reason qtwebkit ftbfs too
15:58:18 <than> rdieter: exactly
15:59:09 <Kevin_Kofler> It might be worth trying to get qt to build its QtWebKit-using stuff against a system qtwebkit instead of the current hack…
15:59:20 <Kevin_Kofler> (needs QMake .pro file magic)
15:59:45 <jreznik> guys, could you endmeeting? I have to go to anoher one...
15:59:57 <Kevin_Kofler> Of course that'd be a circular dependency, but there are no more ABI bumps planned for Qt 4…
16:00:05 <Kevin_Kofler> (4.8.x is supposed to be compatible both ways.)
16:00:30 <Kevin_Kofler> Not sure about QtWebKit though, hopefully they won't bump ABI in a way that a Qt built against 2.2.x breaks with 2.3.x or 3.0.x or whatever they release next.
16:01:15 <Kevin_Kofler> Ideally we'd disable QtWebKit support entirely in our qt, but that breaks at least Assistant.
16:01:27 <Kevin_Kofler> (We tried, the help looked ugly.)
16:02:09 <Kevin_Kofler> The qt FTBFS isn't in the bundled qtwebkit anyway.
16:02:31 <Kevin_Kofler> It's in the atomic stuff, with the issues of overloading methods in templated types.
16:04:30 <rdieter> i'd love to build against system qtwebkit, no one's been able to work on it though (including myself)
16:05:13 <rdieter> anyway, jreznik's right, we're over time.  we'll just have to keep chipping away at all the failed builds
16:05:16 <rdieter> thanks all
16:05:20 <rdieter> #endmeeting