17:02:13 #startmeeting kde-sig -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2011-11-29 17:02:13 Meeting started Tue Nov 29 17:02:13 2011 UTC. The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:02:13 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:02:24 #meetingname kde-sig 17:02:24 The meeting name has been set to 'kde-sig' 17:03:16 #topic roll call 17:03:20 Present. 17:03:26 * rnovacek is here 17:03:41 * ltinkl is present 17:03:46 * than is prent 17:04:05 rdieter is probably still fighting compoter emergency... 17:04:23 * jsmith is lurking 17:05:00 #info Kevin_Kofler rnovacek ltinkl than jreznik present, jsmith lurking 17:05:14 #chair Kevin_Kofler rnovacek ltinkl than 17:05:14 Current chairs: Kevin_Kofler jreznik ltinkl rnovacek than 17:05:29 #topic agenda 17:05:54 4.7.80 status 17:06:02 Enabling compositing by default (F17+) 17:08:10 ok, it's going to be probably quick meeting, let's start 17:08:20 #topic 4.7.80 status 17:08:50 4.8 is mostly built, thanks rdieter a rnovacek 17:08:59 rdieter was working on kdeutils split 17:09:28 * jreznik was working on kdeaccessibility split (still I have to upload jovie for review) 17:09:29 Yeah, a lot of new reviews because of a lot of new split tarballs dumped on us by upstream. :-( 17:10:11 Kevin_Kofler: even some already split packages are split again ;-) 17:10:13 * Kevin_Kofler still wonders whether the monolithic multi-tarball SRPM approach wouldn't have been more effective. 17:10:29 it's pain to import it... 17:10:44 It's a PITA to import the split stuff, too. 17:10:55 on the other hand - I received an input from users they like it this way... 17:11:19 but the scripts are the must, I'll take a look before beta 2 17:11:26 Yeah, users seem to like splits these days. I wonder why the pressure for splitting from users actually increased rather then decreased. 17:11:53 HDDs have grown larger and cheaper, yet people are more and more vocal about not wasting a single kilobyte, it's ridiculous. 17:12:25 Also because actually, the update metadata probably costs them MORE bandwidth than the monolithic packages. :-/ 17:12:58 Of course, TeXLive 201x is going to dump bazillions of metadata on everyone anyway… ;-) 17:14:29 it doesn't matter anymore as we progressed quite a lot, upstream decided to go with and not provide monolithic tarballs, even distros who argued against are now shipping split packages - so it's done 17:15:05 so anyone interested in reviews - feel free to take them 17:15:12 I'd actually argue to undo it, not do any further split reviews, instead go to multi-tarball SRPMs with no subpackages and have the monolithic packages Obsolete all the split ones. 17:15:44 #info 4.7.80 builds are mostly done 17:15:47 Heck, maybe even a monolithic kde-sc package with ALL the split tarballs in it. 17:16:02 #info kdeaccessibility and kdeutils are under review due to splits 17:16:18 (kinda like the TeXLive 2007 packaging) 17:16:26 Kevin_Kofler: wow, users would kill us :) 17:16:51 Of course, kde-sc would force us to go beyond a CD for the live image, too. :-/ 17:16:55 Kevin_Kofler: I don't want to see the specfile, with all the hacks together 17:17:00 Unless, we did kde-sc-cd and kde-sc-extras. ^^ 17:17:20 maybe fedora package :) 17:17:22 We'd even get to pick file by file what we want on the CD. 17:17:22 * jreznik hides 17:18:04 #action anybody feel free to take split packages reviews 17:18:33 ok, let's move, I'll let you know once we have the whole 4.7.80 build ready 17:18:48 #topic Enabling compositing by default (F17+) 17:19:12 So the background there is that upstream has actually been defaulting to compositing enabled on known-good drivers/hardware. 17:19:18 Yet we still force it off by default. 17:19:31 *upstream has been defaulting to it for several releases 17:19:46 Kevin_Kofler: the problem is - the list does not list all good/bad hardware 17:19:56 And I'm not sure why, now that gnome-shell is forcefully testing all the OpenGL drivers. 17:20:20 GNOME is even going to force OpenGL compositing and effects on software rendering. 17:20:23 for example it causes lockups on my nouveau machine and it's allowed to run it here 17:20:23 (in F17) 17:20:32 So my proposal is: 17:20:39 * stop forcing compositing off by default in F17, 17:20:44 and I saw a lot of completely broken f16s with completely broken gnome-shell 17:20:52 * unblacklist/whitelist llvmpipe if necessary, 17:21:06 (i.e. if it's not enabled by default upstream there) 17:21:24 * disable individual annoying effects by default. 17:21:36 (E.g. I really don't think shipping Wobbly Windows by default is a good idea, at all!) 17:21:39 * stop forcing compositing off by default in F17 - I'm not sure, too early - depends on drivers 17:21:41 I think the detection su*ks, let's face it :) on my system, it gets disabled eventhough everything works perfectly (ati/catalyst :) 17:21:53 ltinkl: Catalyst is known crap. 17:22:06 OpenGL 2 mode is known to be sloooooooooooooooooooooooooooow on Catalyst. 17:22:28 ye I know but it works just fine, unlike e.g. nouveau on jreznik's machine 17:22:31 * unblacklist/whitelist llvmpipe if necessary, +1, I tried effects in vm with llvmpipe when forced and it works, even not so slow I expected, some visible glitches 17:23:00 And anyway, if the driver is needlessly blacklisted, that's better than if it's wrongly whitelisted. ;-) 17:23:09 #info proposal 1: stop forcing compositing off by default in F17 17:23:12 I beg to differ :) 17:23:24 ltinkl's problem doesn't look like an argument for not enabling compositing by default in any case. 17:23:35 Changing the setting will have no effect on his machine anyway. 17:23:35 #info proposal 2: unblacklist/whitelist llvmpipe if necessary 17:23:55 #info proposal 3: disable individual annoying effects by default 17:23:59 Uhm, FYI, those are not really separate proposals. 17:24:05 They're supposed to be done all 3. 17:24:26 At least my proposal is to do all 3. 17:24:40 Kevin_Kofler: it can be separated - #2 depends on one but we can decide not to white list llvmpipe 17:24:42 I've read that even the famous blur effect got rewritten so it shouldn't cause problems any longer 17:24:54 Right. 17:24:59 I agree it's getting better 17:25:08 Blur wouldn't be on my list of effects to disable by proposal 3. 17:25:22 It's not annoying, at least if the performance optimizations worked. 17:25:37 Wobbly windows and crap like that are what I want disabled by default if it isn't already. 17:25:45 http://philipp.knechtges.com/?p=10 17:25:57 ^^ ad the blur effect & kwin in 4.8 17:26:00 I'd postpone it for a some time - or at least when we really try 4.8 17:26:13 hi, sorry for appearing in a random meeting completely out of nothing and off topic, but i have a little request for fedora-kde, with my oxygen artist hat on, and i thought that this is probably the best place to make such a request 17:26:15 I still don't want to force users to hell 17:26:34 ruphy: #fedora-kde pls :) 17:26:34 ruphy: Can you wait a few minutes until we get to open discussion= 17:26:38 s/=/? 17:26:39 ok :) 17:27:00 sorry, don't know the rules 0:-) 17:27:04 I don't think we're going to get much testing for compositing as long as it's disabled by default. 17:27:05 ruphy: np 17:27:29 Kevin_Kofler: but yeah, let's try in rawhide 17:27:37 Kevin_Kofler: indeed, let's enable it until/unless we see the bugreports coming :) 17:27:59 kwin in 4.8 should contain a lot of speed optimizations 17:28:06 ltinkl: we will see - I know a few people running gnome shell :) 17:28:27 KWin isn't Gnome Shell you know ;ú 17:28:44 another question is - what about open gl es kwin backend? I tried to build it, not successful - just a quck try 17:29:21 I'm not sure OpenGL ES is enabled in our mesa packages. 17:29:21 ltinkl: but similar in terms of accell usage 17:29:25 Talk to ajax. 17:30:29 Kevin_Kofler: ok, it was just a quick look, I hope it's enabled but not sure what and where... but can be an option too (even it's not shippable together) 17:31:20 mesa-libGLES - Mesa libGLES runtime libraries 17:31:58 but let's back to defaulting effects - at least I'm for trying #1 in rawhide, let's progress a little here 17:32:07 jreznik: +1 17:32:16 testing llvmpipe would be great too - so #2 17:32:30 for #3 let's wait for input - which effects are causing pain 17:32:36 * Kevin_Kofler hopes upstream won't kill him for #2… 17:33:04 OTOH, gnome-shell being enabled on llvmpipe, I don't see why KWin can't be, too… 17:33:09 Kevin_Kofler: for us it's quite important to have #2 17:33:36 as fedora uses llvmpipe, could be interesting for upstream to get bugreports on fresh llvmpipe 17:33:40 Right. 17:34:01 For #3, I'd like a list of what upstream actually enables by default in 4.8 so I can sanity-check it. 17:34:13 Kevin_Kofler: ok 17:34:17 agree 17:34:31 (-1 to enabling Wobbly in any case.) 17:35:04 * Kevin_Kofler hates that one particularly. 17:35:08 so Kevin_Kofler, rnovacek, ltinkl, than: what do you thing about the whole proposal (combined?) 17:35:35 +1 to my combined proposal, obviously. 17:35:37 enable compositing, most (all) effects and see the feedback 17:35:46 I agree with it 17:36:13 ltinkl: Uhm, I'd hope that "all" means only the effects upstream actually enables by default… 17:36:17 They're already too many IMHO. 17:36:25 Kevin_Kofler: yup, the default set 17:37:06 +1 for now, we should have some deadline to reconsider it - not to change it in the last minute back for f17 17:37:16 BTW, in 4.9, compositing will be required for more secure screen locking. 17:37:28 Or even in 4.8 if we backport it from the Plasma Active branch. 17:37:54 jreznik: Alpha Change Deadline minus 1 week. 17:38:04 Then again at Beta Change Deadline minus 1 week. 17:38:19 I still don't think it's prime time for desktop effects enabled by default, not with current drivers but let's see f17 and 4.8 together 17:38:38 #agreed to go with Kevin_Kofler's combined proposal 17:39:36 Kevin_Kofler: why two deadlines? 17:40:07 Because it can't hurt to evaluate it twice, in case new issues pop up. 17:40:52 (and I think Final Change Deadline is actually too late to revert this kind of things, which is why I'm not proposing a third check then) 17:41:09 #info deadline for evalution: alpha change deadline -1 week, then again beta change deadline -1 week (in case of new issues) 17:41:14 (Last-minute changes are always a source of trouble and stress.) 17:41:28 So, can we discuss the cursor thing now? 17:41:39 listening to this from Kevin_Kofler :) 17:41:40 ok 17:41:56 #topic Cursor theme in Plasma 17:42:15 So the main problem is that the systemwide cursor theme is hardcoded in Fedora's libXcursor package. 17:42:31 So e.g. KDM always ends up with the Adwaita cursor theme. 17:43:00 ruphy: Now I guess the question is: Can we ALSO ship the Oxygen theme on the live image? 17:43:12 There the answer is: Space is very limited on a live CD. 17:43:28 We actually got up to 698 MiB or something like that for F16. 17:43:44 how big is the cursor theme? /me doesn't remember 17:43:49 i don't think is that huge, is it? 17:44:04 18795128 17:44:05 Oxygen_Zion looks similar to Adwaita so when KDE started changes from Adwaita in KDM to Oxygen_Zion will be not very noticeable 17:44:07 and we have quite some room for improvement to be sincere 17:44:16 And that's all already compressed PNG and/or SVGZ files. 17:44:25 No way this fits on the live image. 17:44:33 Kevin_Kofler: is that byte count? is the the full package? 17:44:44 It's the size of the oxygen-cursor-themes package. 17:44:52 that contains all the colors 17:44:56 Hmmm, actually, I think it's even already the xz-compressed RPM size. 17:44:57 there's like 40 schemes 17:44:59 os sth 17:45:09 Anyway, compression is basically irrelevant because the stuff is already compressed. 17:45:23 (FWIW, that's the 4.6.5 RPM.) 17:45:27 yes, but even there, there's a lot of room for improvements 17:45:33 oxygen-cursor-themes-4.6.5-5.fc165 17:45:35 *fc15 17:45:43 18795128 is installed size but on live image it will be compressed 17:46:00 (We won't be at fc165 for another ~75 years. ;-) ) 17:46:21 nucleo: But it's already compressed. 17:46:21 i just checked, it's 10 cursor themes, including big versions 17:46:27 So it compresses very poorly. 17:46:32 Kevin_Kofler: yes, but you can compress it way further 17:46:50 * jreznik is not a big fan of oxygen cursors - looks like some game cursors :) 17:46:51 for a simple reason, there is a huge percentage of duplicated files 17:47:05 1259977 is size of rpm 17:47:26 is that about 1MB? 17:47:27 Hmmm, so xz does compress the stuff significantly, probably due to the duplicated files indeed. 17:47:43 Not sure what the hit on the live image will be. 17:47:47 1,2M 17:47:50 ok 17:48:00 you can remove a lot of duplicated files and replace them with symlink 17:48:01 Still, I'm not convinced we want to ship those themes we don't default to. 17:48:02 *symlinks 17:48:04 it will work 17:48:21 We also don't ship the upstream default wallpaper by default, for the same reason (space). 17:48:36 and then you get another big gain by splitting the package, you really need to provide just one version: white (or zion) small 17:48:42 not ten 17:48:59 And defaulting to Oxygen cursors isn't going to be easy considering how libXcursor is set up (hardcoded Adwaita default). 17:49:10 Kevin_Kofler: right - to ship something that is not default on live cd... 17:49:26 stripes was on F16 CD 17:49:32 can't you default it in KDE? 17:49:33 Kevin_Kofler: and I prefer Adwait (no offense to oxygen guys) 17:49:59 jreznik: the problem is about consistency: when i made that theme, it was made to fit in with icons and style elements 17:50:18 nucleo: That's because some subpackaging got screwed up (I think it got moved from kde-wallpapers to kdm in the last moment because it's actually part of kdm upstream). 17:50:39 I think we need to subpackage that away (maybe in a kdm-themes subpackage, which we want anyway because some KDM themes want the kde-wallpapers wallpapers too). 17:50:58 But that stripes wallpaper isn't actually that large. 17:51:22 guys, can't you default to oxygen when plasma starts up? 17:51:40 jreznik: I also used Adawaita but when I recently tried Oxygen_Zion I liked it :) 17:51:41 ruphy: that's the problem - I'm not sure it fits the rest of oxygen :) 17:51:51 nucleo: zion is better, indeed 17:52:10 We can probably change the theme for Plasma sessions, indeed. 17:52:20 KDM probably won't be consistent though… 17:52:28 Unless there's some way to force a cursor theme there too… 17:52:47 let's hope a user doesn't stare at kdm too much then ;-) if there isn't a way to force it 17:53:00 We're probably also going to end up with Adwaita also forced onto the live image as a dependency. :-/ 17:53:09 jreznik: it is :p there are some of the cursor icons also in the oxygen theme 17:53:25 Last time we looked into this, we figured that just using Adwaita cursors is the path of least resistance. 17:53:34 jreznik: it took about 6 months to be designed... cursor themes are hard ;-) 17:54:18 ruphy: We don't doubt that designing the theme was work. But I think any other theme also took time to design. ;-) 17:54:33 Well, maybe except for the default fallback hardcoded in X11, which looks like crap. ;-) 17:54:36 oh yes 17:54:45 no, actually it's very good 17:54:53 adawaita theme is really awesome 17:55:03 but that's why it's so hard to find great cursor themes 17:55:17 I don't mean Adwaita, but what you get if no theme is configured inside libXcursor, or if the configured theme is not installed. 17:55:24 ruphy: I'm not saying it's not hard :) 17:55:32 it's very hard to make them: i could say only the old crystal cursors were at the same level 17:55:38 We've had that theme come up on the live image at some point because Adwaita wasn't getting dragged in and everyone complained. 17:55:44 (of adawaita, oxygen and a couple of others) 17:56:04 Kevin_Kofler: yes, i got that... and you can live with it. with a non-great cursor theme you usually just hate it :) 17:56:24 Adwaita doesn't draw complaints, indeed. 17:56:35 Kevin_Kofler: what i think, as a kde designer, is that if adawaita is also there it's okay, the thing is, it would be awesome if we could manage to see oxygen cursors when we load an "oxygen desktop" 17:56:59 I must say I also find it quite sad that we end up with GNOME 3 cursors in Plasma 4 sessions. 17:57:12 Adwaita == GNOME 3 artwork 17:57:21 adawaita is one of the best themes of the linux desktop :) it's just that for kde 4 we had tried to design a full *KDE* esperience 17:57:38 so that you could go and look at your desktop and see it all integrated well 17:58:40 the thing with kde experience is inconsistency - oxygen qwidgets/plasma widgets/tray icons/theme, sometimes does not fit well and not saying it's bad 17:59:19 tray icons are sometimes bad 17:59:22 Indeed, I've been complaining about those consistency issues for a while. 17:59:24 maybe we can default to Plasma Tablet theme :) 17:59:27 at least not defaults 17:59:32 ahahahahahah 17:59:33 Plasma doesn't care about matching the looks of the apps. 17:59:50 the good this is that all has been designed by the same guy ;-) (nuno) 18:00:06 what is that you find inconsistent? 18:00:09 IMHO, we should actually default to these: http://kde-look.org/content/show.php?content=134914 18:00:12 I propose - let's talk about it on kde-ml - to receive some input 18:00:33 1. The Plasma components/widgets don't look anything like the normal QWidgets. 18:00:36 oh no no no please, let's not go that way 18:00:50 colored systray makes an awful color mess :( 18:00:51 2. The systray icons don't look anything like normal Oxygen icons. 18:01:21 well, it should be this way 18:01:23 AFAIK, Oxywin might help for #1 (though I haven't tried it, I actually use Atelier, which looks closer to my old-school Bluecurve QWidgets). 18:01:35 And my systray theme helps for #2. 18:01:41 ruphy: I agree - no color mess in systray but no to icons that are not very visible on default panel's color 18:01:44 But it's sad that those are not the defaults. 18:02:02 BTW, I made the theme, but the actual icons are all the Oxygen people's work. 18:02:06 it's the difference between the workspace and the apps.. 18:02:12 ok, we are over - so I think post to f-k-ml is ok now 18:02:16 I just made the stuff fit the technical requirements for a systray theme. 18:02:26 ruphy: That's exactly the problem. 18:02:31 The workspace should match the apps! 18:02:52 ruphy: I don't get that difference between apps and workspace - especially when we are starting to work on active apps using plasma components... 18:02:54 * ruphy humbleys disagrees 18:02:55 :[ 18:02:57 :p 18:02:58 BTW, look at the comments for my theme, all positive. 18:03:26 if you want something that matches, use aya 18:03:29 This is Oxywin: http://kde-look.org/content/show.php/Oxywin?content=112004 18:03:34 so everything is going to be plasma app instead of qwidget based... 18:03:42 Kevin_Kofler: those not using it will not comment on it :) 18:04:03 that means we will have two different plasma themes for apps and workspace? 18:04:07 The screenshots are not good enough to know how good it is though, and as I said, I haven't tried it yet. 18:04:08 ok, let's stop now :) 18:04:24 move #fedora-kde :) 18:04:26 jreznik: That'd be great because then I can force the apps theme for everything. ^^ 18:04:28 ahahah :) ok 18:04:56 jreznik: active apps won't see much adoption for the desktop 18:04:57 at least 18:04:58 #info kde sig to talk about possibility of putting oxygen icon theme on live cd and possibility of making it default 18:04:58 BTW, I need to fix my colored theme to handle the new Apper icon. 18:05:02 they will but in a different way 18:05:39 ruphy: it's going to change - soon, with qt 5 and more qml stuff around... I expect 18:05:47 ok, guys, thanks :) 18:05:53 #endmeeting