16:01:52 <rdieter> #startmeeting
16:03:05 <rdieter> #topic KDE SIG Meeting -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-07-07
16:03:20 <rdieter> who's present today?
16:03:54 <slipp3d> +1
16:04:00 <rdieter> #meetingtopic KDE SIG Meeting -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-07-07
16:04:06 <rdieter> #topic Init
16:04:10 <Kevin_Kofler> Present.
16:04:12 * SMParrish_ here
16:04:15 <than> present
16:04:56 <rdieter> ok, let's go down the agenda
16:05:14 <rdieter> #topic fake transparency support for Plasma, http://reviewboard.kde.org/r/472/
16:05:20 <rdieter> Kevin_Kofler: ?
16:06:08 <Kevin_Kofler> So I've put this up after vtokarev reminded me of it.
16:06:22 <Kevin_Kofler> That's a patch by a KDevelop developer which adds fake transparency support to Plasma.
16:06:32 <than> rdieter, i don't think it's good idea to add it in our package
16:06:35 <Kevin_Kofler> Aaron rejected it because he says people should just use compositing.
16:06:49 <rdieter> than: I agree
16:06:58 <than> Kevin_Kofler, i agree with Aaron here
16:07:30 <Kevin_Kofler> Well, it'd make the panel with all those transparent themes look a lot better without compositing.
16:07:53 <Kevin_Kofler> And there isn't really a strong technical reason to reject it, it's just Aaron's "no hacks" policy.
16:09:14 <than> Kevin_Kofler, he knows  what he said
16:10:54 <rdieter> I'm not willing to help support it downstream either.  There's a right way to do move forward, and this (including rejected upstream patches) isn't it.
16:11:13 <rdieter> vtokarev: can you comment?
16:11:54 <vtokarev> well, it's not a wise move from the KDE side to reject patch that makes usability experience better
16:12:37 * rdieter questions the need to pull the "usability" card here, but go on...
16:12:59 <SMParrish_> Do we really want the headaches that will come with maintaining a patch that upstream will never include?
16:13:34 <vtokarev> and people still can't enable composite always without a headache
16:13:46 <rdieter> vtokarev: are you involved in authoring the patch?
16:13:53 <vtokarev> nope
16:14:19 <rdieter> what's your interest here then?  simply a user who's interested in bling without compositing? :)
16:15:16 <vtokarev> just saying my opinion, that's it
16:15:55 <rdieter> vtokarev: ok, thanks.
16:16:43 <rdieter> any other thoughts/comments?
16:17:51 <than> we don't want plasma upstreamer Aaron complains again by KDE SIG team
16:18:26 * thomasj thinks.. fake-transparency.. no need for that one.
16:18:41 <slipp3d> +1 with thomasj
16:18:45 <Kevin_Kofler> I think our primary goal should be to make users happy.
16:18:54 <Kevin_Kofler> But I don't care strongly about that patch.
16:19:13 <Kevin_Kofler> I don't even use a transparent theme. ;-)
16:19:15 <rdieter> It would appear there is little support for incorporating the patch at this time.  I'd welcome further discussion on fedora-kde list, if folks want to pursue it further.
16:19:36 <than> rdieter, you can probably build the package with this patch for kde-redhat
16:19:47 <Kevin_Kofler> That said, I don't know how it'll be with Air, but Oxygen looked really ugly on our default setup because of the strange color it uses when there's no transparency.
16:20:06 <rdieter> air is better
16:20:26 <rdieter> #topic qt-copy vs kde-qt git branch
16:20:30 <Kevin_Kofler> If Air doesn't look that bad without transparency, there's probably no strong need for the patch.
16:20:43 <Kevin_Kofler> rdieter: Don't we want to log an #agreed?
16:20:44 <rdieter> ltinkl wanted this discussed, but he doesn't seem around.
16:21:22 <rdieter> #agreed  kde-sig will not incorporate fake transparency patch at this time
16:21:41 <than> as i know kde developers recomments to use patches kde-qt
16:21:58 <than> there's a disccusion on kde-devellist
16:21:58 <rdieter> we all know (hopefully) by now that qt-copy is going away
16:22:06 <Kevin_Kofler> Thiago says kde-qt is now the canonical source.
16:22:33 <rdieter> So, it's a foregone conclusion we'll want to switch.  may as well do it sooner rather than later.
16:22:39 <Kevin_Kofler> There are 2 or 3 patches in qt-copy which didn't get committed to kde-qt git yet.
16:23:05 <Kevin_Kofler> Thiago says the committers are responsible for committing to git, but they don't seem to care.
16:23:06 <than> Kevin_Kofler, we can commit the missing patches
16:23:13 <Kevin_Kofler> He also didn't like one of the patches.
16:23:38 <rdieter> anyone want to work on the kde-qt switch?  or assign to ltinkl ?  :)
16:24:05 <than> rdieter, i will take care of it
16:24:14 <Kevin_Kofler> (0280 is the one he says is wrong and the author didn't care enough to fix it.)
16:24:37 <Kevin_Kofler> (actually 0285, but he complained about 0280 as well)
16:24:38 <rdieter> #action than will work on switch to kde-qt git branch
16:24:52 <Kevin_Kofler> 0283 and 0285 are the missing ones I know of.
16:25:14 <Kevin_Kofler> But Thiago doesn't feel responsible for merging 0283 and he plain doesn't like 0285.
16:25:50 <rdieter> reminds me, who can commit to kde-qt ?  If they allow it, I'd like at least 1-2 of us to get commit access
16:26:01 <Kevin_Kofler> Meanwhile git got a new patch (0286) which isn't in qt-copy and will probably never land there.
16:26:22 <than> Kevin_Kofler, if the patch are wrong why do we want to commit them?
16:26:25 <Kevin_Kofler> These are the committers to kde-qt: http://gitorious.org/+kde-developers
16:26:56 <Kevin_Kofler> 0283 is not wrong, at least not that I know of.
16:27:13 * than is taking a look at 0283
16:27:15 <Kevin_Kofler> As for 0285, it fixes a real issue, I'm not sure why Thiago thinks it's wrong, it needs more discussion there.
16:28:09 <rdieter> let's move on...
16:28:14 <rdieter> #topic Phonon-GStreamer QA
16:29:07 <Kevin_Kofler> If we want to make Phonon-GStreamer the default, we need to do some proper testing. In particular I'm thinking of:
16:29:10 * rdieter puts on wwoods'-like QA hat, seems like we need to document a test plan, and execute it with a wide audience, and see how things go.
16:29:30 <Kevin_Kofler> * default Rawhide KDE installation (having live images would help there, unfortunately svahl is not present)
16:29:45 <Kevin_Kofler> * install pavucontrol (to see what is really being sent to PA)
16:29:58 <rdieter> may be a good excuse to get auto-mime handling working, mandriva has some phonon patches for that (codeina-like functionality)
16:30:09 <Kevin_Kofler> * try playing audio with Phonon-based media players (Amarok, Dragon Player)
16:30:17 <Kevin_Kofler> * check what happens in pavucontrol
16:30:34 <Kevin_Kofler> What should happen: the player shows up as a native app in pavucontrol.
16:30:37 <Kevin_Kofler> What should NOT happen:
16:30:49 <Kevin_Kofler> * pavucontrol says "(ALSA plugin)"
16:30:58 <rdieter> Kevin_Kofler: mind splatting your mind-dump into a wiki page? :)
16:31:03 <Kevin_Kofler> * device "foo" is not working, falling back to "bar"
16:31:24 <Kevin_Kofler> * Phonon, GStreamer or PulseAudio crashes
16:31:37 <Kevin_Kofler> or other assorted breakage. :-)
16:31:42 <Kevin_Kofler> rdieter: I can do that.
16:31:49 <than> Kevin_Kofler, could you please add them in wiki pages
16:32:02 <rdieter> #action Kevin_Kofler to work on documenting a Phonon-GStreamer test plan
16:32:19 <Kevin_Kofler> Trying to play exotic MIME types like MIDI, XM/IT/MOD etc. with the appropriate GStreamer plugins would also be a good testcase (after we got PA tested).
16:32:33 <thomasj> Question: Why would we change to phonon-gstreamer as default?
16:33:01 <thomasj> I mean xine-backend is working flawless for me, maybe just for me.
16:33:29 <thomasj> And even the gstreamer guys dont like their stuff that much, according to guadec comments.
16:33:45 <rdieter> thomasj: it's not cut-and-dried yet, but we're seriously considerring it for F-12 is all.
16:33:58 <Kevin_Kofler> There are pros and cons.
16:34:02 <rdieter> thomasj: can you elaborate on the guadec comments/feedback?
16:34:05 <Kevin_Kofler> Phonon-Xine indeed works fine for me too.
16:34:14 <Kevin_Kofler> But some reasons to switch to GStreamer include:
16:34:23 <thomasj> rdieter, i have read an article about it at linux-magazine.de
16:34:25 <Kevin_Kofler> * it's supposedly the default multimedia framework in Fedora
16:34:50 <Kevin_Kofler> * RHEL most likely won't include xine-lib, so no Phonon-Xine either (except possibly in EPEL, but not base RHEL)
16:34:57 <thomasj> rdieter, i try to find it again.
16:35:38 <rdieter> Kevin_Kofler: more than most likely. :)
16:35:40 <Kevin_Kofler> * Nokia / Qt Software doesn't support Phonon-xine for licensing reasons (it's GPL only, no LGPL or commercial option), and this means there's little interest in fixing bugs like QtWebKit not displaying video with it.
16:36:05 <Kevin_Kofler> rdieter: Well, if there was no other choice, they'd be more or less forced to. But there is another choice, so...
16:36:50 <rdieter> but, the horizon is that -gstreamer seems to have a better supported future, so we're exploring it.
16:37:01 <Kevin_Kofler> For the Nokia part: Now arguably QtWebKit is the problem. ;-) But this sort of issues may show up in other places of Qt.
16:37:31 <Kevin_Kofler> The cons of switching are: KDE mostly only supports Phonon-Xine.
16:37:44 <Kevin_Kofler> AFAIK most Amarok developers still hate Phonon-GStreamer.
16:38:15 <Kevin_Kofler> It's also badly integrated into System Settings (some options such as the GStreamer sink to use can only be set through qtconfig-qt4).
16:38:43 <Kevin_Kofler> And new features like equalizer support apparently also get implemented only in Phonon-Xine.
16:39:02 <rdieter> We could help work on said integration, if that's the path we choose.
16:39:23 <Kevin_Kofler> The current situation is that Qt is backing GStreamer and KDE is backing xine-lib. :-(
16:40:01 <thomasj> rdieter, ok, basically, they want a 1.0 branch to change the ABI/API because they cant make new things happen with the old 0.10. one. Like KDE made the cut between 3 and 4. Dunno if thats important to wait for the new branch. Sorry, took some time.
16:40:09 <Kevin_Kofler> It's a pretty sad state of affairs because there's no KDE without Qt and KDE-less Qt isn't interesting for us either.
16:40:49 <Kevin_Kofler> thomasj: I think we'll be stuck with a gstreamer010 just like we had gstreamer08 for a while.
16:41:09 <rdieter> ok, let's move on...
16:41:15 <Kevin_Kofler> Waiting makes no sense, Phonon hasn't even started porting to the new API and it seems not to even be started upstream yet.
16:41:26 <rdieter> #topic KDE SIG Meeting Time, can we start 1 hour earlier? Tuesday at 15:00 UTC
16:41:50 <rdieter> according to http://fedoraproject.org/wiki/Fedora_meeting_channel , the next slot avail it 14:00 (15:00 is bugzappers)
16:42:02 <Kevin_Kofler> Right, the meeting room is the main problem.
16:42:27 <Kevin_Kofler> Who is asking to move the time?
16:42:28 <rdieter> there is a #fedora-meeting-1 though
16:42:33 <rdieter> not sure who added that.
16:42:38 <than> rdieter, me
16:42:42 <rdieter> ah. :)
16:42:50 <than> it's bad time for me
16:42:51 <Kevin_Kofler> I think MathStuf was also unhappy with the current time because he has to work at this time.
16:43:00 <rdieter> is 14:00 better ?
16:43:01 <Kevin_Kofler> But I don't think 1 hour earlier will change things for him.
16:43:14 <than> 14:00 is fine with me
16:43:30 <Kevin_Kofler> 14:00 UTC = 16:00 CEST (and will be 15:00 CET in the winter if we keep it).
16:44:40 <rdieter> ok, sounds like a good start, than, mind taking it to fedora-kde list for more comment?  If no one objects too much over the next few days, we can switch starting as early as next week.
16:45:03 <Kevin_Kofler> I won't object to Tuesday 14:00 UTC.
16:45:21 <than> rdieter, it sounds good
16:45:26 <rdieter> fwiw, I'm ok with 14:00 too
16:45:49 <rdieter> speaking of next week, fyi, I and Kevin_Kofler will miss next weeks' meeting
16:46:09 <Kevin_Kofler> Maybe we should just cancel it entirely?
16:46:15 <rdieter> vacation for me
16:46:28 <than> i will be on vacation too
16:46:30 <rdieter> those around can decide whether or not to have a meeting
16:46:33 <rdieter> hee. :)
16:46:40 <than> i think we should cancel it
16:46:45 <Kevin_Kofler> than: +1
16:46:52 <rdieter> ok, stick a fork in it, it's dead
16:46:57 <SMParrish_> lol
16:47:21 <rdieter> #agreed next week's meeting, 07/14 cancelled, too many vacation'ers
16:47:35 <rdieter> #topic open discussion
16:47:40 <rdieter> anything else for today?
16:47:43 <nirik> I have a quick item.
16:47:58 <SMParrish_> 1 item here as well
16:48:06 <rdieter> nirik: go ahead
16:48:43 <nirik> I have finally gotten the meetbot code package imported. This meeting is the first one using the 0.1.1 code, so please give me any feedback on problems or enhancements you would like to see. I expect we will have it in zodbot soon and putting logs up on a fedoraproject.org site also soon. ;)
16:49:20 <nirik> it will also write out a restructured text version of the summary, so that might be usefull for posting to lists, etc. Or at least as a starting point for doing so.
16:49:21 <rdieter> neat, ok
16:49:24 <nirik> that's all. ;)
16:49:34 <rdieter> SMParrish_: go
16:50:43 <SMParrish_> rhughes pushed a new version of PK to rawhide.  KPK should work execept for PolicyKit integration
16:51:16 <Kevin_Kofler> KPK doesn't use PolicyKit directly at all.
16:51:24 <Kevin_Kofler> It's all handled within PackageKit.
16:52:02 <Kevin_Kofler> The problem is that we don't have a polkit-kde for PolicyKit 1.
16:52:12 <Kevin_Kofler> jreznik has started working on it.
16:52:21 <Kevin_Kofler> But I don't know how far it is.
16:52:39 <SMParrish_> then we should be ok then.  Upstream just passed that on to me this am
16:52:47 <rdieter> thanks for the update.
16:53:14 <Kevin_Kofler> I haven't found any PolicyKit-using code when I searched KPackageKit for it.
16:53:25 <Kevin_Kofler> See also my comment on the bug report.
16:53:35 <Kevin_Kofler> (the one which asks to port kpackagekit to PolicyKit 1)
16:53:52 <SMParrish_> they are working on the port now
16:54:35 <Kevin_Kofler> But what I don't get is: what's being ported?
16:54:45 <Kevin_Kofler> There's no PolicyKit code within KPK in the first place.
16:54:46 <SMParrish_> and all the PolicyKit code is going into Packagekit-qt
16:55:28 <SMParrish_> your right its all in packagekit-qt which is part of Packagekit but was originally part of KPK
16:55:59 <Kevin_Kofler> OK
16:57:14 <rdieter> we're about out of time, let's wrap things up
16:57:31 <rdieter> #endmeeting