Re: Distros and QtWebEngine
Sorry Milian, i've sent it to your personal address by mistake. Resending to the list. On Monday 20 April 2015 23:02:35 you wrote: [snip] Have you notified the Qt WebEngine developers about this? I have not seen any email in that regard to the official upstream mailing list at qtwebengine@qt- project.org . Yes we have, but on the main devel mailing list, developm...@qt-project.org It has been troughly discussed, the thread is actually very long. Previously, many of the 3rd party stuff was just hardcoded and shipped internally because it was easier to get stuff done. At least in Qt (not mentioning the web engines) they have been added to easier the development in platforms that do not have a coherent way to handle system libs (like Windows). They are also quite open to add code to detect and use the system lib when required, and I'm really thankful for that :) Sadly that's not the case with the webengine, read: the part the Qt guys don't code. Now with things settling a bit, afaik one could start working on the build system to use a system- provided version of the 3rd party stuff. Some stuff will probably always be shipped internally, but at least this could help things a bit. In all cases, its sadly sometimes simply not possible to make different FOSS code work together without custom patches for a certain project. Yes, this is against the ideal utopia we all dream of, but with limited man power there will always be problems like this. Actually when it comes to the web engine it's not true. When I suggested to use an external ffmpeg and libv8 (javascript engine) the answer was directly no, simply because they are too entangled to be possible. And ffmpeg tends to be quite a source of CVEs... Regarding debug symbols, it certainly works with ld as others have mentioned. And it is definitely easier to build than QtWebKit. Anyhow, I won't judge distros when they won't package software that is against their principals. But I hope you guys also understand that for some developers a good solution for some people is better than a half baked broken solution for some more people. I'm not a KDE PIM maintainer, but with my KDevelop hat on (that uses a web view to display documentation pages, currently QtWebKit), I could understand a projects decision to just make a certain feature optional. Certainly less maintenance effort than supporting different implementations. Right. And now I know at least you know the implicants of making QtWebEngine a hard (or not) dependency. -- Hiroshima '45, Chernobyl '86, Windows '95. Grafitti en Niceto Vega 5940, Buenos Aires. De una foto de Mario Gallo. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Distros and QtWebEngine
Note that QtQuick Text never uses RichText unless told, AutoText only enables StyledText when it finds something that looks like a tag before the first line break. Originalnachricht Von: Thomas Lübking Gesendet: Montag, 20. April 2015 23:27 An: Jeremy Whiting Cc: kdelibs Betreff: Re: Distros and QtWebEngine On Montag, 20. April 2015 23:00:44 CEST, Jeremy Whiting wrote: Yeah, that's probably a better idea. is there a QML ui for QTextview? or maybe some other QML component that renders html. The Text item defaults textFormat to Text.AutoText - you can enforce Text.RichText or rely on the detection (if it starts w/ html) Cheers, Thomas
Re: Kdebugsettings in kdereview
El Dimarts, 21 d'abril de 2015, a les 14:02:26, laurent Montel va escriure: Le Tuesday 14 April 2015 06:46:14 laurent Montel a écrit : Ok It's in kdereview from the 23 march. Is it ok to move it ? Regards No answer from the 14 april. So I will ask to move it from kde-review to kdeutils. I actually had a reminder in my calendar to say +1 if noone had said so yet, so +1 :D Cheers, Albert Regards
Re: Distros and QtWebEngine
On 2015-04-20, Thomas Lübking thomas.luebk...@gmail.com wrote: You can apply that on really *anything* - the obvious (claimed) failure is Qt breaks somehow Plasma because either a) a client relied on undocumented behavior (client bug) or b) a foundation broke documented API/ABI/Behavior (foundation bug) a) is happening quite a lot. Just look for usages of Qt private headers across our modules. Also your list implies that one never can update KDE, because that breaks GNOME, requires a kernel update and whatnot. No. One can update things, but it is not just update Qt. Unfortunately, I haven't really used my imagination here. That implies the Linux SW stack is crap. Point taken. Or .. fast moving. /Sune
Re: Distros and QtWebEngine
On Monday, April 20, 2015 01:28:59 PM Lisandro Damián Nicanor Pérez Meyer wrote: (I am talking with my openSUSE packager hat on as I am the Chromium packager and am part of the community team that packages KDE/Qt) It embeds quite a lot of 3rd party stuff which we distros don't accept (in different grades depending on the distro) as we require to build using the system versions. Fedora's Rex Dieter tells me that's actually why chromium is not available for them. Isn't this the real main issue with the new QtWebEngine and Chromium itself ?? In the past I have been trying to get Chromium to build using system version of the 3rd party stuff, but this only worked out for some of them. Google didn't just included the 3rd party stuff, but also altered it to their needs and some things never got upstreamed. From what I understood the main reason for Fedora not to provide Chromium is the inclusion of the ffmpeg sources. Fedora is not allowed to provide binaries nor sources that contain stuff that could have legal implications. This was also initially openSUSE's main concern, however the legal department of SUSE accepted having the sourcecode on our BuildSercie, as long as we did not build any codecs from it that could cause these legal issues. This situation will not likely change as that there are old bug reports regarding this situation and they were never resolved. We followed the same approach for QtWebEngine and at the moment we are providing both to our users. Moreover we can't build debugging symbols on most archs due to the enormous amount of RAM+swap it involves in the linking process (more than 8GB last time I checked). This is at least the same as QtWebKit, but seems to be getting worse. Switching to the gold linker would help quite a lot here. At least I am able to build Chromium on armv7l with it :) Regards Raymond
Re: Distros and QtWebEngine
Hey, At the moment there is a discussion in kde-core-devel, that distros won't ship QtWebEngine (at least Debian and Fedora). And ubuntu also will follow the decision of debian. The only part so far, that depends on QtWebEngine in kdepim is KSieveUi::SieveEditorWebView it only shows links like: http://tools.ietf.org/html/rfc5173 (some people said, that these kind of links should be easy to display with a QText*) Regards, sandro -- Am Montag, 20. April 2015, 13:28:59 schrieb Lisandro Damián Nicanor Pérez Meyer: Hi everyone! I'm one of Debian's Qt maintainers and I'm writing here due to the problem that QtWebEngine poses for us distros (in this case, at least Debian and Fedora). I know that kdepim seems to depend on it now. Sadly QtWebEngine it's quite a hard (very hard) piece of software to package. It embeds quite a lot of 3rd party stuff which we distros don't accept (in different grades depending on the distro) as we require to build using the system versions. Fedora's Rex Dieter tells me that's actually why chromium is not available for them. Moreover we can't build debugging symbols on most archs due to the enormous amount of RAM+swap it involves in the linking process (more than 8GB last time I checked). This is at least the same as QtWebKit, but seems to be getting worse. Yes, we do understand that QtWebEngine is technically superior to any other thing out there but making that code an acceptable package is another thing. So basically what I'm trying to say is: don't expect us down streamers to easily package QtWebEngine soon, if we ever get to it. I'm really sorry if this comes as bad news, but the reality is currently this :( -- Sandro Knauß Software Developer Kolab Systems AG Zürich, Switzerland e: kna...@kolabsystems.com t: +41 43 501 66 91 w: https://kolabsystems.com pgp: CE81539E Sandro Knauß signature.asc Description: This is a digitally signed message part.
Re: Distros and QtWebEngine
On Monday 20 April 2015 19:02:40 Lisandro Damián Nicanor Pérez Meyer wrote: Sorry Milian, i've sent it to your personal address by mistake. Resending to the list. On Monday 20 April 2015 23:02:35 you wrote: [snip] Have you notified the Qt WebEngine developers about this? I have not seen any email in that regard to the official upstream mailing list at qtwebengine@qt- project.org . Yes we have, but on the main devel mailing list, developm...@qt-project.org It has been troughly discussed, the thread is actually very long. When did this take place and what is the threads subject? I seem to have missed it, and also can't find it in my recent mails. Sorry for that. Thanks -- Milian Wolff m...@milianw.de http://milianw.de
Re: Distros and QtWebEngine
On Monday 20 April 2015 23:19:22 Luigi Toscano wrote: Milian Wolff ha scritto: I'm not a KDE PIM maintainer, but with my KDevelop hat on (that uses a web view to display documentation pages, currently QtWebKit), kio_man uses khtml (why don't you use it)? But anyway, also khtml is deprecated. On the other side, the html for manpages is pretty basic, and we control the generation - are we sure it can't work with QText* things? Same thing for khelpcenter, I can fix the generated html. I think that sometime the full blown html viewer has been abused, hence my question. I'm not (only) talking about man pages (for which one could argue even a monospace plain-text view could be sufficient). I'm also talking about: a) PHP online documentation b) QtHelp documentation c) Python documentation d) anything else you could conceive All of the above can contain arbitrary HTML and we did have problems before with QTextDocument. I can't remember why we moved away from KHTML, but afaik that was due to bugs and it being more or less unmaintained for ages. Furthermore, since we also displayed Html from within a QML code path at some point, we loaded in QtWebKit anyways. So the real bloat was having multiple HTML engines pulled in. Now, we only have QtWebKit, no KHtml. Bye -- Milian Wolff m...@milianw.de http://milianw.de
Re: Distros and QtWebEngine
These are the days I understand why I use gentoo (despite the headaches it gives me every once in a while). No, I cannot use anything that does not have chromium, whatever the reason may be, sorry. Both sides are right, there is not human labour enough to maintain the stuff, and cutting stuff's quality to keep up with the lack of labour means delivering an inferior product nobody would really use. I cannot see any way out of this. I'll keep building my own stuff as long as I can, but the day there won't be any linux pc desktop any more is getting closer by the minute. It's very much the end of an era. On 21 April 2015 at 09:23, Sandro Knauß kna...@kolabsys.com wrote: Hey, At the moment there is a discussion in kde-core-devel, that distros won't ship QtWebEngine (at least Debian and Fedora). And ubuntu also will follow the decision of debian. The only part so far, that depends on QtWebEngine in kdepim is KSieveUi::SieveEditorWebView it only shows links like: http://tools.ietf.org/html/rfc5173 (some people said, that these kind of links should be easy to display with a QText*) Regards, sandro -- Am Montag, 20. April 2015, 13:28:59 schrieb Lisandro Damián Nicanor Pérez Meyer: Hi everyone! I'm one of Debian's Qt maintainers and I'm writing here due to the problem that QtWebEngine poses for us distros (in this case, at least Debian and Fedora). I know that kdepim seems to depend on it now. Sadly QtWebEngine it's quite a hard (very hard) piece of software to package. It embeds quite a lot of 3rd party stuff which we distros don't accept (in different grades depending on the distro) as we require to build using the system versions. Fedora's Rex Dieter tells me that's actually why chromium is not available for them. Moreover we can't build debugging symbols on most archs due to the enormous amount of RAM+swap it involves in the linking process (more than 8GB last time I checked). This is at least the same as QtWebKit, but seems to be getting worse. Yes, we do understand that QtWebEngine is technically superior to any other thing out there but making that code an acceptable package is another thing. So basically what I'm trying to say is: don't expect us down streamers to easily package QtWebEngine soon, if we ever get to it. I'm really sorry if this comes as bad news, but the reality is currently this :( -- Sandro Knauß Software Developer Kolab Systems AG Zürich, Switzerland e: kna...@kolabsystems.com t: +41 43 501 66 91 w: https://kolabsystems.com pgp: CE81539E Sandro Knauß -- == If Pac-Man had affected us as kids, we'd all be running around in a darkened room munching pills and listening to repetitive music.
Re: Distros and QtWebEngine
Thomas Lübking wrote: I know nothing about the trouble w/ QWebEngine¹, but what is insinuated here is that it's completely unusable, unmaintainable, undistributable - ie. Qt then simply won't have any full blown web engine, resp. has one that nobody uses? That issue would seem -a tiny bit- fr beyond kdepim or anything KDE related, to me those claims read: Qt now has no longer a web kit/engine. That's exactly the problem. I have objected to the QtWebKit deprecation on those exact grounds on the upstream Qt mailing list, but my complaints have fallen on deaf ears. [1] Google more Evil than Apple? WebKit blob trustworthy, but Blink blob [isn't? Arch just rolled that on my disk, am I now tracked or what?!? The main problem is not about the trustworthiness of Chromium itself, but about its bundling of many system libraries. Packages in Fedora and Debian MUST build against the system version of libraries, for many practical reasons: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries That said, Google is a web-centric company and as such more likely to put evil stuff into their browser than Apple. In fact, Chromium and Chrome already have the reputation of hiding spyware (mis)features in their code. Kevin Kofler
Re: Kdebugsettings in kdereview
Le Tuesday 14 April 2015 06:46:14 laurent Montel a écrit : Ok It's in kdereview from the 23 march. Is it ok to move it ? Regards No answer from the 14 april. So I will ask to move it from kde-review to kdeutils. Regards
Re: Distros and QtWebEngine
The thread subject is Deprecating modules with 5.5 on the qt development list. On Tue, Apr 21, 2015 at 1:39 AM, Milian Wolff m...@milianw.de wrote: On Monday 20 April 2015 19:02:40 Lisandro Damián Nicanor Pérez Meyer wrote: Sorry Milian, i've sent it to your personal address by mistake. Resending to the list. On Monday 20 April 2015 23:02:35 you wrote: [snip] Have you notified the Qt WebEngine developers about this? I have not seen any email in that regard to the official upstream mailing list at qtwebengine@qt- project.org . Yes we have, but on the main devel mailing list, developm...@qt-project.org It has been troughly discussed, the thread is actually very long. When did this take place and what is the threads subject? I seem to have missed it, and also can't find it in my recent mails. Sorry for that. Thanks -- Milian Wolff m...@milianw.de http://milianw.de
Re: Kdebugsettings in kdereview
Le Tuesday 21 April 2015 19:54:39 Albert Astals Cid a écrit : El Dimarts, 21 d'abril de 2015, a les 14:02:26, laurent Montel va escriure: Le Tuesday 14 April 2015 06:46:14 laurent Montel a écrit : Ok It's in kdereview from the 23 march. Is it ok to move it ? Regards No answer from the 14 april. So I will ask to move it from kde-review to kdeutils. I actually had a reminder in my calendar to say +1 if noone had said so yet, so +1 :D Great :) Thanks Regards Cheers, Albert Regards -- Laurent Montel | laurent.mon...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr
Re: branchGroup stable-qt4 Compile failures. Need dev assistance please.
On Tue, Apr 21, 2015 at 10:45 PM, Scarlett Clark sgcl...@kubuntu.org wrote: kaccount-integration: https://build-sandbox.kde.org/job/kaccounts-integration%20stable%20stable-qt4/PLATFORM=Linux,compiler=gcc/19/console There is no kaccounts-integration kde4/qt4 version and should not be. I've removed it from kde-build-metadata, please discard this job. Cheers -- Martin Klapetek | KDE Developer
Re: branchGroup stable-qt4 Compile failures. Need dev assistance please.
On Tuesday 21 April 2015 13:45:06 Scarlett Clark wrote: kdev-crossfire: https://build-sandbox.kde.org/job/kdev-crossfire%20master%20stable-qt4/PLATF ORM=Linux,compiler=gcc/11/ kdev-php-formatter: https://build-sandbox.kde.org/job/kdev-php-formatter%20master%20stable-qt4/P LATFORM=Linux,compiler=gcc/10/console kdev-xtest: https://build-sandbox.kde.org/view/branchGroup%20stable-qt4/job/kdev-xtest%2 0master%20stable-qt4/PLATFORM=Linux,compiler=gcc/11/console All of the above are unmaintained and should not run through CI until someone spends time on fixing their issues. They are all in playground as well. kdev-css: https://build-sandbox.kde.org/job/kdev-css%201.7%20stable-qt4/PLATFORM=Linux ,compiler=gcc/5/console This one was easy and I fixed it. But in general, I don't think that adding all playground projects to the CI is a good idea, as many things in there are just historic artifacts. Bye -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
Re: Review Request 123458: Improvements to the handling of font weights and styles
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123458/ --- (Updated April 22, 2015, 12:01 a.m.) Review request for KDE Software on Mac OS X and Qt KDE. Repository: qt Description --- Handling of and support for less common font weight/style combinations is far from ideal on OS X but not perfect on Linux either. It is not difficult to run into typefaces that will not be restored properly from settings files for instance, because QFont(family,weight,style) and other methods to obtain a QFont from a font description do not return the appropriate font. This is especially the case on OS X where the code makes the assumption in at least two locations that anything that isn't Normal is Bold. In other places, including generic code, parsers apply overly course numberic weight classifications or fail to consider weights like Medium, Semibold, Regular, Roman etc. (and return a fall-back weight: Normal). Among the font families that are affected there are als common fonts like Segoe UI and Helvetica Neue (UI fonts on MS Windows and OS X 10.10+). NB: medium/semi-/demi-bold weights are perfect in UIs on high-resolution screens. The proposed patch improves the code by adding additional checks against style names and weights. The changes are not only to Mac-specific files so Linux benefits from this too (and other platforms ought to, as well). I'm putting it up for review on here mainly for lack of time to figure out why I failed to get in onto Qt's own code review site. It may appear there too, but if not: I herewith put the attached code changes in the public domain, for possible inclusion into the Qt 4.x codebase under the license that governs that software. Diffs (updated) - src/gui/dialogs/qfontdialog.cpp d791462 src/gui/dialogs/qfontdialog_mac.mm d557a7a src/gui/kernel/qt_mac.cpp fb241ce src/gui/text/qfontdatabase.cpp 4c2ace4 src/gui/text/qfontdatabase_mac.cpp 816a7bd src/gui/text/qfontengine_coretext.mm 204d685 src/plugins/platforms/fontdatabases/coretext/qcoretextfontdatabase.mm 312015f tools/qtconfig/mainwindow.cpp 1bb6e4e Diff: https://git.reviewboard.kde.org/r/123458/diff/ Testing --- On OS X 10.9.5 and Kubuntu 14.04.2 against Qt 4.8.7 with the qtconfig utility and the attached test application File Attachments fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/bbebc0af-e457-4fdf-965c-3918d8e871d0__fontweightissue.pro fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/cfdcbf23-406a-4abf-b0cb-5fdc1957dfe9__main.cpp fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/9898afae-82ca-4c92-b7d9-5607d0dd8e24__dialog.h fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/8ad258bf-7f82-4db4-a344-ce81d75e8c50__dialog.cpp fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/2f0a7c6e-4601-406e-b703-603a36bff62b__fontweightissue.desktop Thanks, René J.V. Bertin
Re: Review Request 123458: Improvements to the handling of font weights and styles
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123458/ --- (Updated April 22, 2015, 12:06 a.m.) Review request for KDE Software on Mac OS X and Qt KDE. Repository: qt Description --- Handling of and support for less common font weight/style combinations is far from ideal on OS X but not perfect on Linux either. It is not difficult to run into typefaces that will not be restored properly from settings files for instance, because QFont(family,weight,style) and other methods to obtain a QFont from a font description do not return the appropriate font. This is especially the case on OS X where the code makes the assumption in at least two locations that anything that isn't Normal is Bold. In other places, including generic code, parsers apply overly course numberic weight classifications or fail to consider weights like Medium, Semibold, Regular, Roman etc. (and return a fall-back weight: Normal). Among the font families that are affected there are als common fonts like Segoe UI and Helvetica Neue (UI fonts on MS Windows and OS X 10.10+). NB: medium/semi-/demi-bold weights are perfect in UIs on high-resolution screens. The proposed patch improves the code by adding additional checks against style names and weights. The changes are not only to Mac-specific files so Linux benefits from this too (and other platforms ought to, as well). I'm putting it up for review on here mainly for lack of time to figure out why I failed to get in onto Qt's own code review site. It may appear there too, but if not: I herewith put the attached code changes in the public domain, for possible inclusion into the Qt 4.x codebase under the license that governs that software. Diffs (updated) - src/gui/dialogs/qfontdialog.cpp d791462 src/gui/dialogs/qfontdialog_mac.mm d557a7a src/gui/kernel/qt_mac.cpp fb241ce src/gui/text/qfontdatabase.cpp 4c2ace4 src/gui/text/qfontdatabase_mac.cpp 816a7bd src/gui/text/qfontengine_coretext.mm 204d685 src/plugins/platforms/fontdatabases/coretext/qcoretextfontdatabase.mm 312015f tools/qtconfig/mainwindow.cpp 1bb6e4e Diff: https://git.reviewboard.kde.org/r/123458/diff/ Testing --- On OS X 10.9.5 and Kubuntu 14.04.2 against Qt 4.8.7 with the qtconfig utility and the attached test application File Attachments fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/bbebc0af-e457-4fdf-965c-3918d8e871d0__fontweightissue.pro fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/cfdcbf23-406a-4abf-b0cb-5fdc1957dfe9__main.cpp fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/9898afae-82ca-4c92-b7d9-5607d0dd8e24__dialog.h fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/8ad258bf-7f82-4db4-a344-ce81d75e8c50__dialog.cpp fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/2f0a7c6e-4601-406e-b703-603a36bff62b__fontweightissue.desktop Thanks, René J.V. Bertin
Re: branchGroup stable-qt4 Compile failures. Need dev assistance please.
El Dimarts, 21 d'abril de 2015, a les 23:42:36, Milian Wolff va escriure: On Tuesday 21 April 2015 13:45:06 Scarlett Clark wrote: kdev-crossfire: https://build-sandbox.kde.org/job/kdev-crossfire%20master%20stable-qt4/PLA TF ORM=Linux,compiler=gcc/11/ kdev-php-formatter: https://build-sandbox.kde.org/job/kdev-php-formatter%20master%20stable-qt4 /P LATFORM=Linux,compiler=gcc/10/console kdev-xtest: https://build-sandbox.kde.org/view/branchGroup%20stable-qt4/job/kdev-xtest %2 0master%20stable-qt4/PLATFORM=Linux,compiler=gcc/11/console All of the above are unmaintained and should not run through CI until someone spends time on fixing their issues. They are all in playground as well. kdev-css: https://build-sandbox.kde.org/job/kdev-css%201.7%20stable-qt4/PLATFORM=Lin ux ,compiler=gcc/5/console This one was easy and I fixed it. But in general, I don't think that adding all playground projects to the CI is a good idea, as many things in there are just historic artifacts. What we need is someone with some time to apply the life cycle policy and move those historic artifacts to unmaintained :) Cheers, Albert Bye signature.asc Description: This is a digitally signed message part.
branchGroup stable-qt4 Compile failures. Need dev assistance please.
I know this is an external depend, but I have no experience with it. Can maybe a calligra dev take a look, as they need it. VC https://build-sandbox.kde.org/job/vc%20master%20stable-qt4/PLATFORM=Linux,compiler=gcc/2/console With that said: Calligra: (probably vc) https://build-sandbox.kde.org/view/branchGroup%20stable-qt4/job/calligra%20calligra-2.9%20stable-qt4/10/ k3b: Found Kcddb: but fails on include file: https://build-sandbox.kde.org/job/k3b%202.0%20stable-qt4/PLATFORM=Linux,compiler=gcc/14/console kamoso: https://build-sandbox.kde.org/job/kamoso%202.1%20stable-qt4/PLATFORM=Linux,compiler=gcc/12/console kdeconnect-kde: fails to find qjson header. I brought it in as a dep but I don't think it actually looks for it because it still fails (and not listed in the configure section). https://build-sandbox.kde.org/job/kdeconnect-kde%20kde4%20stable-qt4/PLATFORM=Linux,compiler=gcc/13/console kdenlive: Please tell me the correct qt4 branches. The ones in LMS were kf5 builds. kaccount-integration: https://build-sandbox.kde.org/job/kaccounts-integration%20stable%20stable-qt4/PLATFORM=Linux,compiler=gcc/19/console kdepim: can't find the supplied grantlee https://build-sandbox.kde.org/job/kdepim%20KDE-4.14%20stable-qt4/PLATFORM=Linux,compiler=gcc/12/console kdev-crossfire: https://build-sandbox.kde.org/job/kdev-crossfire%20master%20stable-qt4/PLATFORM=Linux,compiler=gcc/11/ kdev-css: https://build-sandbox.kde.org/job/kdev-css%201.7%20stable-qt4/PLATFORM=Linux,compiler=gcc/5/console kdev-php-formatter: https://build-sandbox.kde.org/job/kdev-php-formatter%20master%20stable-qt4/PLATFORM=Linux,compiler=gcc/10/console kdev-xtest: https://build-sandbox.kde.org/view/branchGroup%20stable-qt4/job/kdev-xtest%20master%20stable-qt4/PLATFORM=Linux,compiler=gcc/11/console kstars: https://build-sandbox.kde.org/job/kstars%20Applications-14.12%20stable-qt4/PLATFORM=Linux,compiler=gcc/11/console Thanks, Scarlett signature.asc Description: This is a digitally signed message part.
Re: Review Request 123458: Improvements to the handling of font weights and styles
On April 22, 2015, 12:40 a.m., Luigi Toscano wrote: I think this should go to Qt (I think it's quite difficult they will accept it, as Qt4 is in hard freeze mode), and they will probably ask to see if it applies to Qt5 as well. We just mirror Qt... not sure how to handle this. Yes, I know you wrote that it should go to Qt, just stating that I'm not sure how to handle this patch in our Qt mirrors. - Luigi --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123458/#review79313 --- On April 22, 2015, 12:06 a.m., René J.V. Bertin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123458/ --- (Updated April 22, 2015, 12:06 a.m.) Review request for KDE Software on Mac OS X and Qt KDE. Repository: qt Description --- Handling of and support for less common font weight/style combinations is far from ideal on OS X but not perfect on Linux either. It is not difficult to run into typefaces that will not be restored properly from settings files for instance, because QFont(family,weight,style) and other methods to obtain a QFont from a font description do not return the appropriate font. This is especially the case on OS X where the code makes the assumption in at least two locations that anything that isn't Normal is Bold. In other places, including generic code, parsers apply overly course numberic weight classifications or fail to consider weights like Medium, Semibold, Regular, Roman etc. (and return a fall-back weight: Normal). Among the font families that are affected there are als common fonts like Segoe UI and Helvetica Neue (UI fonts on MS Windows and OS X 10.10+). NB: medium/semi-/demi-bold weights are perfect in UIs on high-resolution screens. The proposed patch improves the code by adding additional checks against style names and weights. The changes are not only to Mac-specific files so Linux benefits from this too (and other platforms ought to, as well). I'm putting it up for review on here mainly for lack of time to figure out why I failed to get in onto Qt's own code review site. It may appear there too, but if not: I herewith put the attached code changes in the public domain, for possible inclusion into the Qt 4.x codebase under the license that governs that software. Diffs - src/gui/dialogs/qfontdialog.cpp d791462 src/gui/dialogs/qfontdialog_mac.mm d557a7a src/gui/kernel/qt_mac.cpp fb241ce src/gui/text/qfontdatabase.cpp 4c2ace4 src/gui/text/qfontdatabase_mac.cpp 816a7bd src/gui/text/qfontengine_coretext.mm 204d685 src/plugins/platforms/fontdatabases/coretext/qcoretextfontdatabase.mm 312015f tools/qtconfig/mainwindow.cpp 1bb6e4e Diff: https://git.reviewboard.kde.org/r/123458/diff/ Testing --- On OS X 10.9.5 and Kubuntu 14.04.2 against Qt 4.8.7 with the qtconfig utility and the attached test application File Attachments fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/bbebc0af-e457-4fdf-965c-3918d8e871d0__fontweightissue.pro fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/cfdcbf23-406a-4abf-b0cb-5fdc1957dfe9__main.cpp fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/9898afae-82ca-4c92-b7d9-5607d0dd8e24__dialog.h fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/8ad258bf-7f82-4db4-a344-ce81d75e8c50__dialog.cpp fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/2f0a7c6e-4601-406e-b703-603a36bff62b__fontweightissue.desktop Thanks, René J.V. Bertin
Re: Review Request 123458: Improvements to the handling of font weights and styles
On April 21, 2015, 10:40 p.m., Luigi Toscano wrote: I think this should go to Qt (I think it's quite difficult they will accept it, as Qt4 is in hard freeze mode), and they will probably ask to see if it applies to Qt5 as well. We just mirror Qt... not sure how to handle this. Luigi Toscano wrote: Yes, I know you wrote that it should go to Qt, just stating that I'm not sure how to handle this patch in our Qt mirrors. Aleix Pol Gonzalez wrote: +1, we shouldn't go about maintaining a patched Qt4 fork. Our Qt mirrors are configured to be exact copies of the upstream code.qt.io mirrors, therefore any patches have to go through Qt Project to form part of our mirrors of it. - Ben --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123458/#review79313 --- On April 21, 2015, 10:06 p.m., René J.V. Bertin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123458/ --- (Updated April 21, 2015, 10:06 p.m.) Review request for KDE Software on Mac OS X and Qt KDE. Repository: qt Description --- Handling of and support for less common font weight/style combinations is far from ideal on OS X but not perfect on Linux either. It is not difficult to run into typefaces that will not be restored properly from settings files for instance, because QFont(family,weight,style) and other methods to obtain a QFont from a font description do not return the appropriate font. This is especially the case on OS X where the code makes the assumption in at least two locations that anything that isn't Normal is Bold. In other places, including generic code, parsers apply overly course numberic weight classifications or fail to consider weights like Medium, Semibold, Regular, Roman etc. (and return a fall-back weight: Normal). Among the font families that are affected there are als common fonts like Segoe UI and Helvetica Neue (UI fonts on MS Windows and OS X 10.10+). NB: medium/semi-/demi-bold weights are perfect in UIs on high-resolution screens. The proposed patch improves the code by adding additional checks against style names and weights. The changes are not only to Mac-specific files so Linux benefits from this too (and other platforms ought to, as well). I'm putting it up for review on here mainly for lack of time to figure out why I failed to get in onto Qt's own code review site. It may appear there too, but if not: I herewith put the attached code changes in the public domain, for possible inclusion into the Qt 4.x codebase under the license that governs that software. Diffs - src/gui/dialogs/qfontdialog.cpp d791462 src/gui/dialogs/qfontdialog_mac.mm d557a7a src/gui/kernel/qt_mac.cpp fb241ce src/gui/text/qfontdatabase.cpp 4c2ace4 src/gui/text/qfontdatabase_mac.cpp 816a7bd src/gui/text/qfontengine_coretext.mm 204d685 src/plugins/platforms/fontdatabases/coretext/qcoretextfontdatabase.mm 312015f tools/qtconfig/mainwindow.cpp 1bb6e4e Diff: https://git.reviewboard.kde.org/r/123458/diff/ Testing --- On OS X 10.9.5 and Kubuntu 14.04.2 against Qt 4.8.7 with the qtconfig utility and the attached test application File Attachments fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/bbebc0af-e457-4fdf-965c-3918d8e871d0__fontweightissue.pro fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/cfdcbf23-406a-4abf-b0cb-5fdc1957dfe9__main.cpp fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/9898afae-82ca-4c92-b7d9-5607d0dd8e24__dialog.h fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/8ad258bf-7f82-4db4-a344-ce81d75e8c50__dialog.cpp fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/2f0a7c6e-4601-406e-b703-603a36bff62b__fontweightissue.desktop Thanks, René J.V. Bertin
Re: Review Request 123458: Improvements to the handling of font weights and styles
On April 22, 2015, 12:40 a.m., Luigi Toscano wrote: I think this should go to Qt (I think it's quite difficult they will accept it, as Qt4 is in hard freeze mode), and they will probably ask to see if it applies to Qt5 as well. We just mirror Qt... not sure how to handle this. Luigi Toscano wrote: Yes, I know you wrote that it should go to Qt, just stating that I'm not sure how to handle this patch in our Qt mirrors. Aleix Pol Gonzalez wrote: +1, we shouldn't go about maintaining a patched Qt4 fork. Ben Cooksley wrote: Our Qt mirrors are configured to be exact copies of the upstream code.qt.io mirrors, therefore any patches have to go through Qt Project to form part of our mirrors of it. It didn't even cross my mind to commit this patch to the Qt4 fork, just to put it up for review (and make it available publicly). Oh, and if someone were to beat me to putting this up on Qt's code review site, I'd actually appreciate that, a lot even O:-) - René J.V. --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123458/#review79313 --- On April 22, 2015, 12:06 a.m., René J.V. Bertin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123458/ --- (Updated April 22, 2015, 12:06 a.m.) Review request for KDE Software on Mac OS X and Qt KDE. Repository: qt Description --- Handling of and support for less common font weight/style combinations is far from ideal on OS X but not perfect on Linux either. It is not difficult to run into typefaces that will not be restored properly from settings files for instance, because QFont(family,weight,style) and other methods to obtain a QFont from a font description do not return the appropriate font. This is especially the case on OS X where the code makes the assumption in at least two locations that anything that isn't Normal is Bold. In other places, including generic code, parsers apply overly course numberic weight classifications or fail to consider weights like Medium, Semibold, Regular, Roman etc. (and return a fall-back weight: Normal). Among the font families that are affected there are als common fonts like Segoe UI and Helvetica Neue (UI fonts on MS Windows and OS X 10.10+). NB: medium/semi-/demi-bold weights are perfect in UIs on high-resolution screens. The proposed patch improves the code by adding additional checks against style names and weights. The changes are not only to Mac-specific files so Linux benefits from this too (and other platforms ought to, as well). I'm putting it up for review on here mainly for lack of time to figure out why I failed to get in onto Qt's own code review site. It may appear there too, but if not: I herewith put the attached code changes in the public domain, for possible inclusion into the Qt 4.x codebase under the license that governs that software. Diffs - src/gui/dialogs/qfontdialog.cpp d791462 src/gui/dialogs/qfontdialog_mac.mm d557a7a src/gui/kernel/qt_mac.cpp fb241ce src/gui/text/qfontdatabase.cpp 4c2ace4 src/gui/text/qfontdatabase_mac.cpp 816a7bd src/gui/text/qfontengine_coretext.mm 204d685 src/plugins/platforms/fontdatabases/coretext/qcoretextfontdatabase.mm 312015f tools/qtconfig/mainwindow.cpp 1bb6e4e Diff: https://git.reviewboard.kde.org/r/123458/diff/ Testing --- On OS X 10.9.5 and Kubuntu 14.04.2 against Qt 4.8.7 with the qtconfig utility and the attached test application File Attachments fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/bbebc0af-e457-4fdf-965c-3918d8e871d0__fontweightissue.pro fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/cfdcbf23-406a-4abf-b0cb-5fdc1957dfe9__main.cpp fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/9898afae-82ca-4c92-b7d9-5607d0dd8e24__dialog.h fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/8ad258bf-7f82-4db4-a344-ce81d75e8c50__dialog.cpp fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/2f0a7c6e-4601-406e-b703-603a36bff62b__fontweightissue.desktop Thanks, René J.V. Bertin
latest-QT4 compile failures
Of course my previous email those that failed in stable failed here too. A big thank you to those that got fixed. latest compile failures: apper: https://build-sandbox.kde.org/job/apper%20master%20latest-qt4/PLATFORM=Linux,compiler=gcc/24/console choqok: This is likely because qoauth installs into lib64 and I cannot convince it otherwise. (this also affects kf5 builds too) https://build-sandbox.kde.org/job/choqok%201.0%20latest-qt4/PLATFORM=Linux,compiler=gcc/2/console dolphin-plugins: https://build-sandbox.kde.org/job/dolphin-plugins%20master%20latest-qt4/PLATFORM=Linux,compiler=gcc/17/console kdepim: can't find the grantlee bright in. https://build-sandbox.kde.org/job/kdepim%20KDE-4.14%20latest-qt4/PLATFORM=Linux,compiler=gcc/15/console Thanks, Scarlett signature.asc Description: This is a digitally signed message part.
Re: branchGroup stable-qt4 Compile failures. Need dev assistance please.
On 04/21/2015 03:08 PM, Albert Astals Cid wrote: El Dimarts, 21 d'abril de 2015, a les 23:42:36, Milian Wolff va escriure: On Tuesday 21 April 2015 13:45:06 Scarlett Clark wrote: kdev-crossfire: https://build-sandbox.kde.org/job/kdev-crossfire%20master%20stable-qt4/PLA TF ORM=Linux,compiler=gcc/11/ kdev-php-formatter: https://build-sandbox.kde.org/job/kdev-php-formatter%20master%20stable-qt4 /P LATFORM=Linux,compiler=gcc/10/console kdev-xtest: https://build-sandbox.kde.org/view/branchGroup%20stable-qt4/job/kdev-xtest %2 0master%20stable-qt4/PLATFORM=Linux,compiler=gcc/11/console All of the above are unmaintained and should not run through CI until someone spends time on fixing their issues. They are all in playground as well. kdev-css: https://build-sandbox.kde.org/job/kdev-css%201.7%20stable-qt4/PLATFORM=Lin ux ,compiler=gcc/5/console This one was easy and I fixed it. But in general, I don't think that adding all playground projects to the CI is a good idea, as many things in there are just historic artifacts. What we need is someone with some time to apply the life cycle policy and move those historic artifacts to unmaintained :) Cheers, Albert I have removed them from my job list, they probably should go through the above process pointed out by Albert. Scarlett Bye
Re: Review Request 123458: Improvements to the handling of font weights and styles
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123458/#review79313 --- I think this should go to Qt (I think it's quite difficult they will accept it, as Qt4 is in hard freeze mode), and they will probably ask to see if it applies to Qt5 as well. We just mirror Qt... not sure how to handle this. - Luigi Toscano On April 22, 2015, 12:06 a.m., René J.V. Bertin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123458/ --- (Updated April 22, 2015, 12:06 a.m.) Review request for KDE Software on Mac OS X and Qt KDE. Repository: qt Description --- Handling of and support for less common font weight/style combinations is far from ideal on OS X but not perfect on Linux either. It is not difficult to run into typefaces that will not be restored properly from settings files for instance, because QFont(family,weight,style) and other methods to obtain a QFont from a font description do not return the appropriate font. This is especially the case on OS X where the code makes the assumption in at least two locations that anything that isn't Normal is Bold. In other places, including generic code, parsers apply overly course numberic weight classifications or fail to consider weights like Medium, Semibold, Regular, Roman etc. (and return a fall-back weight: Normal). Among the font families that are affected there are als common fonts like Segoe UI and Helvetica Neue (UI fonts on MS Windows and OS X 10.10+). NB: medium/semi-/demi-bold weights are perfect in UIs on high-resolution screens. The proposed patch improves the code by adding additional checks against style names and weights. The changes are not only to Mac-specific files so Linux benefits from this too (and other platforms ought to, as well). I'm putting it up for review on here mainly for lack of time to figure out why I failed to get in onto Qt's own code review site. It may appear there too, but if not: I herewith put the attached code changes in the public domain, for possible inclusion into the Qt 4.x codebase under the license that governs that software. Diffs - src/gui/dialogs/qfontdialog.cpp d791462 src/gui/dialogs/qfontdialog_mac.mm d557a7a src/gui/kernel/qt_mac.cpp fb241ce src/gui/text/qfontdatabase.cpp 4c2ace4 src/gui/text/qfontdatabase_mac.cpp 816a7bd src/gui/text/qfontengine_coretext.mm 204d685 src/plugins/platforms/fontdatabases/coretext/qcoretextfontdatabase.mm 312015f tools/qtconfig/mainwindow.cpp 1bb6e4e Diff: https://git.reviewboard.kde.org/r/123458/diff/ Testing --- On OS X 10.9.5 and Kubuntu 14.04.2 against Qt 4.8.7 with the qtconfig utility and the attached test application File Attachments fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/bbebc0af-e457-4fdf-965c-3918d8e871d0__fontweightissue.pro fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/cfdcbf23-406a-4abf-b0cb-5fdc1957dfe9__main.cpp fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/9898afae-82ca-4c92-b7d9-5607d0dd8e24__dialog.h fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/8ad258bf-7f82-4db4-a344-ce81d75e8c50__dialog.cpp fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/2f0a7c6e-4601-406e-b703-603a36bff62b__fontweightissue.desktop Thanks, René J.V. Bertin
Re: Review Request 123458: Improvements to the handling of font weights and styles
On April 22, 2015, 12:40 a.m., Luigi Toscano wrote: I think this should go to Qt (I think it's quite difficult they will accept it, as Qt4 is in hard freeze mode), and they will probably ask to see if it applies to Qt5 as well. We just mirror Qt... not sure how to handle this. Luigi Toscano wrote: Yes, I know you wrote that it should go to Qt, just stating that I'm not sure how to handle this patch in our Qt mirrors. +1, we shouldn't go about maintaining a patched Qt4 fork. - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123458/#review79313 --- On April 22, 2015, 12:06 a.m., René J.V. Bertin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123458/ --- (Updated April 22, 2015, 12:06 a.m.) Review request for KDE Software on Mac OS X and Qt KDE. Repository: qt Description --- Handling of and support for less common font weight/style combinations is far from ideal on OS X but not perfect on Linux either. It is not difficult to run into typefaces that will not be restored properly from settings files for instance, because QFont(family,weight,style) and other methods to obtain a QFont from a font description do not return the appropriate font. This is especially the case on OS X where the code makes the assumption in at least two locations that anything that isn't Normal is Bold. In other places, including generic code, parsers apply overly course numberic weight classifications or fail to consider weights like Medium, Semibold, Regular, Roman etc. (and return a fall-back weight: Normal). Among the font families that are affected there are als common fonts like Segoe UI and Helvetica Neue (UI fonts on MS Windows and OS X 10.10+). NB: medium/semi-/demi-bold weights are perfect in UIs on high-resolution screens. The proposed patch improves the code by adding additional checks against style names and weights. The changes are not only to Mac-specific files so Linux benefits from this too (and other platforms ought to, as well). I'm putting it up for review on here mainly for lack of time to figure out why I failed to get in onto Qt's own code review site. It may appear there too, but if not: I herewith put the attached code changes in the public domain, for possible inclusion into the Qt 4.x codebase under the license that governs that software. Diffs - src/gui/dialogs/qfontdialog.cpp d791462 src/gui/dialogs/qfontdialog_mac.mm d557a7a src/gui/kernel/qt_mac.cpp fb241ce src/gui/text/qfontdatabase.cpp 4c2ace4 src/gui/text/qfontdatabase_mac.cpp 816a7bd src/gui/text/qfontengine_coretext.mm 204d685 src/plugins/platforms/fontdatabases/coretext/qcoretextfontdatabase.mm 312015f tools/qtconfig/mainwindow.cpp 1bb6e4e Diff: https://git.reviewboard.kde.org/r/123458/diff/ Testing --- On OS X 10.9.5 and Kubuntu 14.04.2 against Qt 4.8.7 with the qtconfig utility and the attached test application File Attachments fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/bbebc0af-e457-4fdf-965c-3918d8e871d0__fontweightissue.pro fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/cfdcbf23-406a-4abf-b0cb-5fdc1957dfe9__main.cpp fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/9898afae-82ca-4c92-b7d9-5607d0dd8e24__dialog.h fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/8ad258bf-7f82-4db4-a344-ce81d75e8c50__dialog.cpp fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/2f0a7c6e-4601-406e-b703-603a36bff62b__fontweightissue.desktop Thanks, René J.V. Bertin
Re: Distros and QtWebEngine
On 04/20/2015 08:17 PM, Albert Astals Cid wrote: IMHO the duty of a distro is providing software to their users to use But not under any circumstance: Enforcing some level of hygiene and quality in the software provided is a service rendered in my interest and protects me as a user. A lot of good has come from Debian forcing projects to play nice with others. Cheers, Albert Cheers, Eike
Re: Distros and QtWebEngine
Raymond Wooninck wrote: Isn't this the real main issue with the new QtWebEngine and Chromium itself ?? In the past I have been trying to get Chromium to build using system version of the 3rd party stuff, but this only worked out for some of them. Google didn't just included the 3rd party stuff, but also altered it to their needs and some things never got upstreamed. Yes, this is the main issue, for both Fedora and Debian. From what I understood the main reason for Fedora not to provide Chromium is the inclusion of the ffmpeg sources. Fedora is not allowed to provide binaries nor sources that contain stuff that could have legal implications. This was also initially openSUSE's main concern, however the legal department of SUSE accepted having the sourcecode on our BuildSercie, as long as we did not build any codecs from it that could cause these legal issues. This is also a concern, but it could be fixed the same way as for other affected packages, by ripping out the encumbered source code from the tarball. That said, having maintained such a cleaning script for xine-lib for a while, I am not looking forward to trying to clean FFmpeg that way (FFmpeg is not in Fedora at all at this time; for some other packages that bundle FFmpeg, we rm -rf the entire FFmpeg, but that is not doable for Chromium/QtWebEngine), and the bundling of the forked FFmpeg is also against Fedora policies to begin with. This situation will not likely change as that there are old bug reports regarding this situation and they were never resolved. And this is exactly why we urge KDE to not require QtWebEngine for anything. Kevin Kofler
Re: Distros and QtWebEngine
On Tuesday 21 April 2015 15:44:35 Kevin Kofler wrote: Thomas Lübking wrote: I know nothing about the trouble w/ QWebEngine¹, but what is insinuated here is that it's completely unusable, unmaintainable, undistributable - ie. Qt then simply won't have any full blown web engine, resp. has one that nobody uses? That issue would seem -a tiny bit- fr beyond kdepim or anything KDE related, to me those claims read: Qt now has no longer a web kit/engine. That's exactly the problem. I have objected to the QtWebKit deprecation on those exact grounds on the upstream Qt mailing list, but my complaints have fallen on deaf ears. I think that's not a fair characterisation that they fell on deaf ears. They were heard, but it's simply a matter of fact that WebKit is no longer a possible target, since Apple removed the necessary bits out of WebKit and they're a much harder group to work with than Google. So it's simply not an option to continue to develop WebKit. If someone has 100 full-time developers to spare, I'm sure un-deprecation could happen. (I'm not exaggerating) That said, Google is a web-centric company and as such more likely to put evil stuff into their browser than Apple. In fact, Chromium and Chrome already have the reputation of hiding spyware (mis)features in their code. I'm not sure about spyware, but they do have a history of inserting things of theirs, like the HTTP-over-QUIC they recently talked about. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Review Request 123458: Improvements to the handling of font weights and styles
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123458/ --- Review request for KDE Software on Mac OS X and Qt KDE. Repository: qt Description --- Handling of and support for less common font weight/style combinations is far from ideal on OS X but not perfect on Linux either. It is not difficult to run into typefaces that will not be restored properly from settings files for instance, because QFont(family,weight,style) and other methods to obtain a QFont from a font description do not return the appropriate font. This is especially the case on OS X where the code makes the assumption in at least two locations that anything that isn't Normal is Bold. In other places, including generic code, parsers apply overly course numberic weight classifications or fail to consider weights like Medium, Semibold, Regular, Roman etc. (and return a fall-back weight: Normal). Among the font families that are affected there are als common fonts like Segoe UI and Helvetica Neue (UI fonts on MS Windows and OS X 10.10+). NB: medium/semi-/demi-bold weights are perfect in UIs on high-resolution screens. The proposed patch improves the code by adding additional checks against style names and weights. The changes are not only to Mac-specific files so Linux benefits from this too (and other platforms ought to, as well). I'm putting it up for review on here mainly for lack of time to figure out why I failed to get in onto Qt's own code review site. It may appear there too, but if not: I herewith put the attached code changes in the public domain, for possible inclusion into the Qt 4.x codebase under the license that governs that software. Diffs - src/gui/dialogs/qfontdialog.cpp d791462 src/gui/dialogs/qfontdialog_mac.mm d557a7a src/gui/kernel/qt_mac.cpp fb241ce src/gui/text/qfontdatabase.cpp 4c2ace4 src/gui/text/qfontdatabase_mac.cpp 816a7bd src/gui/text/qfontengine_coretext.mm 204d685 src/plugins/platforms/fontdatabases/coretext/qcoretextfontdatabase.mm 312015f tools/qtconfig/mainwindow.cpp 1bb6e4e Diff: https://git.reviewboard.kde.org/r/123458/diff/ Testing --- On OS X 10.9.5 and Kubuntu 14.04.2 against Qt 4.8.7 with the qtconfig utility and the attached test application File Attachments fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/bbebc0af-e457-4fdf-965c-3918d8e871d0__fontweightissue.pro fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/cfdcbf23-406a-4abf-b0cb-5fdc1957dfe9__main.cpp fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/9898afae-82ca-4c92-b7d9-5607d0dd8e24__dialog.h fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/8ad258bf-7f82-4db4-a344-ce81d75e8c50__dialog.cpp fontweight issue test application https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/2f0a7c6e-4601-406e-b703-603a36bff62b__fontweightissue.desktop Thanks, René J.V. Bertin
Re: branchGroup stable-qt4 Compile failures. Need dev assistance please.
On 04/21/2015 02:42 PM, Milian Wolff wrote: On Tuesday 21 April 2015 13:45:06 Scarlett Clark wrote: kdev-crossfire: https://build-sandbox.kde.org/job/kdev-crossfire%20master%20stable-qt4/PLATF ORM=Linux,compiler=gcc/11/ kdev-php-formatter: https://build-sandbox.kde.org/job/kdev-php-formatter%20master%20stable-qt4/P LATFORM=Linux,compiler=gcc/10/console kdev-xtest: https://build-sandbox.kde.org/view/branchGroup%20stable-qt4/job/kdev-xtest%2 0master%20stable-qt4/PLATFORM=Linux,compiler=gcc/11/console All of the above are unmaintained and should not run through CI until someone spends time on fixing their issues. They are all in playground as well. kdev-css: https://build-sandbox.kde.org/job/kdev-css%201.7%20stable-qt4/PLATFORM=Linux ,compiler=gcc/5/console This one was easy and I fixed it. But in general, I don't think that adding all playground projects to the CI is a good idea, as many things in there are just historic artifacts. Bye Hi, thanks for fixing that. I do not make the call on what goes in the CI. Everything kde-build-metadata/logical-module-structure will land in CI. Thanks, Scarlett
Re: Distros and QtWebEngine
Lisandro Damián Nicanor Pérez Meyer wrote: Actually when it comes to the web engine it's not true. When I suggested to use an external ffmpeg and libv8 (javascript engine) the answer was directly no, simply because they are too entangled to be possible. And ffmpeg tends to be quite a source of CVEs... Not to mention that we want our web browsers to not use FFmpeg at all (at least not directly), but GStreamer 1. Sadly, due to how deeply FFmpeg is entangled into Chromium, this does not look realistic for QtWebEngine. Using GStreamer would mean that we could ship it only with unencumbered codecs while still allowing our users to easily add patent-encumbered codecs, the same codecs would work for all applications, and there would also be an automated plugin installation mechanism. Chromium's hardcoded use of a forked FFmpeg breaks all that. We also want our web browsers to support a JavaScript engine that has a non- JIT fallback, because the JIT does not work on our secondary architectures. (For Debian, those are even PRIMARY architectures!) This is even less realistic in Chromium, because V8 is hardcoded everywhere, and there is no interest whatsoever in V8 upstream in supporting an interpreter fallback. This issue means anything that requires QtWebEngine in KDE will NOT be available on all those platforms, even if we were to package QtWebEngine. (It would also increase our maintenance workload if we were to package QtWebEngine, by requiring ExcludeArch or ExclusiveArch lists all over the place.) Kevin Kofler
Re: Distros and QtWebEngine
Milian Wolff wrote: When did this take place and what is the threads subject? I seem to have missed it, and also can't find it in my recent mails. Sorry for that. It was a subthread starting here: http://lists.qt-project.org/pipermail/development/2015-February/019900.html (It also overflowed into March.) Kevin Kofler
