15:02:41 <jreznik> #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2011-01-25
15:02:41 <zodbot> Meeting started Tue Jan 25 15:02:41 2011 UTC.  The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:41 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:03:33 <jreznik> #topic roll call
15:03:37 <jreznik> who's present?
15:04:28 * rnovacek here
15:05:20 <Kevin_Kofler> Present. (Sorry for being late.)
15:05:31 <jreznik> Kevin_Kofler: no, still roll call
15:05:31 * ltinkl is here
15:05:42 <than_> present
15:05:51 <jreznik> #chair Kevin_Kofler than_ ltinkl rnovacek rdieter_work
15:05:51 <zodbot> Current chairs: Kevin_Kofler jreznik ltinkl rdieter_work rnovacek than_
15:06:16 <jreznik> #info rnovacek jreznik Kevin_Kofler ltinkl than_ present
15:06:30 <jreznik> #topic agenda
15:06:41 <rdieter_work> hola
15:07:31 <jreznik> #info rdieter and rdieter_work present too :)
15:07:43 <jreznik> anything else to add to the agenda?
15:07:52 <jreznik> 4.6 status
15:08:11 <than_> yes, 4.6.0 status
15:08:49 <jreznik> else?
15:09:20 <jreznik> ok, let's start
15:09:29 <jreznik> #topic 4.6.0 status
15:09:51 <jreznik> everything should built, ltinkl's now working on kdebase-workspace respin
15:10:03 <ltinkl> done too, building atm
15:10:13 <Kevin_Kofler> One thing about 4.6.0:
15:10:44 <Kevin_Kofler> Should I add versioned Conflicts for kile, kdevplatform/kdevelop and rkward to kdelibs to ensure they'll be upgraded to a compatible version?
15:10:45 <jreznik> one plasma fix and powedevil migration issues in respun tarball
15:10:54 <Kevin_Kofler> (the KatePart Smart* issue)
15:11:37 <jreznik> we should assure the correct kdelibs are used
15:11:43 <Kevin_Kofler> Speaking about KDevelop, there's now 4.2.0 final ready for packagers (release tomorrow), we should get it in.
15:11:50 <Kevin_Kofler> jreznik: It's the opposite here.
15:12:02 <Kevin_Kofler> kdelibs needs a versioned Conflicts to force those apps to be upgraded.
15:12:04 <rdieter_work> I'd say... no.  I'm not comfortable abusing Conflicts for that
15:12:15 <Kevin_Kofler> The existing versions don't have a Requires: kdelibs < 4.6.0.
15:12:17 <jreznik> #info 4.6.0 is built, ltinkl is building rebased kdebase-workspace packages (one plasma fix, powerdevil migration issues)
15:12:25 <jreznik> Kevin_Kofler: ah, ok
15:12:32 <rdieter_work> but I don't feel too strongly, if others disagre
15:14:02 <jreznik> but I'm not sure it should go to kdelibs neither
15:14:03 <rdieter_work> are all of those fallout from the kate changes?
15:14:13 <Kevin_Kofler> rdieter_work: Yes.
15:14:22 <Kevin_Kofler> rkward has been upgraded a while ago (even in F14).
15:14:32 <Kevin_Kofler> Kile and KDevelop are our packages.
15:14:51 <Kevin_Kofler> They all have compatible versions, it's just that upgrading to KDE 4.0 won't necessarily drag them in.
15:14:54 <Kevin_Kofler> *4.6
15:15:53 <rdieter_work> meh... ok.
15:17:42 <rdieter_work> Kevin_Kofler: can you add the Conflicts?
15:17:45 <Kevin_Kofler> Yes.
15:17:51 <Kevin_Kofler> Will do.
15:17:56 <Kevin_Kofler> BTW, is anybody working on KDevelop 4.2.0 yet?
15:18:02 <rdieter_work> I can after meeting
15:18:13 <Kevin_Kofler> OK, please do.
15:18:33 <jreznik> #action Kevin_Kofler to add Conflits to kdelibs because of KatePart Smart* issue (kile, kdevplatform/kdevelop and rkward)
15:18:39 <Kevin_Kofler> BTW, do we want to push this to F14 too? (IMHO yes.) And F13? (IMHO also yes.)
15:18:50 <Kevin_Kofler> Minimum required kdelibs for 4.2.0 is 4.5.2.
15:18:57 <jreznik> #action rdieter_work to work on KDevelop 4.2.0 after meeting
15:19:02 <Kevin_Kofler> So it can be pushed with or without KDE 4.6.
15:19:14 <Kevin_Kofler> (If 4.6 is pushed, KDevelop 4.2 must be, too.)
15:19:14 <rdieter_work> this/it = kdevelop-4.2.x ?
15:19:23 <Kevin_Kofler> Yes.
15:19:49 <rdieter_work> won't that complicate the conflicts then?
15:19:49 <than_> Kevin_Kofler: do we need to ask fesco for that?
15:20:15 <rdieter_work> I mean, iirc, will kdevelop-4.2.0 built against kde-4.5.x still be abi-incompat with kde-4.6 ?
15:20:16 <Kevin_Kofler> If we can reasonably pass it off as a bugfix, no. ;-)
15:20:26 <Kevin_Kofler> (re asking FESCo)
15:20:40 <Kevin_Kofler> rdieter_work: No, it'll be compatible.
15:20:45 <rdieter_work> oh, ok.
15:20:48 <Kevin_Kofler> 4.5 already has the Moving* interfaces.
15:20:59 <Kevin_Kofler> (That's also one of the reasons why 4.5 is required.)
15:21:25 <Kevin_Kofler> Kile built against 4.5 is also fine for 4.6, only if you build it against 4.4, you'll get a build incompatible with 4.6 (using Smart*).
15:21:32 <Kevin_Kofler> KDevelop just dropped Smart* support entirely.
15:21:39 <jreznik> ok, than_'s question leads me to - 4.6.0 and F14
15:21:58 * thomasj waves a late hi
15:22:15 <rdieter_work> Kevin_Kofler: ok, those compatibility changes/fixes makes this a desirable update for f13/f14 to me then.
15:22:49 <rdieter_work> thomasj: hi!
15:23:07 <Kevin_Kofler> FWIW, I already pushed a Kile update to testing, upgrading it from beta 4 to beta 5, which fixes 4.6 compatibility along with another huge bunch of bugs and a handful minor features.
15:23:59 <Kevin_Kofler> (We've had the 4.6 compat fix as a backported patch in Rawhide for a while, but now we have a new official beta.)
15:24:56 <Kevin_Kofler> So what about 4.6.0 and F14?
15:25:00 <Kevin_Kofler> IMHO we want to push this.
15:25:28 <Kevin_Kofler> Should we file a request with FESCo? Or just do it and present them with the done deal? ;-)
15:25:33 <rdieter_work> jreznik: wrt f14/kde-4.6.x, I'd say we probably wait for 4.6.1 at least, and make an earnest effort to find regressions
15:25:46 <Kevin_Kofler> Finding regressions is what updates-testing is for.
15:25:48 * rdieter_work looks up kde-4.6 tracker bug
15:25:53 <than_> yes, i prefer 4.6.1 for f14
15:26:00 <jreznik> but we need an exception, we can "hide" one package as bugfix update but not 4.6.0...
15:26:07 <Kevin_Kofler> Why wait a month for no good reason?
15:26:17 <jreznik> rdieter_work, than_: +1
15:26:20 <rdieter_work> looks like things are clear... for now, https://bugzilla.redhat.com/showdependencytree.cgi?id=657002&hide_resolved=1
15:26:24 <Kevin_Kofler> All it'll do is make our case for "no, our users can't wait for F15" weaker!
15:26:28 <jreznik> it would be one argument for fesco to approve it
15:26:31 <than_> as we know the first kde major release ist not the stable enough
15:26:37 <Kevin_Kofler> 4.5 for F13 came after F14 was out.
15:26:45 <jreznik> there are not a big changes in interface
15:26:50 <Kevin_Kofler> That kinda defeats our point of wanting to provide the new KDE before the new Fedora.
15:27:10 <Kevin_Kofler> And why wait if we have no known regressions?
15:27:11 <rdieter_work> never considered that our point
15:27:23 <Kevin_Kofler> It's one of the arguments we brought to FESCo.
15:27:32 <Kevin_Kofler> (At least SMParrish, our contact in FESCo, did.)
15:28:03 <rdieter_work> it may have been a nice-to-have side-benefit, but not much more than that
15:28:28 <Kevin_Kofler> Their argument is, if there's a new Fedora users can upgrade to, they don't need the new KDE as an update.
15:28:45 <Kevin_Kofler> And they'll have a good point there if we wait until the new Fedora to push the new KDE.
15:28:58 <Kevin_Kofler> I also really don't see why we would wait.
15:28:59 <rdieter_work> http://fedoraproject.org/wiki/SIGs/KDE/Update_policy
15:29:00 <SMParrish> It was my understanding that KDE has a blanket I major upgrade per release exception
15:29:06 <Kevin_Kofler> Our tracker is clear.
15:29:06 <rdieter_work> that's not mentioned on ^^
15:29:23 <Kevin_Kofler> SMParrish: The exception is case by case, not blanket, AFAICT. :-(
15:29:45 <rdieter_work> we presented as a blanket, not sure if fesco took it to mean that or not.
15:29:56 <SMParrish> rdieter_work: yes we did
15:30:14 <rdieter_work> :)
15:30:17 <Kevin_Kofler> SMParrish: I think you need to clear that up, because that's not the understanding I get reading the writeup rdieter_work linked to.
15:30:30 <Kevin_Kofler> I suspect there may be some misunderstanding somewhere.
15:30:42 <Kevin_Kofler> (OTOH, if we just push it, we can always claim we understood it that way. ;-) )
15:30:44 <SMParrish> Kevin_Kofler: 1 exception per release, anything more must go to fesco
15:31:03 <jreznik> SMParrish: is it written somewhere?
15:31:31 <SMParrish> jreznik: I'll have to go back thru the minutes to find the vote
15:31:40 <thomasj> 1 exception == 1 major 4.x update IIRC
15:31:49 <jreznik> SMParrish: ok, thanks
15:31:51 <SMParrish> thomasj: correct
15:32:02 <Kevin_Kofler> https://fedoraproject.org/wiki/Updates_Policy#Examples doesn't confirm what SMParrish said, unfortunately.
15:32:56 <Kevin_Kofler> But maybe it's just the writeup which doesn't make it clear that KDE specifically has been given an exception.
15:33:21 <Kevin_Kofler> But on our end, why would we want to wait if our regression tracker is clear?
15:33:27 <Kevin_Kofler> I'm for pushing 4.6.0.
15:33:41 <rdieter_work> it's clear because there's not much much testing of 4.6.0 yet.
15:33:45 <rdieter_work> it's not even released!
15:33:51 <Kevin_Kofler> That's what updates-testing is for.
15:33:57 <ltinkl> I'd wait for 4.6.1
15:34:22 <rdieter_work> Kevin_Kofler: I think we understand your opinion.  fair enough.
15:34:36 <Kevin_Kofler> FWIW, one issue I can think of for 4.6 on F14 is that it appears to require a newer polkit than in F14, I think we need to somehow hack it to build with the older one.
15:34:43 <rdieter_work> I just don't agree, .0 isn't ready for updates-testing yet
15:34:45 <Kevin_Kofler> (Or has that changed?)
15:35:04 <Kevin_Kofler> rdieter_work: The problem is, I don't understand your opinion. ;-)
15:35:08 <rdieter_work> I think it was just a newer polkit-qt
15:35:19 <than_> rdieter_work: +1
15:35:23 <rdieter_work> I don't recall doing any polkit builds for kde-unstable
15:35:27 <jreznik> Kevin_Kofler: I'll check it but rdieter_work is right
15:35:39 <Kevin_Kofler> OK, then it's not a real problem.
15:35:40 <jreznik> we did some changes in polkit-qt and these are in kde
15:35:55 <jreznik> polkit 0.96 should be enough
15:35:56 <rdieter_work> what I'm worried about most is the halectomy in 4.6.x
15:35:58 <Kevin_Kofler> As long as we don't have to touch polkit (which would definitely be vetoed), we should be fine.
15:36:19 <Kevin_Kofler> rdieter_work: 4.6 can be built with HAL support, if we really want that.
15:36:22 <jreznik> rdieter_work: we should ship it with hal enabled
15:36:33 <Kevin_Kofler> (but the Solid code would still be somewhat different)
15:36:57 <rdieter_work> ltinkl: what do you think wrt 4.6 and solid/hal?
15:37:23 <Kevin_Kofler> The reason why I don't understand the opinion that 4.6.0 isn't ready for testing is that no concrete issue with it has been mentioned.
15:37:27 <rdieter_work> jreznik: perhaps, but that's also something that's untested so far (but it's old code, so likely not a big deal)
15:37:34 <ltinkl> Solid+HAL is ok for older distros
15:37:55 <ltinkl> for F15 the default should be udisks+upower+udev backends, HAL disabled
15:38:03 <rdieter_work> certainly.
15:38:15 <Kevin_Kofler> To ship Solid with HAL, we'd drop the HALectomy patches and build without support for the new stuff.
15:38:16 <rdieter_work> So, kde-unstable up to now has been built like f15, hal disabled
15:38:27 <Kevin_Kofler> We may have to set HAL_LEGACY in the environment or disable the checks.
15:38:37 <Kevin_Kofler> Or is that automatic if u* wasn't found at build time?
15:38:41 <ltinkl> Kevin_Kofler: not needed
15:38:58 <ltinkl> Kevin_Kofler: the HAL code is removed
15:39:21 <ltinkl> the problem is that we have to make sure we don't load both HAL and udisks backends
15:39:21 <jreznik> Kevin_Kofler: removed?
15:39:30 <ltinkl> that could cause nasty effects
15:39:38 <ltinkl> either of them is fine
15:39:42 <jreznik> only the selection, isn't it?
15:39:44 <rdieter_work> if we intend to ship f14, 46 with hal support, I'd propose the next round of (un)official builds include hal support again then
15:40:17 <Kevin_Kofler> ltinkl: If we want to support HAL on F14, we'd drop the patches which remove the HAL code and add a new one to remove/disable the u* code instead.
15:40:18 <jreznik> rdieter_work: +1
15:40:37 <Kevin_Kofler> FWIW, I think we should just ship the u* backends.
15:40:47 <Kevin_Kofler> HAL has been deprecated for ages in Fedora.
15:40:51 <ltinkl> yup
15:41:03 <ltinkl> I'm running in on F14, HAL disabled, no problems
15:41:03 <Kevin_Kofler> OTOH, backlight setting is known to regress with non-Intel drivers at this time.
15:41:08 <rdieter_work> ltinkl: yep to me or Kevin_Kofler ?
15:41:21 <Kevin_Kofler> Only HAL has the weird smarts for that. :-(
15:41:23 * rdieter_work assumes Kevin
15:41:26 <ltinkl> to Kevin, HAL should just stay removed
15:41:33 <jreznik> I'm not sure, we found last minute regression with smartphones in 4.6, fixed now but because of hal/u* differences I think there could be more we don't know yet
15:41:52 <Kevin_Kofler> There's still the backlight mess.
15:41:59 <ltinkl> right, that's why I'm for waiting for 4.6.1
15:42:21 <rdieter_work> ltinkl: so, continue to test u* backends in the meantime?
15:42:23 <Kevin_Kofler> ltinkl: I don't think the XRandR backlight stuff will be sorted out by 4.6.1, especially not on F14.
15:42:31 <ltinkl> Kevin_Kofler: the backlight works fine now, either with the xrandr or using the kernel iface
15:42:45 <jreznik> if we wait for 4.6.1 - then it would be sane to just go with u*, if 4.6.0 I say strong no to u* and use HAL
15:42:48 <ltinkl> Kevin_Kofler: it selects the one which is available
15:42:50 <Kevin_Kofler> Oh, you have code to bypass XRandR now?
15:42:54 <ltinkl> yes
15:43:07 <Kevin_Kofler> Doesn't the kernel interface only work as root?
15:43:10 <ltinkl> so backlight works on all gfx cards
15:43:14 <jreznik> Kevin_Kofler: yep, KAuth code :)
15:43:22 <ltinkl> Kevin_Kofler: yup, using the KAuth framework
15:43:32 <Kevin_Kofler> Oh OK, well then I'm all for u* in F14.
15:43:43 <ltinkl> Kevin_Kofler: definitely
15:43:47 <Kevin_Kofler> I was already mostly for it, but now I see really no reason to use the legacy HAL crap.
15:43:53 <ltinkl> I am testing it all the time with HAL disabled on F14
15:43:59 <ltinkl> for the last 2-3 months
15:44:04 <jreznik> Kevin_Kofler: as I said - for 4.6.0 HAL, if we wait for 4.6.1 I'm not against u*
15:44:22 <jreznik> ltinkl: but remember that last bug with smartphones
15:44:22 <Kevin_Kofler> jreznik: Uh, what's wrong with u* in 4.6.0?
15:44:32 <ltinkl> jreznik: fixed now :)
15:44:35 <Kevin_Kofler> If it still has bugs, we can backport the fixes from the branch.
15:44:35 <jreznik> Kevin_Kofler: it's not well tested code
15:44:53 <Kevin_Kofler> (Hmmm, only 15 minutes and we have 2 more agenda items…)
15:44:59 <ltinkl> jreznik: that's why I'm proposing to wait for 4.6.1 before pushing it down to f14
15:45:05 <jreznik> ltinkl: yes, fixed - but you haven't tested it with all kinds of devices... let's wait for bugreports after 4.6.0 release
15:45:16 <jreznik> ltinkl: yep, that's what I'm saying
15:45:21 <Kevin_Kofler> OK, so do we want to vote?
15:45:30 <rdieter_work> ok, we're largely agreed.  let's def wait for 4.6.1 to re-evaluate, and continue testing solid u* backends in the meantime
15:45:31 <ltinkl> probably
15:45:40 <ltinkl> rdieter_work: yup
15:45:42 <Kevin_Kofler> Push to F14: 4.6.0? 4.6.1? Neither?
15:45:45 <Kevin_Kofler> +1 for 4.6.0
15:46:02 <ltinkl> +1 4.6.1, HAL disabled
15:46:05 <rdieter_work> proposal by me: let's def wait for 4.6.1 to re-evaluate f14 plans, and continue testing solid u* backends in the meantime
15:46:16 <ltinkl> rdieter_work: agree with that
15:46:19 <Kevin_Kofler> -1, there are no concrete issues to wait for!
15:46:19 <thomasj> +1 more testing and waiting for 4.6.1
15:46:29 <Kevin_Kofler> What the heck are we waiting for?
15:46:34 <rnovacek> rdieter_work: +1
15:46:35 <rdieter_work> +1
15:46:38 <Kevin_Kofler> How do we explain to our users why they have to wait?
15:46:41 <jreznik> I would do testing in kde-unstabel
15:46:45 <jreznik> kde-unstable
15:46:45 <Kevin_Kofler> There's no reason to wait!
15:46:54 <ltinkl> yup, it can be put meanwhile on our kde-redhat repos
15:46:58 <rdieter_work> we could even switch over these to kde-testing at some point soonish
15:47:02 <jreznik> so we can think about 4.6.0 update too
15:47:13 <Kevin_Kofler> rdieter_work: 4.6.0 is definitely kde-testing material, IMHO.
15:47:16 <than_> Kevin_Kofler: i will say 4.6.0 is not well tested
15:47:22 <jreznik> it's not yet released, let's wait for some early birds testers
15:47:27 <than_> +1 for 4.6.1 in f14
15:47:35 <rdieter_work> ok, perhaps @ or after fudcon I can work on getting it all in kde-testing
15:47:38 <Kevin_Kofler> than_: It's as well tested as all our KDE updates have been prior to pushing to updates-testing.
15:47:44 <Kevin_Kofler> Testing is what updates-TESTING is for!
15:47:55 <jreznik> so I'm +0.5 for 4.6.0 with HAL enabled
15:47:59 <rdieter_work> let's start with kde-testing before even thinking about updates-testing
15:48:05 <than_> rdieter_work: +1
15:48:06 <jreznik> rdieter_work: yep
15:48:13 <Kevin_Kofler> So I'm for 4.6.0 with u*.
15:48:39 <Kevin_Kofler> So u* vs. HAL: I'm for u*.
15:48:44 <jreznik> my proposal - let's start with 4.6.0 in kde-testing with HAL and then re-evalute 4.6.0 for f14
15:49:05 <Kevin_Kofler> Uh, it's a lot of work to change stuff to enable HAL.
15:49:14 <Kevin_Kofler> If we then want to switch back to u*, it'll be wasted effort.
15:49:14 <thomasj> Hmm.. I'm not in favor of going back to HAL
15:49:25 <Kevin_Kofler> And nobody has tested 4.6 with HAL in Fedora.
15:49:29 <rdieter_work> jreznik: let's discuss that more after meeting if you want, let's move on to the other agenda items for now
15:49:31 <ltinkl> jreznik: no, no HAL
15:49:31 <Kevin_Kofler> The u* code is actually much better tested.
15:49:36 <jreznik> ltinkl should have the last word regarding HAL/u*
15:49:43 <jreznik> Kevin_Kofler: no, it isn't
15:49:43 <Kevin_Kofler> jreznik: And he's for u*.
15:49:44 <ltinkl> no HAL, anywhere
15:49:46 <Kevin_Kofler> Case closed.
15:49:49 <than_> it doesn't make sense to switch to hal
15:49:56 <ltinkl> definitely
15:50:02 <ltinkl> it isn't maintained at all
15:50:07 <Kevin_Kofler> Can we move on now?
15:50:10 <jreznik> ok
15:50:22 <jreznik> #topic stick to 700 MiB (CD-sized) live images
15:50:25 <ltinkl> upstream KDE has chosen udisks&co over HAL as the default backend
15:50:38 <Kevin_Kofler> So xz SquashFS brought the nightlies down to 655 MiB, we even have space left!
15:50:54 <rdieter_work> sure, no brainer.  see what we can fit using xz+700mb now
15:50:58 <Kevin_Kofler> => Proposal: we stick to 700 MiB for F14, the plan to go to 1 GiB is struck with no replacement.
15:51:11 <jreznik> Kevin_Kofler: +1
15:51:16 <Kevin_Kofler> +1 from me, obviously.
15:51:16 <rdieter_work> I'm still going to commit my kickstart refactoring to spins-kickstart git though
15:51:45 <Kevin_Kofler> rdieter_work: But please call the CD-sized one with the current name and call the new one LiveDVD-KDE or something.
15:51:51 <rdieter_work> right
15:52:08 <rdieter_work> the old one will stay fedora-kde-livecd, the new one is just fedora-kde-live
15:52:10 <Kevin_Kofler> We also need to look at how much stuff we can enable while still fitting.
15:52:52 <Kevin_Kofler> I'm a bit worried that some rel-eng folks might be confused about what we want spun if we have both sitting there though…
15:52:54 <rdieter_work> once I have that committed to get, then we can all start playing with it more
15:52:57 <jreznik> Kevin_Kofler: we can go through commits and look what we disabled before
15:53:15 <rdieter_work> Kevin_Kofler: I'll make sure no one is confused
15:53:32 <Kevin_Kofler> OK
15:53:57 <Kevin_Kofler> So can I remove "increasing spin beyond cd size." from Features/KDE46?
15:54:07 <jreznik> Kevin_Kofler: yep
15:54:38 <jreznik> do we agreed?
15:55:06 <rdieter_work> I'd rather wait to do some testing of what can be fit before removing anything from the features page
15:55:22 <rdieter_work> though amending it to say we're only considering a size increase is ok
15:55:26 <Kevin_Kofler> Uh, I just committed the feature page edit to the wiki. ;-)
15:55:35 <rdieter_work> ok, no biggie
15:55:55 <Kevin_Kofler> https://fedoraproject.org/wiki/Features/KDE46#Detailed_Description – it's a wiki, you can fix it to say what you think it should say.
15:56:32 <rdieter_work> can just as easily re-add it after testing if needed, let's move on
15:56:36 <jreznik> ok, let's move now, we can talk later at #fedora-kde
15:56:42 <jreznik> #topic reconsider the OnlyShowIn=KDE; for System Settings
15:56:45 <Kevin_Kofler> I think a size increase is not OK unless there are some major sources of bloat showing up in the next couple months. ;-)
15:57:09 <jreznik> Kevin_Kofler: +1 (but there will be soon I think)
15:57:27 <Kevin_Kofler> Uh, which ones? I think gtk3 is already dragged in.
15:57:44 <jreznik> for topic I'm +1, it makes sense - useful use-case
15:57:57 <Kevin_Kofler> So re System Settings, the issue is that it's the only way to set some stuff for KDE apps, e.g. sound events.
15:58:00 <jreznik> Kevin_Kofler: everything is growing...
15:58:08 <Kevin_Kofler> OTOH, the name "System Settings" in a GNOME menu won't be very helpful.
15:58:32 <Kevin_Kofler> It doesn't say anything "KDE", so it's not easily identifiable as KDE's.
15:58:51 <rdieter_work> yeah, I'd lean against this
15:59:15 <thomasj> Well, or make it say "KDE System Settings"
15:59:32 * jreznik is not sure about naming - it can be used for system settings, not kde related only ones
15:59:40 <rdieter_work> Heh, add a dup'd copy that has OnlyShowIn=gnome with the relabel.
15:59:47 <Kevin_Kofler> The problem with changing the name is that it breaks translations.
15:59:56 <rdieter_work> or NotShowIn=kde
16:00:01 <thomasj> rdieter_work,  yeah :)
16:00:06 <Kevin_Kofler> Unless you know how to fix the name for all translated languages. :-)
16:00:22 <Kevin_Kofler> (Sure, I could prepend "KDE" everywhere, but that may be agrammatical.)
16:00:53 <jreznik> we can't do that
16:01:06 <rdieter_work> <shrug>, not sure it's worth the hassle.
16:01:07 <Kevin_Kofler> (I don't want to present our Japanese users with the Japanese equivalent of the "English" sentences they brought us. ;-) )
16:01:17 <Kevin_Kofler> ("All your base are belong to us." etc.)
16:01:31 <rdieter_work> or drop the translations
16:01:41 <rdieter_work> but that's it's own mess
16:01:41 <jreznik> +1 to enable it in Gnome, -1 to rename/drop translations
16:02:03 * Kevin_Kofler has no opinion…
16:02:20 <Kevin_Kofler> I brought it up because it came up on the devel ML, but I don't have a really satisfactory solution.
16:02:41 <Kevin_Kofler> Another issue is that systemsettings is in kdebase-workspace which isn't always installed in the first place.
16:03:26 <jreznik> so status quo?
16:04:14 <rdieter_work> guess so
16:04:14 <than_> i prefer NotShowIn=gnome for KDE systemsetting
16:04:28 <Kevin_Kofler> That'd be the status quo…
16:04:52 <Kevin_Kofler> (Well, actually, it's OnlyShowIn=KDE;, but I think that makes more sense than NotShowIn=GNOME; anyway.)
16:05:05 <Kevin_Kofler> I don't see any reason to special-case GNOME.
16:05:10 <Kevin_Kofler> It's all or nothing.
16:05:11 <rdieter_work> me either
16:05:29 <ltinkl> OnlyShowIn KDE makes more sense
16:05:47 <jreznik> it would be great to have it in other DE's but there are so many issues...
16:06:16 <Kevin_Kofler> We could add an entry with NotShowIn=KDE;, Name=KDE System Settings and no translations.
16:06:32 <rdieter_work> others didn't like that
16:06:32 <Kevin_Kofler> (The app itself would still be translated, of course, only the menu entry not.)
16:07:09 <jreznik> it does not look good - untranslated string when everythin is translated and in Gnome Preferences menu I think everything is translated to all languages
16:08:22 <thomasj> So upstream needs to change that to "KDE System Settings"
16:08:32 <Kevin_Kofler> I doubt they will.
16:08:36 <Kevin_Kofler> They also only show it in KDE.
16:08:36 <jreznik> thomasj: I'm not sure
16:08:40 <thomasj> That way it gets translated as well.
16:08:51 <jreznik> some distros really used it as system settings
16:09:07 <Kevin_Kofler> Yeah, some distros add KCMs for non-KDE stuff.
16:09:16 <Kevin_Kofler> To some extent we do too, see kcm-gtk, kpackagekit etc.
16:09:35 <jreznik> ok, we are 9 minutes over today...
16:09:57 <jreznik> some solution for gnome and co. would be nice
16:10:19 <Kevin_Kofler> Maybe ask upstream what they think of this?
16:10:20 <thomasj> yep
16:10:24 <thomasj> +1
16:10:25 <jreznik> Kevin_Kofler: +1
16:10:34 <Kevin_Kofler> Maybe their consensus is that the missing stuff should be added to apps instead.
16:10:51 <jreznik> especially now, when they want kde apps in other DEs
16:10:56 <Kevin_Kofler> (e.g. app-specific sound events should really be configurable from the app's configuration dialog)
16:11:24 <Kevin_Kofler> jreznik: Oh, they do? Have they stopped disabling Qt's desktop integration in kdelibs? And do they default to QGtkStyle in GNOME yet?
16:11:47 <jreznik> Kevin_Kofler: it's the plan - make KDE Applications DE agnostic
16:11:52 <Kevin_Kofler> That's kinda the minimum to integrate properly into other DEs.
16:12:02 <jreznik> that's why we have KDE Plasma and KDE Applications
16:12:07 <jreznik> that's the marketing plan
16:12:29 <Kevin_Kofler> I'd even say they should default to QGtkStyle in everything except KDE.
16:12:33 <jreznik> to show - hey, these apps works great even outside Plasma desktop
16:12:36 <Kevin_Kofler> Xfce and LXDE are GTK+-based, too.
16:13:28 <jreznik> ok, so we agreed - status quo now and ask upstream
16:13:40 <jreznik> I think it's time to end meeting now...
16:13:51 <Kevin_Kofler> Yes.
16:13:59 <jreznik> #endmeeting