15:08:01 <rdieter> #startmeeting kde-sig
15:08:01 <zodbot> Meeting started Tue Jul 16 15:08:01 2013 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:08:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:08:05 <rdieter> #meetingname kde-sig
15:08:06 <zodbot> The meeting name has been set to 'kde-sig'
15:08:09 <rdieter> #topic roll call
15:08:18 <rdieter> hi all, who's around today?
15:08:26 <rdieter> than sends his regards
15:08:26 <mbriza> hey
15:09:14 <Kevin_Kofler> Present.
15:10:54 <dvratil> present (sort of)
15:12:00 <rdieter> #info rdieter mbriza Kevin_Kofler dvratil(sort-of) present
15:12:06 <rdieter> #chair mbriza Kevin_Kofler dvratil
15:12:06 <zodbot> Current chairs: Kevin_Kofler dvratil mbriza rdieter
15:12:08 <heliocastro> rdieter: me
15:12:19 <rdieter> #info heliocastro present too
15:12:23 <rdieter> hola
15:12:28 <heliocastro> :-)
15:12:28 <rdieter> #topic agenda
15:12:36 <Kevin_Kofler> #chair heliocastro
15:12:36 <zodbot> Current chairs: Kevin_Kofler dvratil heliocastro mbriza rdieter
15:12:46 <rdieter> what to discuss today?
15:12:58 <heliocastro> Can i add a topic ?
15:13:00 <rdieter> 4.10.5 status (though than probably knows best about that)
15:13:03 <rdieter> heliocastro: sure
15:13:11 <heliocastro> I just got an Kira =book
15:13:19 <heliocastro> high dpi, 2540 x 1440
15:13:22 <heliocastro> 13"
15:13:31 <heliocastro> KDE is barely ready as default
15:13:48 <heliocastro> tiny fonts, bad KDM our lighdm-kde
15:14:07 <Kevin_Kofler> And SDDM? :-)
15:14:17 <heliocastro> Not tested yet
15:14:34 <Kevin_Kofler> (mbriza likes that one and is doing some upstream development on it now.)
15:14:36 <heliocastro> But the current status is that half of the apps respect dpi settings
15:14:48 <mbriza> sddm status: i opened a package review, don't recommend for general usage yet, am working with upstream on fixing PAM
15:14:52 <heliocastro> and we need chnage in three places at all
15:15:12 <rdieter> heliocastro: yeah, i've been meaning for awhile to force 96dpi in kde for awhile to match the rest of the world
15:15:14 <heliocastro> Xresources, systemsettings on KDE and fixed in some applications
15:15:33 <heliocastro> My acceptable here was 148 dpi
15:15:54 <heliocastro> good enough with 172, but i'm not that eagle vision
15:16:16 <Kevin_Kofler> rdieter: -1
15:16:17 <rdieter> heliocastro: what is the default (non-hardcoded) dpi?
15:16:24 <heliocastro> 96
15:16:42 <rdieter> heliocastro: that's what xdpyinfo says?
15:16:42 <Kevin_Kofler> heliocastro: Broken hardware or X11 driver then.
15:17:05 <Kevin_Kofler> So the thing is, you should have to set the dpi exactly ONCE: in KDE's System Settings.
15:17:25 <Kevin_Kofler> It's supposed to be enforced directly for Qt/KDE apps and through xsettings-kde for GTK+ apps.
15:17:30 <heliocastro> screen #0:
15:17:31 <heliocastro> dimensions:    2560x1440 pixels (290x170 millimeters)
15:17:32 <heliocastro> resolution:    224x215 dots per inch
15:17:34 <heliocastro> depths (7):    24, 1, 4, 8, 15, 16, 32
15:17:43 <rdieter> ok, so real dpi is ~220
15:17:48 <Kevin_Kofler> If apps aren't honoring those settings, it's a bug somewhere.
15:18:02 <heliocastro> gtk is fine after xsettings-kde
15:18:14 <Kevin_Kofler> With "resolution:    224x215 dots per inch", the default dpi in KDE is SUPPOSED to be 224 or 215.
15:18:14 <rdieter> Kevin_Kofler: k, I forgot that xsetttings-kde handled that
15:18:15 <heliocastro> from the closed side, chrome is the most stupid
15:18:42 <rdieter> any other agenda topics?
15:18:43 <Kevin_Kofler> The thing is, if we force 96 dpi on the KDE end, it will not make this work any better.
15:18:51 <rdieter> Kevin_Kofler: yeah, nevermind
15:19:03 <Kevin_Kofler> But somehow it's getting forced to 96 anyway and I have no idea from where.
15:19:13 <Kevin_Kofler> The default is supposed to be what the hardware reports.
15:19:23 <Kevin_Kofler> Unless upstream changed something recently.
15:19:53 <heliocastro> Kevin_Kofler: You don't want to see the console :-P
15:20:00 <heliocastro> you need zoom
15:20:18 <rdieter> #topic qt/kde on high-resolution devices
15:20:24 <Kevin_Kofler> The console mode is its own can of worms.
15:20:30 <rdieter> since we're currently discussing that
15:20:40 * jreznik_ is listening
15:20:43 <Kevin_Kofler> Not much we can do about that one in KDE SIG.
15:21:00 <rdieter> #info qt/kde should "just work" to respect system dpi
15:22:18 <Kevin_Kofler> The problem is, as long as we have prominent X11 developers arguing that "dpi" should be a constant of 96 without the letters 'd', 'p' and 'i' actually meaning anything, we will never get this working everywhere. :-(
15:22:20 <rdieter> plasma *may* be an outlier here, I haven't tested it myself on high dpi ever
15:22:48 <rdieter> heliocastro: so, in particular, which apps didnt respect dpi?  you mentioned kdm?
15:22:55 <rdieter> and chrome...
15:23:03 <Kevin_Kofler> rdieter: Oh, that's another fun thing, Plasma sometimes gets the dpi right, sometimes not, and I haven't been able to ever figure out why it's sometimes wrong.
15:23:23 <rdieter> in short, I think we need to identify particular apps that misbehave
15:23:28 <heliocastro> rdieter: kdm respect after teaks
15:23:35 <heliocastro> tweaks
15:23:43 <Kevin_Kofler> KDM doesn't run in a Plasma session, so it's special.
15:23:50 <heliocastro> lightdm-kde gots confsed with resolution
15:23:57 <Kevin_Kofler> Chrome is, well, Chrome. Don't use proprietary software if you expect your software to actually WORK. ;-)
15:24:02 <rdieter> heliocastro: ok, what kind of tweaking was required?
15:24:13 <heliocastro> on kdmrc
15:24:18 <heliocastro> let me check
15:25:09 <rdieter> short of simply configuring to use larger font?
15:25:29 <heliocastro> XResources
15:25:35 <heliocastro> large font is ok
15:25:44 <heliocastro> but you need do the same for X
15:26:02 <heliocastro> rdieter:
15:26:04 <heliocastro> ! Fix the Xft dpi to 96; this prevents tiny fonts
15:26:05 <heliocastro> ! or HUGE fonts depending on the screen size.
15:26:06 <heliocastro> Xft.dpi: 148
15:26:29 <rdieter> boo, so Xft.dpi doesn't get set right by default?
15:26:30 <heliocastro> X is fixed on 96, but xterm not respecting as well
15:26:48 <heliocastro> rdieter: Remember that kdm has Xresources internal
15:27:19 <rdieter> ok, there's various other distro places that hardcode dpi to our frustration. :(
15:27:59 <rdieter> and I doubt that's ever going to change, I suppose... one thing to help in the short term would be document all this on the wiki somewhere
15:28:27 <rdieter> so interested parties (like us and other kde users) could know what requires (re)configuration
15:28:48 <heliocastro> look the current situation on my desktop:
15:28:51 <heliocastro> http://heliocastro.info/snapshot1.png
15:29:06 <heliocastro> This shows exactly how xterm is behaving even after Xresources set
15:29:54 <rdieter> ok, either xterm uses something else or we have a plain-ole bug
15:30:32 <Kevin_Kofler> xterm is not using any of the standard toolkits.
15:30:40 <Kevin_Kofler> So of course it doesn't pick up desktop settings.
15:30:45 <Kevin_Kofler> Why are you still using that ancient thing?
15:31:05 <rdieter> its just an example of an app that still doesn't respect dpi
15:31:13 <rdieter> even with Xresources set
15:31:16 <Kevin_Kofler> Konsole or any other Qt or GTK+ terminal picks up the dpi right.
15:31:19 <heliocastro> This ancient thing is a good fallback for tons of testing
15:31:50 <Kevin_Kofler> Well, it's an example of an ancient non-Qt non-GTK+ app. It isn't even expected to do the right thing here.
15:32:16 * rdieter wonders how java apps handle dpi
15:32:22 <heliocastro> Aha
15:32:25 <heliocastro> wait a second :-)
15:32:43 <Kevin_Kofler> Basically, there's Qt, there's GTK+, and then there's "everything else", which tends to be broken. :-(
15:33:17 * rdieter thought low-level X toolkits uses Xft or XResources
15:33:43 <rdieter> but true, if even those aren't used, not much else we can do
15:33:50 <heliocastro> http://heliocastro.info/snapshot2.png
15:34:25 <heliocastro> So, intellij, pure Java
15:34:46 <heliocastro> rdieter: I needed force intellij use  bigger fonts
15:35:04 <Kevin_Kofler> Confirms my "everything else" theory… Sigh… :-(
15:35:05 <rdieter> ok. :(
15:35:46 <heliocastro> BUT
15:35:57 <heliocastro> you use GTK+ as base for Java
15:35:58 <heliocastro> wors
15:36:01 <heliocastro> works
15:36:27 <heliocastro> But i not touch the inner problem yet
15:36:29 <Kevin_Kofler> Sure, because GTK+ gets the setting through XSettings.
15:36:34 <heliocastro> There's one bigger
15:36:46 <heliocastro> it's called embedded html
15:36:52 <heliocastro> example, kmail
15:37:09 <heliocastro> view an html email, is small as hell, and only partial fonts rescale
15:37:19 <heliocastro> despite the whole interface is ok
15:37:30 <Kevin_Kofler> The GTK+ look&feel really ought to be the default under KDE, I filed a bug for that at IcedTea, maybe I should try filing it at Oracle and see what THEY do with it.
15:37:52 <heliocastro> So summarizing, is a hell now
15:38:18 <Kevin_Kofler> heliocastro: The HTML thing is probably crappy CSS forcing font sizes in pixels.
15:38:25 <Kevin_Kofler> That insanity is WAY too common.
15:38:33 <heliocastro> Let me show to you now whats happened with intellij with GTK
15:38:35 <rdieter> with no good solution in sight, since the powers-that-be currently actively work against using screen dpi
15:38:40 <Kevin_Kofler> I don't understand why idiot webmasters think pixels are an acceptable unit for font sizes!
15:38:44 <Kevin_Kofler> They're obviously not. Grrr!
15:39:28 <Kevin_Kofler> rdieter: The only alternative is really to use a smaller (non-native, zoom) resolution. :-/
15:39:31 <heliocastro> http://heliocastro.info/snapshot3.png
15:39:37 <heliocastro> look the beatifull mess
15:40:02 <rdieter> heliocastro: beautiful
15:40:28 <heliocastro> :-)
15:40:45 <rdieter> distros/toolkits in general will have to learn to adapt and handle high-res screens sooner or later
15:40:52 <rdieter> will have to think about it more
15:40:54 <Kevin_Kofler> Java/Swing at its "best".
15:41:07 <rdieter> any final thoughts on the topic before moving on?
15:41:10 <Kevin_Kofler> Swing is a horribly broken piece of crap (just like all the other non-Qt, non-GTK+ toolkits).
15:41:43 <Kevin_Kofler> rdieter: All the other toolkits need to either get fixed somehow or just die.
15:42:00 <heliocastro> Unlikely
15:42:11 <Kevin_Kofler> heliocastro: There's no third option.
15:42:20 <Kevin_Kofler> Either you fix the toolkit or you uninstall the app.
15:42:21 <heliocastro> We still have important tools, like audacity, based on wxWindows
15:42:31 <Kevin_Kofler> wxWidgets uses GTK+ behind the scenes.
15:42:49 <Kevin_Kofler> Things like wxWidgets or SWT are NOT the problem.
15:43:05 <Kevin_Kofler> Things that do their own drawing and do it poorly are.
15:43:44 * rdieter largely agrees with Kevin_Kofler .  If app "foo" makes unfortunate toolkit choices, that lack features to handle dpi properly... well, that's largely *their* problem
15:44:13 <Kevin_Kofler> (and by the way, wxWidgets hasn't been called "wxWindows" anymore for ages!)
15:44:28 <rdieter> in particular, the problem will be the same (or worse) on !kde desktops too
15:44:56 <Kevin_Kofler> Right.
15:45:09 <Kevin_Kofler> Not much that can be done other than fixing the offending toolkit.
15:45:20 <Kevin_Kofler> (or if it's homegrown, the app)
15:46:30 <Kevin_Kofler> Even just reading the XSetting for DPI should make it work everywhere (under KDE thanks to xsettings-kde, under GTK+-based desktops thanks to their native settings daemon).
15:46:47 <Kevin_Kofler> That said, Wayland is going to open another can of worms there, because there's no XSettings without X.
15:46:48 <rdieter> heliocastro: are you subscribed to kde@lists.fedoraproject.org ?   if so, would you mind outlining the changes you had to make to accomodate high res/dpi ?
15:46:58 <rdieter> outlining in a post, that is.
15:47:23 <Kevin_Kofler> (Last I checked, the "fix" from GTK+ was to read GNOME GSettings directly under Wayland, which will of course not work on other desktops.)
15:47:30 <rdieter> heck, even if you're not subscribed, I'll approve the post
15:47:53 <rdieter> for posterity
15:47:59 <rdieter> otherwise, let's move on...
15:48:03 <rdieter> #topic kde-4.10.5 status
15:48:16 <rdieter> looks like than was doing most of the work on 4.10.5 builds so far
15:48:25 <rdieter> submitted f19 update that went stable already
15:48:30 <rdieter> f18 update is pending
15:48:35 <heliochissini> ohh, good
15:48:38 <rdieter> I don't see any f17 builds yet
15:49:03 <Kevin_Kofler> It's not even in the dist-git f17 branch yet.
15:49:38 <rdieter> I can start some f17 builds after meeting
15:49:50 <rdieter> stuff low in the stack at least, kdelibs, etc...
15:51:15 <rdieter> we'd discussed a patch than backported for kdenetwork/krdc to make it use freerdp instead of rdesktop, except there appears to be issues with it
15:52:00 <rdieter> so I think we'll revert back to rdesktop in the short-term, until that's sorted out
15:52:13 <Kevin_Kofler> Speaking of updates: https://admin.fedoraproject.org/updates/FEDORA-2013-12570/strigi-0.7.8-1.fc18 needs 1 more karma.
15:52:20 <rdieter> maybe defer freerdp feature until 4.11 lands
15:52:26 <Kevin_Kofler> For some reason, strigi is marked critpath in F18, but not F17 nor F19.
15:53:31 * rdieter karma'd
15:53:42 <Kevin_Kofler> rdieter: Thanks.
15:55:15 <Kevin_Kofler> strigi 0.7.8 queued for stable everywhere.
15:55:44 <heliocastro> The boy that fixed the whole engines on this won the akademy awards
15:55:57 <rdieter> vhanda?
15:56:10 <rdieter> very deserving, cool
15:56:43 <heliocastro> Yep
15:57:02 <rdieter> i suck for not working harder to make akademy this year. :(  work just got a little crazy the past couple of months, a lot less free time for me
15:58:08 * rdieter will be lucky to make flock
15:59:43 <rdieter> #topic open discussion
16:00:02 <rdieter> hour's about over, any final thoughts before we close the meeting?
16:00:38 * heliocastro is changing jobs now
16:00:54 <heliocastro> looking for be back on KDE more often
16:00:56 <heliocastro> and Qt
16:01:33 <rdieter> heliocastro: good to hear, yay.
16:01:40 <Kevin_Kofler> +1, sounds great. :-)
16:02:12 <heliocastro> Just to put you guys up to date about at least Qt Contributors:
16:02:22 <heliocastro> - New html engine coming
16:02:37 <heliocastro> - New Qt Creator 3 all QML oriented
16:03:08 <heliocastro> - Guys from Samsung ( Staniek ) show Tizen Qt
16:03:32 <heliocastro> - Blackberry gave us a Z10 \o/ and they talk about the slow plans on Qt 5
16:03:37 <heliocastro> The phone is full Qt
16:04:08 <Kevin_Kofler> New HTML engine? Instead of QtWebKit?!
16:04:29 <heliocastro> welcome to the brave new world
16:04:42 <heliocastro> This thanks for the google fork
16:05:07 <rdieter> k, thanks for the update
16:05:10 <Kevin_Kofler> Oh, is it based on the Blink/Chromium stuff?
16:05:13 <Kevin_Kofler> Ugh…
16:05:17 <heliocastro> No no
16:05:40 <heliocastro> They not decided yet what they will base
16:06:14 <Kevin_Kofler> Oh joy… "We will replace our HTML engine, which is larger than pretty much anything else in Qt, but we haven't decided yet with what"??? WTF?!
16:06:33 <heliocastro> Wait a minute, don't be so dramatic
16:06:46 <heliocastro> all guys are the webkit guys form Nokia now Digia
16:06:46 * Kevin_Kofler misses the days where HTML in KDE meant KHTML, period.
16:06:53 <heliocastro> And khtml
16:07:03 <heliocastro> They not decided which best fork they will take
16:07:10 <heliocastro> I was in the meeting.
16:07:13 <Kevin_Kofler> (before Apple forked up (pun intended :-) ) everything)
16:09:32 <rdieter> alright, let's wrap, thanks everyone!
16:09:32 <heliocastro> Guys, we'er going out
16:09:37 <rdieter> #endmeeting