kde-sig
LOGS
15:02:24 <jreznik> #startmeeting kde-sig -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2012-01-10
15:02:24 <zodbot> Meeting started Tue Jan 10 15:02:24 2012 UTC.  The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:33 <jreznik> #meetingname kde-sig
15:02:33 <zodbot> The meeting name has been set to 'kde-sig'
15:02:45 <jreznik> #topic roll call
15:02:55 <jreznik> hi all! who's present today?
15:03:42 * rnovacek is here
15:03:46 * ltinkl is here
15:06:00 <rdieter> here
15:06:53 <Kevin_Kofler> Present.
15:07:11 <jreznik> #chair jreznik rnovacek ltinkl rdieter Kevin_Kofler
15:07:11 <zodbot> Current chairs: Kevin_Kofler jreznik ltinkl rdieter rnovacek
15:07:22 <jreznik> #info jreznik rnovacek ltinkl rdieter Kevin_Kofler present
15:07:42 <jreznik> #topic agenda
15:07:59 <jreznik> agenda is clean like a water, topics please :)
15:08:57 <rdieter> followup of pkg rename reviews (from last week), progress, work still to do...
15:09:16 <Kevin_Kofler> oxygen-gtk3 by default for KDE Plasma sessions.
15:10:20 <jreznik> ok, added... anything else?
15:10:21 <rdieter> qt ftbfs on rawhide (though not much discussion needed, just that someone needs to look into what gcc47'ism is causing the problem this time)
15:10:41 <Kevin_Kofler> build log?
15:11:13 <jreznik> ok, let's start with it
15:11:25 <jreznik> #topic qt ftbfs on rawhide
15:12:01 <rdieter> failed build here, http://koji.fedoraproject.org/koji/buildinfo?buildID=282502
15:12:20 <jreznik> #link http://koji.fedoraproject.org/koji/buildinfo?buildID=282502
15:12:27 <rdieter> type/qbuiltinatomictypes_p.h:390:46: error: 'virtual QPatternist::AtomicTypeVisitorResult::Ptr QPatternist::DerivedIntegerType<DerivedType>::accept(const Ptr&, const QPatternist::SourceLocationReflection*) const' cannot be overloaded
15:12:27 <jreznik> #info qt fails to build on rawhide
15:12:34 <rdieter> type/qbuiltinatomictypes_p.h:370:46: error: with 'virtual QPatternist::AtomicTypeVisitorResult::Ptr QPatternist::IntegerType::accept(const Ptr&, const QPatternist::SourceLocationReflection*) const'
15:12:53 <rdieter> type/qbuiltinatomictypes_p.h:712:46: error: 'virtual QPatternist::AtomicTypeVisitorResult::Ptr QPatternist::DerivedStringType<DerivedType>::accept(const Ptr&, const QPatternist::SourceLocationReflection*) const' cannot be overloaded
15:13:00 <rdieter> type/qbuiltinatomictypes_p.h:692:46: error: with 'virtual QPatternist::AtomicTypeVisitorResult::Ptr QPatternist::StringType::accept(const Ptr&, const QPatternist::SourceLocationReflection*) const'
15:13:20 <ltinkl> looks like some template and virtual inheritance prob
15:13:26 <Kevin_Kofler> Huh, why can't those be overloaded?
15:13:36 <Kevin_Kofler> The signature is exactly the same…
15:13:45 <rdieter> fwiw, the f16 build just finished
15:14:02 <ltinkl> Kevin_Kofler: you don't see the super class
15:14:51 <rdieter> so, anyone able/willing to take a look at this soon?  (seems a little out of my depth)
15:15:01 <Kevin_Kofler> I really don't see why g++ doesn't accept this.
15:15:16 <Kevin_Kofler> Ask Jakub, and if he also doesn't know, the C++ experts at upstream GCC.
15:15:33 <ltinkl> I can take a look around
15:16:17 <Kevin_Kofler> Hmmm, wait, maybe I see something…
15:16:25 <Kevin_Kofler> Is const Ptr& really the same type in both cases?
15:16:41 <ltinkl> I'm guessing a template type
15:16:45 <Kevin_Kofler> If Ptr resolves to something different, the signatures won't match.
15:16:52 <Kevin_Kofler> You might need to fully qualify Ptr somehow.
15:17:11 <ltinkl> or that
15:18:59 <Kevin_Kofler> I just looked at the code, Ptr seems to always be specified as AtomicTypeVisitor::Ptr in this context.
15:19:15 * than is present
15:19:18 <rdieter> #action ltinkl to look into qt ftbfs on rawhide
15:19:28 <jreznik> #info than present too
15:19:34 <jreznik> #chair than
15:19:34 <zodbot> Current chairs: Kevin_Kofler jreznik ltinkl rdieter rnovacek than
15:20:14 <Kevin_Kofler> Hmmm, I think the problem is that there's first a using IntegerType::accept;, then the overload.
15:20:22 <Kevin_Kofler> But I suspect just removing the using might also not work.
15:20:34 <than> ltinkl: you can ask jakub, he can help
15:20:42 <Kevin_Kofler> http://qt.gitorious.org/qt/qt/blobs/4.8/src/xmlpatterns/type/qbuiltinatomictypes_p.h#line388
15:20:48 <ltinkl> than: yup
15:20:53 <Kevin_Kofler> (and the second error is the same thing with another pair of classes)
15:24:22 <jreznik> anything else? so we can try that IntegerType::accept or ltinkl will ask Jakub
15:24:37 <ltinkl> yup, I'll take care of it
15:24:44 <jreznik> thanks
15:25:12 <jreznik> #topic followup of pkg rename reviews
15:26:08 <rdieter> still have a few kde-4.8 ones and renames yet to do
15:26:08 <jreznik> #link https://bugzilla.redhat.com/showdependencytree.cgi?id=kde-4.8&hide_resolved=1
15:26:46 <jreznik> qyoto should be CLOSED now
15:27:07 * rdieter just closed pykde4 too
15:28:04 <jreznik> rdieter: for qyoto - I was wondering why some stuff is in -devel just didn't ask :( sorry... same for kimono
15:28:49 <rdieter> jreznik: like?  qyoto-devel just had lib symlinks, headers, pkgconfig files
15:29:03 <rdieter> and a couple of binaries used @ buildtime, iirc
15:29:24 <rdieter> oh,
15:29:28 <rdieter> * Wed Jan 04 2012 Rex Dieter <rdieter@fedoraproject.org> 4.7.97-2
15:29:29 <rdieter> - move lib*-sharp.so to main pkg
15:29:34 <rdieter> jreznik: ^^ is that better? :)
15:29:38 <jreznik> yep :)
15:29:41 <rdieter> k
15:29:58 <jreznik> so I'm going to roll the kimono review
15:30:18 <rdieter> so, those, kde-printer-applet, kde-baseapps, kde-runtime, kde-workspace
15:30:48 <jreznik> I'll take the renames ones
15:31:00 <rdieter> and I think we should be mostly done with 4.8-related stuff
15:31:11 <jreznik> and I hope kdegraphics-mobipocket will stay
15:31:17 <rdieter> and that one
15:31:19 <rdieter> :)
15:31:36 <jreznik> #action jreznik to finish package reviews
15:32:16 <rdieter> can move on then...
15:32:30 <jreznik> #topic oxygen-gtk3 by default for KDE Plasma sessions
15:32:58 <Kevin_Kofler> So we finally have oxygen-gtk3 in Rawhide, as well as a version of kcm-gtk which supports GTK+ 3.
15:33:23 <Kevin_Kofler> So my plan is to change kde-settings in Rawhide so that KDE Plasma sessions will default to oxygen-gtk3.
15:33:45 <Kevin_Kofler> I also want to push an updated kcm-gtk to F15 and F16, but not change the defaults there.
15:33:54 <Kevin_Kofler> Any objections to that plan?
15:35:13 <than> Kevin_Kofler: +1
15:35:19 <jreznik> +1
15:35:35 <ltinkl> +1 too
15:35:38 <rdieter> Kevin_Kofler: +1
15:36:39 <Kevin_Kofler> Great, I'll go ahead then.
15:37:29 <jreznik> #agreed to set oxygen-gtk3 as default for KDE Plasma sessions
15:39:35 <jreznik> #topic open discussion
15:41:10 <Kevin_Kofler> Hmmm, problem, kcm-gtk's GTK+ 3 supports writes to ~/.config/gtk-3.0/settings.ini rather than something KDE-specific.
15:41:40 <Kevin_Kofler> So stuff you set there will also affect other sessions (unlike for GTK+ 2 where they use ~/.gtkrc-2.0-kde4).
15:42:31 <rdieter> Kevin_Kofler: ok, so there's GTK2_RC_FILES env var, need to find out if gtk3 has an equivalent, or get this handled in xsettings-kde somehow
15:43:09 <Kevin_Kofler> xsettings-kde doesn't work because xsettings only have one theme setting for all GTK+ versions.
15:43:29 <Kevin_Kofler> (That's why in GNOME you can only use themes which have both a GTK+ 2 and 3 version.)
15:45:07 <ltinkl> btw, regarding a Qt 4.8 regression
15:45:18 <rdieter> Kevin_Kofler: well, we have one theme for all gtk versions now. :)
15:45:28 <ltinkl> has anyone noticed that non-KDE apps don't display a tray icon?
15:45:42 <rdieter> ltinkl: that's been an ongoing problem for a long time
15:45:50 <ltinkl> all Qt, GTK no matter what apps fail to embed a systray icon for me
15:45:52 <Kevin_Kofler> kcm-gtk also reads/writes the GTK+ 3 theme setting directly from that per-user file with no systemwide fallback (it uses KConfigGroup with an absolute path), so I can't preseed the setting anywhere in kde-settings. :-/
15:46:04 <ltinkl> rdieter: with Qt 4.8 only I assume?
15:46:05 <Kevin_Kofler> I think I need to fix kcm-gtk before I can do anything else.
15:46:20 <rdieter> ltinkl: it happened for me going back to f14/f15 with qt-4.7.x too
15:46:26 <ltinkl> ugh
15:46:38 <ltinkl> used to work fine in Qt 4.7
15:46:47 <ltinkl> maybe a regression in KDE then
15:46:52 <rdieter> recall the bug we had about nm-applet systray icon sometimes not showing?
15:46:53 <ltinkl> I will test it in xfce
15:46:59 <ltinkl> yup
15:47:02 <rdieter> and if you killed/restarted it, then it worked
15:47:09 <ltinkl> no longer works
15:47:15 <rdieter> oh, joy.
15:47:23 <ltinkl> doesn't display at all
15:47:40 <Kevin_Kofler> KSensors, which is a kdelibs3 systray icon, works fine for me…
15:47:44 <rdieter> ok, mind opening a new bug so we can track it then
15:47:49 <ltinkl> also, if you don't like apper (like me :), you won't get any updates notification from gpk
15:48:02 <ltinkl> Kevin_Kofler: old Qt?
15:48:40 <Kevin_Kofler> Works fine on F16 too if I'm not mistaken, I can fire up the notebook to double-check.
15:48:41 * ltinkl tries with the pure Qt examples
15:48:48 <ltinkl> Kevin_Kofler: pretty pls :)
15:49:00 <ltinkl> might be a bug in KDE as well
15:49:55 <ltinkl> /usr/lib64/qt4/examples/desktop/systray no worky
15:50:12 <ltinkl> will try under Gnome/xfce
15:51:03 <rdieter> ltinkl: heh, if the qt systray example doesn't work, then definitely sounds like our/kde problem
15:51:28 <ltinkl> not certain
15:51:42 <rdieter> though I do know of several qt-only apps' systray icons being ok too, including clementine
15:51:46 <rdieter> for me
15:52:18 <rdieter> woo, initial calligra build finally done in kde-mock repo
15:52:28 <Kevin_Kofler> ltinkl: ksensors displays fine with:
15:52:30 <Kevin_Kofler> qt-4.8.0-5.fc16.x86_64
15:52:31 <Kevin_Kofler> kdelibs-4.7.4-1.fc16.x86_64
15:52:32 <Kevin_Kofler> kdebase-workspace-4.7.4-6.fc16.x86_64
15:52:34 <Kevin_Kofler> ksensors-0.7.3-19.fc15.x86_64
15:52:35 <Kevin_Kofler> kdelibs3-3.5.10-31.fc16.x86_64
15:52:45 <Kevin_Kofler> (That's a kdelibs3 app, definitely not using the new systray spec.)
15:52:49 <rdieter> ok, so kde3 app systray ok
15:52:56 <ltinkl> I have qt 4.8 :)
15:53:07 <ltinkl> that's why I said a "qt 48 regression"
15:53:13 <Kevin_Kofler> ltinkl: This is also Qt 4.8, but KDE SC 4.7.4.
15:53:24 <ltinkl> oops, misread
15:53:29 <Kevin_Kofler> Are you using KDE SC 4.8-pre?
15:53:33 <rdieter> ltinkl: my qt-examples pkg doesn't include anything under /usr/lib64/qt4/examples/desktop
15:53:56 <ltinkl> rdieter: in /usr/lib? dunno your arch
15:53:59 <rdieter> nvm, I'm blind or copy-n-paste fail
15:54:29 <rdieter> ltinkl: it works for me here, on my box with kde-4.7.97
15:54:56 <ltinkl> I have (almost) the same config as Kevin above
15:55:06 <ltinkl> ie qt48 + kde 4.7.4
15:55:27 <rdieter> so, could be some kde-4.7.x specific issue
15:55:29 <ltinkl> no gtk or qt app show any systray icons
15:55:38 <ltinkl> only pure KDE apps work
15:55:58 <rnovacek> yeah, works for me with qt48 and kde4.7.97
15:56:26 <rdieter> looks like I'll need to downgrade again for some more testing.
15:56:31 <than> ltinkl: i can reproduce this issue with qt48+kde4.7.x on my working machine
15:56:37 <ltinkl> might be a messup on my system... I'll investigate more
15:56:44 <ltinkl> than: oh rly?
15:56:59 <Kevin_Kofler> http://developer.gnome.org/gtk3/3.1/GtkSettings.html#GtkSettings.description – Looks like the only way to use a different settings.ini in KDE Plasma sessions is to change XDG_CONFIG_HOME, WTF…
15:57:13 <rdieter> Kevin_Kofler: :( crap.
15:59:04 <jreznik> #info non-kde systray icons does not work for ltinkl and than
15:59:38 <jreznik> #info Kevin_Kofler investigating possibility of setting different path for oxygen-gtk3 settings
15:59:44 <jreznik> anything else todya?
15:59:58 <Kevin_Kofler> What I guess I could do is to put a script into /etc/kde/env which creates the settings.ini if it's not there yet and writes the config entry.
16:00:04 <than> ltinkl: yes, i will try more testing later
16:00:09 <Kevin_Kofler> But that'll then also affect other desktops.
16:00:26 <Kevin_Kofler> I don't think I can do any better without changing GTK+.
16:00:34 <Kevin_Kofler> http://git.gnome.org/browse/gtk+/tree/gtk/gtksettings.c#n313
16:00:42 <rdieter> Kevin_Kofler: back to xsettings-kde again? :)
16:00:45 <Kevin_Kofler> The path is hardcoded and there's no environment variable or the like.
16:00:59 <Kevin_Kofler> xsettings-kde doesn't allow setting different themes for GTK+ 2 and 3.
16:01:05 <Kevin_Kofler> IMHO it's no viable solution.
16:01:17 <rdieter> I know, but it's better that anything else right now
16:01:37 <rdieter> but makes the kcm-gtk thing largely useless
16:01:43 <rdieter> so, yeah, suckage
16:01:51 <jreznik> :(
16:02:04 <Kevin_Kofler> I think GTK+ really needs to change.
16:02:10 <rdieter> it will get us our objective of oxygen-gtk by default
16:02:21 <Kevin_Kofler> But it'll be tough to get them to agree.
16:03:06 <Kevin_Kofler> For our objective, I think we can put some sobpackage of kde-settings on the spin which installs a systemwide /etc/gtk-3.0/settings.ini and Conflicts: adwaita-gtk3-theme.
16:03:15 <Kevin_Kofler> *subpackage
16:03:26 <Kevin_Kofler> Of course that solution will suck for everyone else.
16:03:36 <Kevin_Kofler> But it'd fix the KDE spin.
16:03:56 * jreznik is not happy with breaking other desktops even on kde spin...
16:04:29 <ltinkl> yet Gnomies are happy with that
16:04:54 <Kevin_Kofler> GTK+ 3 really need something equivalent to GTK2_RC_FILES. I don't know why they removed that.
16:05:07 <Kevin_Kofler> We need to ask for a GTK3_SETTINGS_FILES or something like that.
16:05:15 <rdieter> ltinkl: probably more a matter of not being aware of the impacts of the changes introduced
16:05:16 <Kevin_Kofler> s/need/needs/
16:05:34 <jsmith> rdieter: Yeah, that's probably closer to the truth
16:06:54 <nucleo> is GNOME uses settings.ini?
16:07:18 <rdieter> nucleo: good question, I bet not (using gnome-settings-daemon instead)
16:07:48 <rdieter> would hit other desktops without a settings daemon though
16:07:48 <nucleo> and other desktops have own settings for gtk3 themes?
16:08:05 <jreznik> we're out of time -> #fedora-kde
16:08:13 <rdieter> agreed
16:08:17 <jreznik> thanks all :)
16:08:20 <jreznik> #endmeeting