15:10:58 <Kevin_Kofler> #startmeeting KDE SIG Meeting
15:10:58 <zodbot> Meeting started Tue Feb  3 15:10:58 2015 UTC.  The chair is Kevin_Kofler. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:10:58 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:11:02 <Kevin_Kofler> #meetingname kde-sig
15:11:02 <zodbot> The meeting name has been set to 'kde-sig'
15:11:09 <Kevin_Kofler> #topic Roll call
15:11:13 * Kevin_Kofler is present, who else?
15:11:30 * jreznik is here
15:11:37 * jgrulich is present
15:12:22 <than> present
15:12:46 * danofsatx is here
15:12:54 <danofsatx> for once, on time even
15:13:16 <dvratil> hi
15:14:09 <Kevin_Kofler> heliocastro: Ping?
15:14:11 <Kevin_Kofler> pino|work: Ping?
15:14:19 <pino|work> hi
15:14:20 <heliocastro> ping
15:14:22 <heliocastro> poing
15:15:21 <Kevin_Kofler> #chair jreznik jgrulich than danofsatx dvratil pino|work heliocastro ltinkl rdieter
15:15:21 <zodbot> Current chairs: Kevin_Kofler danofsatx dvratil heliocastro jgrulich jreznik ltinkl pino|work rdieter than
15:16:03 <Kevin_Kofler> #info Kevin_Kofler, jreznik, jgrulich, than, danofsatx, dvratil, pino|work, heliocastro, ltinkl present. rdieter notified us he'll be late or absent.
15:16:10 <Kevin_Kofler> #topic Agenda
15:16:11 * jreznik does not like pings as the notification causes significant load of Plasma 5
15:16:23 <jreznik> (or mentions on IRC :)
15:16:35 <pino|work> fix plasma ;)
15:17:21 <danofsatx> I don't even get the notifications from Konversation in Plasma 5.
15:17:22 <dvratil> that could be a good DDOS...just need to write an IRC bot that will ping you every couple seconds ;)
15:17:25 <heliocastro> jreznik: The freeze popup issue ?
15:17:30 <Kevin_Kofler> jreznik: So jreznik I (hey jreznik) think (jreznik?) that we need (still listening jreznik?) to mention jreznik everywhere to get jreznik to fix Plasma 5 for us, right jreznik? :-p
15:18:02 <danofsatx> cruel, Kevin_Kofler, cruel - but I like it >:)
15:18:53 <jreznik> Kevin_Kofler: it's actually ddos on my laptop :D
15:19:05 <heliocastro> One thing for sure we can say that is not fedora kde issue, but fedora issue
15:19:27 <jreznik> danofsatx: I get them and I know even with locked screen I got pinged because of fan noise :)
15:19:27 <heliocastro> Since i have the same issues, but my kde is self compiled twice a week
15:19:58 <heliocastro> jreznik: I got this when using opengl 3 and 2 in render backend / Intel card
15:20:36 <heliocastro> recent updates on f21 make system work back with opengl 2
15:20:54 <heliocastro> Don't know if was mesa or intel drivers
15:21:06 <jreznik> could be
15:21:39 <Kevin_Kofler> So agenda-wise, I think F22 Plasma 5 status is probably the main topic, and we've already started on it somehow.
15:22:08 <jgrulich> item to agenda, KDE SIG dinner on Saturday, I booked a restaurant for 10 people :)
15:22:34 <heliocastro> Restaurant delivers remotely too ? :-)
15:23:15 <Kevin_Kofler> jgrulich: Nice.
15:23:34 <Kevin_Kofler> I'll be there.
15:23:58 <jgrulich> heliocastro: not this one, but you would need a place where to go anyway if you want to deliver food somewhere
15:24:36 <dvratil> trans-atlantic food delivery...sounds like a good idea for a startup ;)
15:24:44 <jgrulich> http://en.restauracevelorex.cz/
15:24:53 <Kevin_Kofler> Delivery by rocket? :-)
15:25:20 <Kevin_Kofler> But I'd suggest we move on to more serious matters.
15:25:26 <heliocastro> dvratil: "We deliver our pizza hot like out of the oven!
15:25:38 <Kevin_Kofler> We're already 25 minutes into the meeting.
15:25:50 <Kevin_Kofler> #topic Fedora 22 Plasma 5 status
15:25:52 <jgrulich> looks that the english version is not updated, they have Spanish specialities until this Sunday, but it's not mentioned there
15:26:21 <dvratil> F22 Plasma 5 status: all imported into rawhide and built
15:26:36 <Kevin_Kofler> Hooray! Thanks!
15:26:37 <dvratil> there were some deps issues during the launch, but should be OK now
15:26:54 <heliocastro> There this one:
15:26:55 <heliocastro> https://bugs.kde.org/show_bug.cgi?id=341951
15:27:18 <Kevin_Kofler> Now we need to identify all the bugs.
15:27:22 <dvratil> there were some complaints about a few specific things, so we should probably focus on those primarily, but overall feedback seems rather positive
15:28:37 <dvratil> the biggest issue seems to actually be a Qt bug: QTBUG-42985 - crash when no screens are available
15:29:17 <dvratil> the "no screen" situation can easilly happen when plugging in an external monitor. As a result, all Qt5 apps crash and you get thrown back to SDDM
15:29:19 <jreznik> dvratil: yep, I hit it several times per day
15:29:48 <jreznik> (but I just get Plasma crash and it gets respawn)
15:29:55 <dvratil> jreznik:  that's different
15:30:00 <heliocastro> We had some bugs open on Qt4 related to this as well, so is ancient bug migtrated to new Qt
15:30:30 <jreznik> aha, so I've never experienced this one and I plug/unplug external displays a few times per day
15:30:52 <dvratil> probably. Looks like Qt simply does not expect the situation when some calls to get screen information can return null pointer. Proper fix is difficult though
15:31:31 <dvratil> the plasmashell crash that jreznik is hitting is mostly KScreen related I think, and should be much better with my fixed in KScreen (which I did not built in Copr yet)
15:31:57 <ltinkl> I'm using it from git and get no crashes at all now
15:32:15 <ltinkl> when plugging/unplugging the monitors or the laptop from the dock
15:32:18 <jreznik> strange I did not experience the all qt5 apps crash
15:32:25 <dvratil> aaand everything is awesome
15:33:52 <jreznik> maybe disable dr konqui for a while and get some statistics from abrt/faf about most common crashes in plasma...
15:34:20 <dvratil> hmm, that's a good idea
15:35:05 <Kevin_Kofler> Ewww…
15:35:16 <Kevin_Kofler> As if we weren't already getting enough bugspam!
15:35:28 <Kevin_Kofler> My mailbox is already swamped with bugzilla spam.
15:35:54 <jreznik> Kevin_Kofler: bug spam is one thing but stats of most common bugs is valuable resource... you can fix a few bugs that are causing most issues
15:36:01 <dvratil> well, use mail filters ;-)  but we could indeed get some valuable info from retrace
15:36:22 <Kevin_Kofler> And I think those are crashes in upstream code that upstream needs to fix, the reports should go upstream.
15:36:28 <jreznik> there were talks between abrt and kde bug guys as they want something similar but seems like it stalled (I got them contacted at Akademy)
15:36:34 <Kevin_Kofler> There's only so much we can do to fix upstream breakage.
15:36:49 <jreznik> Kevin_Kofler: if it's common crash, it will be already in upstream bz but we need stats
15:37:13 <Kevin_Kofler> So -1 to disabling DrKonqi from me.
15:37:30 <Kevin_Kofler> I don't want this stuff flooding our downstream Bugzilla.
15:37:41 <Kevin_Kofler> And I don't like ABRT to begin with.
15:38:02 <Kevin_Kofler> But even if ABRT were great, it'd still be reporting to the wrong bug tracker.
15:38:05 <jreznik> Kevin_Kofler: it's just for rawhide, till beta freeze maybe? to see what are common issues our users hit and we can push upstream to fix it
15:38:22 <jreznik> Kevin_Kofler: then let's push on upstream to use faf :)
15:39:09 <dvratil> does even reporting through DrKonqi work in Plasma 5? There were some problems because of the XMLRPC change in last bugs.kde.org update
15:39:19 <jreznik> :)
15:39:29 <Kevin_Kofler> They have supposedly fixed DrKonqi for both Plasma 4 and 5.
15:39:36 <dvratil> but yeah, we would turn drkonqi back before F22 alpha or whatever
15:39:55 <Kevin_Kofler> There were threads on kde-core-devel and review requests.
15:40:05 <Kevin_Kofler> It should be working now.
15:40:07 <dvratil> and the second thing is that me, jgrulich and ltinkl can actually go to upstream and fix stuff, since we are...well, part of upstream :)
15:40:24 <dvratil> but we can't really go through upstream bugzilla and look for random issues
15:40:35 <jreznik> dvratil: that's my point
15:40:53 <heliocastro> dvratil: I can too
15:41:04 <Kevin_Kofler> Technically, I'm also a KDE developer and IIRC rdieter is, too, but in practice you're the ones doing the work.
15:41:54 <Kevin_Kofler> The thing is, do we really have the resources to track down and fix crashes in all KDE apps?
15:42:13 <dvratil> nah, not all, but the most critical one
15:42:22 <Kevin_Kofler> None of us is familiar with ALL KDE code. Is any of you actively involved in Plasma 5 upstream development?
15:42:50 <Kevin_Kofler> dvratil: The thing is, then we fix the most critical crashes, and the remaining ones rot in our Bugzilla because upstream will never see them.
15:42:54 <Kevin_Kofler> They just spam our mailboxes.
15:43:02 <Kevin_Kofler> And nobody will fix them.
15:43:29 <jreznik> Kevin_Kofler: but if we fix the top bugs users hits, we will get much better experience for users
15:43:30 <Kevin_Kofler> A downstream crash handler is a horribly bad idea.
15:43:36 <dvratil> then we move the upstream and close them downstream ... remember that what is proposed is only for limited period of time, like month or two, not forewer
15:43:51 <dvratil> also with a rather limited userbase of rawhide adventurers
15:43:55 <jreznik> and for the rest of bugs, other distros may hit the same issue - so it will appear in upstream bz
15:44:00 <Kevin_Kofler> Tons of unfixed crashes because we do not have the resources to fix them all and upstream doesn't see them are NOT a nice user experience.
15:44:35 <dvratil> better than plasma crashing after login ;)
15:44:56 <ltinkl> or not starting leaving a black screen... cough cough
15:45:00 <Kevin_Kofler> The frequency of a crash report also does not necessarily correlate with its impact.
15:45:18 <Kevin_Kofler> You can have Plasma crashing after login for one user, will you be spending your time on fixing that?
15:45:22 <jreznik> Kevin_Kofler: you still need some wrangling but it gives you at least some overview
15:46:20 <Kevin_Kofler> Or will you rather fix a KCalc crash with 10000 reports in FAF, even if just to stop the flood of duplicate bug reports and pointless "me too" comments (that ABRT encourages, unfortunately).
15:47:24 <Kevin_Kofler> ltinkl: For the black screen thing, chances are that ABRT will NOT catch that.
15:47:38 <Kevin_Kofler> If you have a hardware-level lockup, there's nothing any crash handler can do.
15:48:05 <Kevin_Kofler> Or if the code is running fine, but not displaying anything.
15:48:16 <ltinkl> that wasn't a HW level bug but a kded lockup
15:48:30 <jreznik> Kevin_Kofler: I'm not saying it's answer for everything...
15:48:53 <Kevin_Kofler> Even then, infinite loops only get caught by ABRT if you manually send SIGABRT or SIGSEGV or something like that to the process.
15:48:54 * ltinkl hums 42
15:48:55 <jreznik> but now, we don't have a clue about important bugs our users are hitting...
15:49:59 <Kevin_Kofler> Search on upstream Bugzilla for Plasma 5 issues with "Installed from: Fedora RPMs"?
15:51:00 <heliocastro> Kevin_Kofler: https://bugs.kde.org/show_bug.cgi?id=341951
15:51:06 <heliocastro> Look for latest comment
15:52:00 <dvratil> https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&chfield=%5BBug%20creation%5D&chfieldfrom=2015-01-01&chfieldto=Now&f1=rep_platform&list_id=1202301&o1=equals&query_format=advanced&v1=Fedora%20RPMs
15:52:23 <dvratil> All bug reports for "Fedora RPMs" since January 1st (long before we merged Plasma 5 to rawhide)
15:52:45 <dvratil> filter out unrelevant stuff and there are like 5 Plasma 5-related crashes
15:53:13 <dvratil> it would be awesome if we were that good, but I think the numbers are like this for different reasons :(
15:53:15 <Kevin_Kofler> heliocastro: I know about that one.
15:53:17 <Kevin_Kofler> I'm on CC on it.
15:53:22 <heliocastro> Ohh, ok
15:53:25 <rdieter> here finally (reading backscroll)
15:53:34 <Kevin_Kofler> Do you think having that in our downstream Bugzilla would get it fixed any faster?
15:53:43 <Kevin_Kofler> I don't, but if you do, feel free to file it.
15:54:00 <Kevin_Kofler> I'm not even sure where to start debugging it.
15:54:12 <heliocastro> Kevin_Kofler: I'm running sessions with loger and debug
15:54:26 <Kevin_Kofler> jreznik was complaining about that issue at the beginning of the meeting.
15:55:32 <rdieter> I agree with disabling drkonqi temporarily, fwiw
15:55:42 <Kevin_Kofler> dvratil: I think there's already more than enough things to fix there. :-) As for the (relative) lack of DrKonqi reports, that's because that was exactly the period where it was broken.
15:55:47 <jreznik> Kevin_Kofler: this is different one
15:56:32 <Kevin_Kofler> We can easily test that DrKonqi is working, just "crash" a random KDE app with kill -SIGABRT and then try reporting that crash.
15:57:07 <Kevin_Kofler> (Of course I wouldn't do that too often, for fear of p*ssing off upstream developers.)
15:57:26 <rdieter> Kevin_Kofler: crash kompare (ie your own app) :)
15:57:38 <Kevin_Kofler> Yeah, we can do that.
15:58:01 <Kevin_Kofler> (Still, the reports go to the mailing list, so it still goes to more people than just me. :-( )
15:58:23 <Kevin_Kofler> Also, it's a kdelibs4 app, unless you want to build master just to test the KF5 DrKonqi.
15:58:39 <Kevin_Kofler> Or are we packaging things to use the new DrKonqi everywhere?
15:59:01 <rdieter> good question, I think kde4/kf5 are separate still
15:59:01 <Kevin_Kofler> I know the kdelibs4 DrKonqi works with the kdelibs3 KCrash (i.e., for KDE 3 apps), we have it set up that way.
15:59:17 <Kevin_Kofler> But is it really officially supported? AFAIK, hell no.
15:59:38 <rdieter> anyway, what would it take to disable kf5 drkonqi (temporarily)?
16:00:25 <Kevin_Kofler> Presumably, whatever RHEL is doing to disable the kdelibs4 one, there are conditionals in kdelibs4 packaging.
16:00:38 <Kevin_Kofler> But I still think it's a very very bad idea.
16:01:06 <Kevin_Kofler> Especially at this stage of Plasma 5 development, it's crucial that upstream gets all the feedback they can get, so they can fix things.
16:01:41 <rdieter> then let's coordinate a small testing window
16:01:53 <rdieter> say 1 or 2 weeks
16:02:00 <Kevin_Kofler> We're, as usual, one of the first distros to ship Plasma 5 at all.
16:02:23 <Kevin_Kofler> I don't want the crash reports rotting in our downstream Bugzilla.
16:02:52 <rdieter> we hadn't discussed what "temporarily" means exactly yet
16:02:57 <rdieter> (have we?)
16:03:00 <jreznik> btw. test day is not a bad idea
16:03:24 <jreznik> rdieter: beta freeze as latest (and test day when disabled)
16:03:43 <rdieter> agreed
16:04:05 <jreznik> Kevin_Kofler: dvratil and ltinkl volunteeered to make sure these bugs are wrangled and reacted in appropriate place
16:04:43 <rdieter> ok, let's flip the switch soon, maybe @devconf then
16:04:58 <ltinkl> yup
16:05:16 * Kevin_Kofler is still opposed to the idea.
16:06:03 <rdieter> duly noted
16:06:13 <rdieter> anyone else opposed?
16:07:06 <danofsatx> not I
16:07:50 <Kevin_Kofler> :-(
16:08:29 <rdieter> ok, that's as close to consensus as we'll get then
16:08:31 <rdieter> anything else?
16:08:54 <Kevin_Kofler> Don't you see that this will only give us work, spam our mailboxes (yet another HOURS of my time that will go wasted on waiting for KMail 2 / Akonadi to process the hundreds of useless mails!) and keep the reports away from upstream developers?
16:09:49 <rdieter> everyone's agreed with the implications (except you)
16:10:06 <Kevin_Kofler> I think you aren't seeing them.
16:10:17 <Kevin_Kofler> Think this through.
16:10:39 <rdieter> I see them at least, think it's mitigated by keeping the testing window small (as mentioned 1-2 weeks worth)
16:11:18 <Kevin_Kofler> DrKonqi is the one right way to handle crashes.
16:11:45 <rdieter> just occurred to me, is pam_keyring still not enabled in sddm?
16:12:11 <rdieter> (means, abrt will trigger manual open of gnome keyring I think)
16:12:29 <Kevin_Kofler> Ah, indeed.
16:12:36 <Kevin_Kofler> Yet another reason why ABRT is not an option for us.
16:12:41 <rdieter> mine has it enabled, not sure if that's default though
16:12:59 <Kevin_Kofler> It's not, because it causes other problems.
16:13:16 <rdieter> .bug 1150283
16:13:17 <rdieter> that one
16:13:18 <zodbot> rdieter: Bug 1150283 KDE logout never completes - https://bugzilla.redhat.com/1150283
16:13:40 <Kevin_Kofler> Exactly why we shouldn't rely on GNOME crap, ever.
16:13:42 <rdieter> apparently (I don't experience that myself though)
16:13:57 <Kevin_Kofler> And the GTK+ theming issues also affect ABRT.
16:14:15 <rdieter> I think it's still worth the testing window, probably ought to document the extra work needed though
16:14:18 <Kevin_Kofler> (GTK+ discontinuing support for C themes such as Oxygen.)
16:14:31 <rdieter> Kevin_Kofler: that's gtk4, mind you
16:15:00 <rdieter> gtk3 theming isn't going anywhere
16:15:07 <Kevin_Kofler> No. :-(
16:15:12 <Kevin_Kofler> No, it's the next 3.x release!
16:15:17 <rdieter> that's news to me
16:15:29 <rdieter> but lets discuss that separately
16:15:33 <Kevin_Kofler> In fact, C theming is already disabled in Rawhide (though it may be reenabled for the stable release, ONE stable release, and dropped again in the next).
16:15:53 <Kevin_Kofler> GTK+ doesn't care about us.
16:15:57 <jreznik> a) it's in rawhide + maybe test day image, b) limited time, c) with commitment from dvratil and ltinkl to wrangle the bugs... so let's move one
16:16:09 <rdieter> jreznik: +1
16:16:10 <Kevin_Kofler> Which is why we need to get rid of all GTK+ stuff from our spin ASAP, not increase our reliance on it.
16:16:20 <jreznik> Kevin_Kofler: well, GTK doesn't care even about GTK users :)
16:16:24 <dvratil> jreznik:  +1, this is worth the temporary pain :)
16:16:52 <Kevin_Kofler> Then put me (and kde-sig) off watchbugzilla for all the packages that are going to not use DrKonqi due to that. :-/
16:17:16 <Kevin_Kofler> It's really not practical to get even more Bugzilla spam.
16:17:46 <rdieter> feel free to disable or filter kde-sig mail delivery
16:18:03 <dvratil> Kevin_Kofler:  I can write you a local mailfilter rule to just drop these emails ;-)
16:19:35 <Kevin_Kofler> So to sum up: user experience will suck (manual gnome-keyring login), downstream developer experience will suck (lots of Bugzilla mails), upstream developer experience will suck (no access to crash reports).
16:19:48 <Kevin_Kofler> This is going to help nobody.
16:20:40 <rdieter> anything else Plasma5 related to discuss?
16:21:14 <rdieter> if folks don't mind, I'd like to spend some time on the gtk theming issue...
16:22:02 <Kevin_Kofler> So the consensus is not changing, you still all agree on disabling DrKonqi for a while? :-(
16:22:16 <Kevin_Kofler> Let's file it as #agreed then and move on, grrr…
16:22:21 * Kevin_Kofler NOT looking forward to the spam!
16:23:24 <Kevin_Kofler> dvratil: If you really want to help, optimize KMail 2 / Akonadi… It takes 30-60 minutes between being started to being ready for use, 5+ seconds to mark a mail as read, etc.
16:23:38 <dvratil> wish I could, wish I could....
16:23:50 <Kevin_Kofler> So you admit that Akonadi is unfixable?
16:24:04 <Kevin_Kofler> KMail 1 was 100 to 1000 times faster, no exaggeration.
16:24:08 <rdieter> #agreed to temporarily disable drkonqi.  plan a) when it's in rawhide + maybe test day image, b) limited time, c) with commitment from dvratil and ltinkl to wrangle the bugs
16:24:37 <dvratil> Kevin_Kofler: it probably reached the limits of it's current design. We are working on it though, some neat stuff coming in next months
16:24:38 <Kevin_Kofler> #info majority consensus, 1 dissenter (Kevin_Kofler)
16:25:32 <Kevin_Kofler> dvratil: It's only been what, 4 years?, that I've been telling you that Akonadi's design is flawed.
16:25:37 <rdieter> #topic gtk3 (and future) theming/integration
16:26:01 <rdieter> afk, brb
16:26:22 <Kevin_Kofler> So GTK+ does not care about looking good under KDE, never did, never will, and is now actively breaking KDE efforts to do their job for them.
16:27:11 <dvratil> what are they plans for theming? Pure CSS?
16:27:18 <rdieter> dvratil: yes
16:27:27 <Kevin_Kofler> Thus my proposal: Stop caring about GTK+ and drop all GTK+ software from the KDE spin (use Calamares as the installer, ufw-kde as the firewall, drop ABRT and setroubleshoot).
16:27:46 <rdieter> my impression was that the c theming engine is deprecated but still supported in gtk3 (this is what oxygen-gtk3 uses)
16:28:07 <ltinkl> exactly, it's deprecated and free to break without notice
16:28:16 <Kevin_Kofler> They want to drop it in this or the next GTK+ 3.x release.
16:28:24 <rdieter> who says "free to break"?
16:28:38 <rdieter> who says that it will be dropped?
16:28:48 * ltinkl finding the BR
16:29:18 <rdieter> if it's one person's opinion rather than a definitive statement, then I'm not sure it will be helpful
16:29:33 <dvratil> depends on the person ;)
16:30:15 <ltinkl> https://bugs.kde.org/show_bug.cgi?id=343555
16:30:16 <ltinkl> and
16:30:25 <ltinkl> https://bugzilla.gnome.org/show_bug.cgi?id=735211
16:30:30 <ltinkl> nice read :)
16:30:30 <rdieter> I read one person's opinion saying that, then someone else ( mclasen ) clarified it as "depredated, but still supported"
16:30:32 <jreznik> well, you can't expect stability from gtk theming...
16:31:50 <rdieter> https://bugzilla.gnome.org/show_bug.cgi?id=735211#c10
16:32:00 <rdieter> I guess that sounds like porting is needed :(
16:32:14 <Kevin_Kofler> Maybe mclasen is available for a comment?
16:32:17 <mclasen> kinda
16:32:29 <rdieter> I think the bz statements are fairly clear
16:32:58 <rdieter> mclasen: in short, will oxygen-gtk3 (as is now) be usable for f22... or not?
16:33:38 <mclasen> theme engines will not work in f22, as things stand today
16:33:40 <rdieter> I'm guessing the answer is no, but is there more you'd like to add?
16:33:42 <rdieter> ok
16:34:02 <mclasen> I have said that we need to evaluate that decision when we come close to the end of the cycle
16:35:23 <rdieter> mclasen: "end of cycle" as in when exactly?  near f22 beta freeze?
16:35:39 <rdieter> or in regards to gtk development schedule?
16:35:53 <mclasen> near the end of the gtk 3.15 cycle, which amounts ot the same thing, more or less
16:35:54 <Kevin_Kofler> The thing is, Oxygen has a lot of theming code in C, some of it even ported from the Qt theme's C++ code, and even where not, almost all was shared with the GTK+ 2 version.
16:36:16 <Kevin_Kofler> Now you want them to rewrite everything in CSS, which means to throw away all the code, and also likely to drop some features that cannot be implemented in CSS.
16:36:29 <danofsatx> one of my servers just dropped offline. I'll be back shortly.
16:36:36 <Kevin_Kofler> (In fact, oxygen-gtk currently actually also hacks around some limitations of even the C theming API.)
16:37:05 <mclasen> preventing theme engines from 'hacking around' is one of the main motivations here, indeed
16:37:16 <Kevin_Kofler> The oxygen-gtk developer has already stated that he is not willing to do that work and that as a result, he is discontinuing oxygen-gtk3 and dropping the plans for breeze-gtk.
16:38:05 <Kevin_Kofler> So you're preventing them from implementing some features that are essential for a consistent desktop-wide look&feel.
16:38:13 <Kevin_Kofler> (unless that desktop happens to be GNOME, of course)
16:38:16 <rdieter> ok, starting to sound like oxygen-gtk (v3 at least) will not be viable for f22 then
16:38:24 <heliocastro> Is only me or gnome is paving the way to screw all other desktops in the try to become the only one ?
16:38:42 <rdieter> heliocastro: not constructive (feel free to rant later though)
16:38:48 <rdieter> (after meeeting)
16:38:50 <heliocastro> Sorry for that
16:39:05 <mclasen> no worries, I'm at least as thick-skinned as lennart
16:39:22 <Kevin_Kofler> mclasen: Lack of support for C themes also means that things such as gtk-qt-engine (which some developers have been recently trying to revive) are no longer possible, requiring every single theme to get ported to GTK+.
16:39:31 <rdieter> I think that answers the questions I had
16:40:11 <rdieter> We were going to have to evaluate gtk integration topics at devconf anyway, this at least simplifies things a bit (by removing one option)
16:40:39 <Kevin_Kofler> Qt goes out of its way to integrate in GTK+-based desktops, with QGtkStyle, platform plugins, etc. GTK+ is doing the opposite. This sucks.
16:41:03 <rdieter> Kevin_Kofler: ditto what I said to heliocastro
16:41:24 <rdieter> #topic open discussion
16:41:30 <rdieter> anything else to discuss today?
16:41:32 <Kevin_Kofler> rdieter: Well, what we could do is fork GTK+, enable it per ld.so.conf.d override (see freetype-freeworld), readd theme engine support and ship that.
16:42:07 <rdieter> there's lot of things we *could* do, sure.
16:42:14 <Kevin_Kofler> We could put the GTK+ fork on git.kde.org playground.
16:42:29 <mclasen> would be an interesting development, certainly
16:42:44 <Kevin_Kofler> I guess some people would help out with it. Keeping binary compatibility with the moving target of upstream GTK+ would be a PITA though.
16:42:52 <rdieter> *could* and *should* are completely different things, of course
16:42:55 <Kevin_Kofler> We can't really expect all the GTK+ stuff in Fedora to be built against our fork.
16:43:31 <mclasen> I'll talk to mbriza about looking at cssified oxygen
16:44:18 <Kevin_Kofler> That could be a solution, if he can pull it off.
16:44:31 <Kevin_Kofler> I'm pretty sure it wouldn't look&feel as native as the C theme though.
16:44:43 <mclasen> but I'll also state that I don't think it is the end of the world if gtk apps use a different theme under kde (as long as it is polished, and complete)
16:44:46 <Kevin_Kofler> But better than nothing.
16:44:53 <mclasen> thats what we are doing on os x and windows too, now
16:45:04 <Kevin_Kofler> I think inconsistency sucks.
16:45:24 <mclasen> and I admit that that is a change from the approach we've been taken to cross-platform theming
16:45:42 <Kevin_Kofler> Speaking of inconsistency, another annoyance we're having with GTK+ is with client-side decorations.
16:46:12 <Kevin_Kofler> GTK+ doesn't even allow disabling them (without a Debian patch that we don't ship, or an LD_PRELOAD hack → ewww!).
16:46:50 <Kevin_Kofler> That makes GTK+ applications look REALLY out of place under KDE (because the window decorations don't look ANYTHING like the native KWin ones).
16:47:13 <Kevin_Kofler> We really want CSD disabled under KWin.
16:47:29 <mclasen> might be an argument in favor of not worrying too much about the theme - things look and work different anyway
16:47:38 <rdieter> anything else (contructive) to discuss?  else let's close the meeting
16:47:50 <Kevin_Kofler> That's going to be an argument in favor of dropping GTK+ entirely.
16:47:55 <Kevin_Kofler> You're entirely unhelpful and uncooperative.
16:48:03 <Kevin_Kofler> How hard can it be to allow disabling CSD?
16:48:10 <Kevin_Kofler> KWin upstream wants CSD off. We do too.
16:48:11 <rdieter> Kevin_Kofler: you're the pillar of cooperation too? :)
16:48:28 <mclasen> you can't give screen real estate to application designers to use and then say 'but we may turn it off behind your back!'
16:49:16 <Kevin_Kofler> Sure you can, it's clear to everybody that CSD is optional, it even gets turned off under some conditions (no compositing).
16:49:45 * rdieter takes that as a no, thanks everyone
16:49:47 <rdieter> #endmeeting