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/ ) Cheers, Thomas
Re: Review Request 117345: Fix crash in KIO due to exposing inconsistent views of internal data.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117345/ --- (Updated April 21, 2015, 2:30 a.m.) Status -- This change has been marked as submitted. Review request for kdelibs. Repository: kdelibs Description --- Fix crash in KIO due to exposing inconsistent views of internal data. This can be triggered by renaming a directory while one of the files in it is open in gwenview. It occurs because when KDirListerCache::emitRedirections is called, itemsInUse contains the old url. However, KDirLister::Private::redirect changes lstDirs to the new url. Thus at this point lstDirs contains an item not in itemsInUse, which causes an assertion if forgetDirs is called. In gwenview, the redirection signal is connected to openURL. This calls forgetDirs, and causes the assertion. The solution: update itemsInUse *before* emitting redirections. This fixes the crash, but gwenview opens the first file in the new directory instead of the file open before renaming. This is probably an unrelated gwenview bug. I wrote this for kdelibs 4, but the code seems unchanged in kdelibs 5. Diffs - kio/kio/kdirlister.cpp aad6893f47eba81c3f78ed1ca7327adf6fb587bb Diff: https://git.reviewboard.kde.org/r/117345/diff/ Testing --- It fixes the crash! It might break something else. Thanks, Simeon Bird
Re: Review Request 117345: Fix crash in KIO due to exposing inconsistent views of internal data.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117345/ --- (Updated April 21, 2015, 2:29 a.m.) Review request for kdelibs. Repository: kdelibs Description --- Fix crash in KIO due to exposing inconsistent views of internal data. This can be triggered by renaming a directory while one of the files in it is open in gwenview. It occurs because when KDirListerCache::emitRedirections is called, itemsInUse contains the old url. However, KDirLister::Private::redirect changes lstDirs to the new url. Thus at this point lstDirs contains an item not in itemsInUse, which causes an assertion if forgetDirs is called. In gwenview, the redirection signal is connected to openURL. This calls forgetDirs, and causes the assertion. The solution: update itemsInUse *before* emitting redirections. This fixes the crash, but gwenview opens the first file in the new directory instead of the file open before renaming. This is probably an unrelated gwenview bug. I wrote this for kdelibs 4, but the code seems unchanged in kdelibs 5. Diffs - kio/kio/kdirlister.cpp aad6893f47eba81c3f78ed1ca7327adf6fb587bb Diff: https://git.reviewboard.kde.org/r/117345/diff/ Testing --- It fixes the crash! It might break something else. Thanks, Simeon Bird
Re: Review Request 117345: Fix crash in KIO due to exposing inconsistent views of internal data.
> On April 20, 2015, 7:08 a.m., David Faure wrote: > > Should be committed to kdelibs4 indeed. Preferrably with the unittest > > improvements that you wrote for KF5. > > > > Sorry for the delay before I reviewed it. No problem - the bug's been there for several years so a few more months won't hurt :) I'll commit it with the unit test once I've checked it compiles and passes. - Simeon --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117345/#review79240 --- On Dec. 19, 2014, 6:50 p.m., Simeon Bird wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/117345/ > --- > > (Updated Dec. 19, 2014, 6:50 p.m.) > > > Review request for kdelibs. > > > Repository: kdelibs > > > Description > --- > > Fix crash in KIO due to exposing inconsistent views of internal data. > > This can be triggered by renaming a directory while one of the files in it is > open in gwenview. > > It occurs because when KDirListerCache::emitRedirections is called, > itemsInUse contains the old url. However, KDirLister::Private::redirect > changes lstDirs to the new url. Thus at this point lstDirs contains an > item not in itemsInUse, which causes an assertion if forgetDirs is > called. > > In gwenview, the redirection signal is connected to openURL. This calls > forgetDirs, and causes the assertion. > > The solution: update itemsInUse *before* emitting redirections. > > This fixes the crash, but gwenview opens the first file in > the new directory instead of the file open before renaming. > This is probably an unrelated gwenview bug. > > I wrote this for kdelibs 4, but the code seems unchanged in kdelibs 5. > > > Diffs > - > > kio/kio/kdirlister.cpp aad6893f47eba81c3f78ed1ca7327adf6fb587bb > > Diff: https://git.reviewboard.kde.org/r/117345/diff/ > > > Testing > --- > > It fixes the crash! It might break something else. > > > Thanks, > > Simeon Bird > >
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> On April 20, 2015, 10:36 p.m., Thomas Pfeiffer wrote: > > What would likely be confusing is that the two button modes have different > > interaction flows: The "End Process" mode requires to first select a > > process and then press the button to work, whereas the "Kill specific > > window" mode requires to first press the button and then select the window > > to kill, and users have no easy way to understand how each one works and > > why they work differently. > > > > The ellipsis in the label "End Process..." adds to that confusion. It > > indicates that further input is necessary before the action can take > > effect. While the button does open a dialog to confirm killing the selected > > process, ellipses are actually reserved for actions where a dialog asks for > > new information, such as the "Save As..." button, not for actions that > > require confirmation. > > > > To avoid this confusion, it should be possible to also click "End > > Process..." even if no processes has been selected, whuch would then ask > > the user to select the process to kill. This could theoretically be done > > similarly to the "Kill specific window" function: Click the "End > > Process..." button and then click the process in the list that you want to > > end. Alternatively, if no process had been selected when "End Process..." > > is clicked, a dialog could be opened where the process to kill would be > > selected. Of course the current flow of ending a process could and should > > still work. > > Gregor Mi wrote: > Thanks for the feedback! The ellipsis in "End Process..." is the original > design. According to your explanation this was wrong in the first place. What > about removing the ellipses in both menu items so we will end up with "End > Process" and "Kill a specific window"? "Kill specific window" does always need additional input until it really does something, doesn't it? As I understood it merely changes the cursor to the kill cursor and then the user has to select the window to kill, right? - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review79262 --- On April 20, 2015, 10:24 p.m., Gregor Mi wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122249/ > --- > > (Updated April 20, 2015, 10:24 p.m.) > > > Review request for KDE Base Apps, Martin Gräßlin, John Tapsell, and Thomas > Pfeiffer. > > > Repository: libksysguard > > > Description > --- > > Current situation: > The "End Process..." button has a tooltip which says "To target a specific > window to kill, press Ctrl+Alt+Esc at any time." The keyboard shortcut is > hardcoded. > > New: > Replace the "End Process..." button with a drop-down button and a action > named "Kill a specific window..." > > > Diffs > - > > CMakeLists.txt 66899e577a03786d894423a8f1ce5b3aeed6de8a > processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 > processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 > processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c > > Diff: https://git.reviewboard.kde.org/r/122249/diff/ > > > Testing > --- > > > File Attachments > > > New End Process button with drop down arrow > > https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/16301e88-e21b-4358-9a63-a85dae5722bd__screenshot_default1.png > new submenu > > https://git.reviewboard.kde.org/media/uploaded/files/2015/04/10/eeaecc88-20bc-46d6-9c65-50ba4a7c182a__submenu.png > > > Thanks, > > Gregor Mi > >
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
> On April 20, 2015, 10:36 p.m., Thomas Pfeiffer wrote: > > What would likely be confusing is that the two button modes have different > > interaction flows: The "End Process" mode requires to first select a > > process and then press the button to work, whereas the "Kill specific > > window" mode requires to first press the button and then select the window > > to kill, and users have no easy way to understand how each one works and > > why they work differently. > > > > The ellipsis in the label "End Process..." adds to that confusion. It > > indicates that further input is necessary before the action can take > > effect. While the button does open a dialog to confirm killing the selected > > process, ellipses are actually reserved for actions where a dialog asks for > > new information, such as the "Save As..." button, not for actions that > > require confirmation. > > > > To avoid this confusion, it should be possible to also click "End > > Process..." even if no processes has been selected, whuch would then ask > > the user to select the process to kill. This could theoretically be done > > similarly to the "Kill specific window" function: Click the "End > > Process..." button and then click the process in the list that you want to > > end. Alternatively, if no process had been selected when "End Process..." > > is clicked, a dialog could be opened where the process to kill would be > > selected. Of course the current flow of ending a process could and should > > still work. Thanks for the feedback! The ellipsis in "End Process..." is the original design. According to your explanation this was wrong in the first place. What about removing the ellipses in both menu items so we will end up with "End Process" and "Kill a specific window"? - Gregor --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review79262 --- On April 20, 2015, 10:24 p.m., Gregor Mi wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122249/ > --- > > (Updated April 20, 2015, 10:24 p.m.) > > > Review request for KDE Base Apps, Martin Gräßlin, John Tapsell, and Thomas > Pfeiffer. > > > Repository: libksysguard > > > Description > --- > > Current situation: > The "End Process..." button has a tooltip which says "To target a specific > window to kill, press Ctrl+Alt+Esc at any time." The keyboard shortcut is > hardcoded. > > New: > Replace the "End Process..." button with a drop-down button and a action > named "Kill a specific window..." > > > Diffs > - > > CMakeLists.txt 66899e577a03786d894423a8f1ce5b3aeed6de8a > processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 > processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 > processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c > > Diff: https://git.reviewboard.kde.org/r/122249/diff/ > > > Testing > --- > > > File Attachments > > > New End Process button with drop down arrow > > https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/16301e88-e21b-4358-9a63-a85dae5722bd__screenshot_default1.png > new submenu > > https://git.reviewboard.kde.org/media/uploaded/files/2015/04/10/eeaecc88-20bc-46d6-9c65-50ba4a7c182a__submenu.png > > > Thanks, > > Gregor Mi > >
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/#review79262 --- What would likely be confusing is that the two button modes have different interaction flows: The "End Process" mode requires to first select a process and then press the button to work, whereas the "Kill specific window" mode requires to first press the button and then select the window to kill, and users have no easy way to understand how each one works and why they work differently. The ellipsis in the label "End Process..." adds to that confusion. It indicates that further input is necessary before the action can take effect. While the button does open a dialog to confirm killing the selected process, ellipses are actually reserved for actions where a dialog asks for new information, such as the "Save As..." button, not for actions that require confirmation. To avoid this confusion, it should be possible to also click "End Process..." even if no processes has been selected, whuch would then ask the user to select the process to kill. This could theoretically be done similarly to the "Kill specific window" function: Click the "End Process..." button and then click the process in the list that you want to end. Alternatively, if no process had been selected when "End Process..." is clicked, a dialog could be opened where the process to kill would be selected. Of course the current flow of ending a process could and should still work. - Thomas Pfeiffer On April 20, 2015, 10:24 p.m., Gregor Mi wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122249/ > --- > > (Updated April 20, 2015, 10:24 p.m.) > > > Review request for KDE Base Apps, Martin Gräßlin, John Tapsell, and Thomas > Pfeiffer. > > > Repository: libksysguard > > > Description > --- > > Current situation: > The "End Process..." button has a tooltip which says "To target a specific > window to kill, press Ctrl+Alt+Esc at any time." The keyboard shortcut is > hardcoded. > > New: > Replace the "End Process..." button with a drop-down button and a action > named "Kill a specific window..." > > > Diffs > - > > CMakeLists.txt 66899e577a03786d894423a8f1ce5b3aeed6de8a > processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 > processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 > processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c > > Diff: https://git.reviewboard.kde.org/r/122249/diff/ > > > Testing > --- > > > File Attachments > > > New End Process button with drop down arrow > > https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/16301e88-e21b-4358-9a63-a85dae5722bd__screenshot_default1.png > new submenu > > https://git.reviewboard.kde.org/media/uploaded/files/2015/04/10/eeaecc88-20bc-46d6-9c65-50ba4a7c182a__submenu.png > > > Thanks, > > Gregor Mi > >
Re: Review Request 122249: libksysguard: add Kill Window to End Process button and show correct keyboard shortcut
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122249/ --- (Updated April 20, 2015, 10:24 p.m.) Review request for KDE Base Apps, Martin Gräßlin, John Tapsell, and Thomas Pfeiffer. Changes --- Remove message box screenshot because the text changed. There are two different texts depending if KWin is used or not. Message box without KWin: ``` Typically, the kill window method can be invoked with the global shortcut Ctrl+Alt+Esc. The mouse cursor will then change into a deadly skull or some other pirate symbol. If you left-click on a window, the corresponding process will be killed - and unsaved data be lost. Typically, with right-click you can abort. ``` Message box text with KWin: ``` The kill window method can be invoked with a global shortcut which is currently set to: Ctrl+Alt+Esc The mouse cursor will then change into a deadly skull or some other pirate symbol. If you left-click on a window, the corresponding process will be killed - and unsaved data be lost. With right-click or the Esc key you can abort. ``` Repository: libksysguard Description --- Current situation: The "End Process..." button has a tooltip which says "To target a specific window to kill, press Ctrl+Alt+Esc at any time." The keyboard shortcut is hardcoded. New: Replace the "End Process..." button with a drop-down button and a action named "Kill a specific window..." Diffs - CMakeLists.txt 66899e577a03786d894423a8f1ce5b3aeed6de8a processui/CMakeLists.txt 7f87b85e0201e63d69070a71203bbb34851a79c6 processui/ProcessWidgetUI.ui e50f55cf1813b00d49b1716023df487ffbd536e3 processui/ksysguardprocesslist.cpp 450ca600b8aed7ca611ec638610b6c524c96080c Diff: https://git.reviewboard.kde.org/r/122249/diff/ Testing --- File Attachments (updated) New End Process button with drop down arrow https://git.reviewboard.kde.org/media/uploaded/files/2015/01/28/16301e88-e21b-4358-9a63-a85dae5722bd__screenshot_default1.png new submenu https://git.reviewboard.kde.org/media/uploaded/files/2015/04/10/eeaecc88-20bc-46d6-9c65-50ba4a7c182a__submenu.png Thanks, Gregor Mi
Re: Distros and QtWebEngine
2015-04-20 23:41 GMT+02:00 Thomas Lübking : > On Montag, 20. April 2015 23:02:34 CEST, Sune Vuorela wrote: > >> Let's just try to follow that thru. >> >> A new QuigleyImageView pulls in a new Qt. The newer Qt breaks somehow >> Plasma, >> because relying on internals. Then a newer Plasma is pulled in. THat ... > > > 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) > > Also your list implies that one never can update KDE, because that breaks > GNOME, requires a kernel update and whatnot. (Taking my Debian developer hat) Yes, stuff like that happens and is absolutely common - that's why we have a development cycle, where we tune the distribution to have all parts working well together. If we make a huge update on one part, we might end up breaking more things than we solve issues. >> Unfortunately, I haven't really used my imagination here. > > That implies the Linux SW stack is crap. Point taken. Well, it's not crap, but... ;-) Different upstreams care for different things: Some care very much for backward compatibility and never break API or ABI. Others, however, break API/ABI with every single release, remove features and add new ones or even decide to rewrite the whole application. They might also drop support for lower versions of dependency X at any time. I don't say this behaviour is bad, but it makes it impossible to plan for changes, and to be 100% certain that a change does not break other unrelated software. When we release a new version of Debian, users expect the current feature set to remain stable, so they can tune their workflow to it and be sure it does not randomly break because a software decided to e.g. remove command-line flag which became unsupported upstream. The same way, the quick webbrowser updates are a huge issue in the enterprise. In order to keep the whole thing we call a "distribution" sane, we have a set of rules, like "do not duplicate code in the archive". This ensures that we do not need to patch the same thing over and over again, in case there is a security hole in the respective code block. So, in summary: The free software stack is a mess, and distributors align it to produce a working compilation of software. This is simply because there is no central authority coordinating the development of Mesa, Plasma, GNOME, GCC, systemd, etc., so incompatibilities can arise at any time. Cheers, Matthias
Re: Distros and QtWebEngine
On Monday 20 April 2015, Vadim Zhukov wrote: > 2015-04-20 19:28 GMT+03:00 Lisandro Damián Nicanor Pérez : > > 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 :( > > And if such large-community distros like Debian and Fedora have > issues, what to say about smaller ones? Also, QtWebEngine isn't ported > outside of Linux, Windows and MacOS X at all. > > I'm an OpenBSD developer, maintaining almost all Qt and KDE ports for > now. And I can clearly say that I won't ever start working on > QtWebEngine: chromium port in OpenBSD (maintained by a different > person) already has 285 (sic!) local patches, so QtWebEngine will need > at least as much. That's, obviously, too much. So until something > changes, there will be no KF5-based PIM on OpenBSD. > > I'm not in favor of using outdated QtWebkit module either: it's likely > full of security holes, so it's not the thing you want to throw > incoming email at. > QtWebKit is not outdated yet. And security is least of problems when it starts getting older. The main problem is that it is slowly losing the ability to show modern webpages. The first causality was YouTube TV mode and anything else depending on Media Stream Extensions. More will join those once age sets in, but for EMail or wikipedia; I think QtWebKit should be fine for a few years yet, especially for applications that continued to use Qt4.8 QtWebKit until recently. Anyway, QtWebEngine runs a patched fork of chromium, and while we don't support OpenBSD, you are welcome to contribute patches to us. Regards `Allan
Re: Distros and QtWebEngine
On Montag, 20. April 2015 23:02:34 CEST, Sune Vuorela wrote: Let's just try to follow that thru. A new QuigleyImageView pulls in a new Qt. The newer Qt breaks somehow Plasma, because relying on internals. Then a newer Plasma is pulled in. THat ... 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) Also your list implies that one never can update KDE, because that breaks GNOME, requires a kernel update and whatnot. Unfortunately, I haven't really used my imagination here. That implies the Linux SW stack is crap. Point taken. Cheers, Thomas
Re: Distros and QtWebEngine
On Montag, 20. April 2015 23:11:49 CEST, Alexander Neundorf wrote: On Monday, April 20, 2015 22:54:26 Thomas Lübking wrote: On Montag, 20. April 2015 22:31:24 CEST, Jeremy Whiting wrote: Even simple applications may want to use a webview for stuff. Kanagram at one point had a QtWebkit Web view just to show the wikipedia entry of the current word. Ouch, sounds like giant overhead =) Shouldn't the basic html subset support in QTextView provide anything for this? probably not. You very quickly hit the limits of that. Yeah, but they want to show a word definition... (I assume?) - there's not much limit pushing in that. Using a QWebView doesn't "feel" like giant overhead Depends on whether - kanagramm is the only user - it crashes Maybe I meant "overengineered" Cheers, Thomas
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/ ) Cheers, Thomas
Re: Distros and QtWebEngine
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. Ciao -- Luigi
Re: Distros and QtWebEngine
On Monday, April 20, 2015 22:54:26 Thomas Lübking wrote: > On Montag, 20. April 2015 22:31:24 CEST, Jeremy Whiting wrote: > > Even simple applications may want to use a webview for stuff. Kanagram at > > one point had a QtWebkit Web view just to show the wikipedia entry of the > > current word. > > Ouch, sounds like giant overhead =) > Shouldn't the basic html subset support in QTextView provide anything for > this? probably not. You very quickly hit the limits of that. Using a QWebView doesn't "feel" like giant overhead, displaying a few kB of html is instant, and you have all HTML features ate your hand. Alex
Re: Distros and QtWebEngine
On 2015-04-20, Albert Astals Cid wrote: > Just state that there's no such long maintaince time for that package o= > r just=20 > install the newer version of Qt. And yes again that probably goes again= > st your=20 > rules, but it's your rules, so you can just improve them for everyone's= >=20 > benefit :) Let's just try to follow that thru. A new QtWebEngine pulls in a new Qt. The newer Qt breaks somehow Plasma, because relying on internals. Then a newer Plasma is pulled in. THat requires a newer KDE Frameworks, and a newer Wayland and a newer Mesa. Those two components requires a newer kernel. The newer KDE frameworks also has a couple of extra requirements. Some of those extra requirements happens to break parts of the Gnome stack. So a update of that is needed too. That requires a newer systemd, that discovers issues with apache. The newest apache has a changed plugin api that requires changes to all the apache extensions. Including php, ruby and python. You can likely continue the story yourself from here. Unfortunately, I haven't really used my imagination here. /Sune
Re: Distros and QtWebEngine
Yeah, that's probably a better idea. is there a QML ui for QTextview? or maybe some other QML component that renders html. On Mon, Apr 20, 2015 at 2:54 PM, Thomas Lübking wrote: > On Montag, 20. April 2015 22:31:24 CEST, Jeremy Whiting wrote: > >> Even simple applications may want to use a webview for stuff. Kanagram at >> one point had a QtWebkit Web view just to show the wikipedia entry of the >> current word. >> > > Ouch, sounds like giant overhead =) > Shouldn't the basic html subset support in QTextView provide anything for > this? (in doubt: fetch the xml and htmlify that locally?) > > Cheers, > Thomas >
Re: Distros and QtWebEngine
On Monday 20 April 2015 13:28:59 Lisandro Damián Nicanor Pérez Meyer wrote: > 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 :( 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 . Previously, many of the 3rd party stuff was just hardcoded and shipped internally because it was easier to get stuff done. 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. 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. Bye -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
Re: Distros and QtWebEngine
On Montag, 20. April 2015 22:31:24 CEST, Jeremy Whiting wrote: Even simple applications may want to use a webview for stuff. Kanagram at one point had a QtWebkit Web view just to show the wikipedia entry of the current word. Ouch, sounds like giant overhead =) Shouldn't the basic html subset support in QTextView provide anything for this? (in doubt: fetch the xml and htmlify that locally?) Cheers, Thomas
Re: Distros and QtWebEngine
On Montag, 20. April 2015 22:16:34 CEST, Luigi Toscano wrote: That said, let's talk for a moment on real use cases: how many applications can need an *hard* dependency on the beast, apart from mail apps? Everybody. Nobody. Depends. The API doesn't look quite exchangeable w/ QWebKit, so one would require a (ONE) compile and/or runtime shim, what raises the questions a) is that worth it, given (assuming) that QWebKit will at some point become unmaintained (and the insecure) b) wtf is gonna happen when, let's say, QWebKit is gonna be dropped in Qt6? 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". Cheers, Thomas [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?!?
Re: Distros and QtWebEngine
Even simple applications may want to use a webview for stuff. Kanagram at one point had a QtWebkit Web view just to show the wikipedia entry of the current word. It was disabled because QtWebKit at the time was crashing. I'd like to use something light and secure, but am not sure what options we have going forward tbh. On Mon, Apr 20, 2015 at 2:16 PM, Luigi Toscano wrote: > Albert Astals Cid ha scritto: > > El Dilluns, 20 d'abril de 2015, a les 15:52:12, Lisandro Damián Nicanor > Pérez > > Meyer va escriure: > > > >> I could also say that Fedora+Debian+Debian derivatives (Ubuntu is > mostly in > >> the same position as us) is also a large userbase for KDE to loose. > >> > >> But *it's not really* about which distro or app is going to loose more > user > >> base, it's about keeping the current one. I don't want Debian nor KDE to > >> loose users, in the same way I do not want to ship something that's > >> unmaintainable. > > > > Maybe you guys should just trust the Qt project to maintain QtWebEngine > and > > just run with what they provide instead of needing 3 people to > "maintain" it > > yourselves? > > Qt project can maintain their bits, sure. Are they looking "inside" the big > block, or do they import the core engine as it is? If the latter, well, > it's > not that simple as trusting them. > > > > > > What's wrong with that besides it going against your rules? > > The rules are there not because someone wants to have unhappy users; think > about the rule about untangling tons of embedded libraries and patching > issues. > > > > > That you need to provide longer maintaince times than what Qt upstream > > provides? > > > > Just state that there's no such long maintaince time for that package or > just > > install the newer version of Qt. And yes again that probably goes > against your > > rules, but it's your rules, so you can just improve them for everyone's > > benefit :) > > Even Firefox ended up providing an yearly stable release for make it > easier, > and it's not an hard dependency (and they don't even provide a stable API). > > > That said, let's talk for a moment on real use cases: how many applications > can need an *hard* dependency on the beast, apart from mail apps? > > Ciao > -- > Luigi >
Re: Distros and QtWebEngine
Albert Astals Cid ha scritto: > El Dilluns, 20 d'abril de 2015, a les 15:52:12, Lisandro Damián Nicanor Pérez > Meyer va escriure: > >> I could also say that Fedora+Debian+Debian derivatives (Ubuntu is mostly in >> the same position as us) is also a large userbase for KDE to loose. >> >> But *it's not really* about which distro or app is going to loose more user >> base, it's about keeping the current one. I don't want Debian nor KDE to >> loose users, in the same way I do not want to ship something that's >> unmaintainable. > > Maybe you guys should just trust the Qt project to maintain QtWebEngine and > just run with what they provide instead of needing 3 people to "maintain" it > yourselves? Qt project can maintain their bits, sure. Are they looking "inside" the big block, or do they import the core engine as it is? If the latter, well, it's not that simple as trusting them. > > What's wrong with that besides it going against your rules? The rules are there not because someone wants to have unhappy users; think about the rule about untangling tons of embedded libraries and patching issues. > > That you need to provide longer maintaince times than what Qt upstream > provides? > > Just state that there's no such long maintaince time for that package or just > install the newer version of Qt. And yes again that probably goes against > your > rules, but it's your rules, so you can just improve them for everyone's > benefit :) Even Firefox ended up providing an yearly stable release for make it easier, and it's not an hard dependency (and they don't even provide a stable API). That said, let's talk for a moment on real use cases: how many applications can need an *hard* dependency on the beast, apart from mail apps? Ciao -- Luigi
Re: Distros and QtWebEngine
2015-04-20 19:28 GMT+03:00 Lisandro Damián Nicanor Pérez : > 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 :( And if such large-community distros like Debian and Fedora have issues, what to say about smaller ones? Also, QtWebEngine isn't ported outside of Linux, Windows and MacOS X at all. I'm an OpenBSD developer, maintaining almost all Qt and KDE ports for now. And I can clearly say that I won't ever start working on QtWebEngine: chromium port in OpenBSD (maintained by a different person) already has 285 (sic!) local patches, so QtWebEngine will need at least as much. That's, obviously, too much. So until something changes, there will be no KF5-based PIM on OpenBSD. I'm not in favor of using outdated QtWebkit module either: it's likely full of security holes, so it's not the thing you want to throw incoming email at. Could some sa[fn]e, compact, non-JS engine be used for viewing mail and other PIM activities? What options do KDE PIM people see? -- WBR, Vadim Zhukov
Re: Distros and QtWebEngine
El Dilluns, 20 d'abril de 2015, a les 15:52:12, Lisandro Damián Nicanor Pérez Meyer va escriure: > On Monday 20 April 2015 20:17:13 Albert Astals Cid wrote: > [snip] > > > IMHO the duty of a distro is providing software to their users to use, if > > the rules of the distro make providing software hard/impossible they need > > to be updated or these distros need to understand they will lose users to > > more flexible distros. > > Let me begin that I acknowledge you have a fair point there. But using the > same reasoning users can also switch to using other apps. Users are free to do what they want, that's obvious, but if the user switches is not because we used QtWebEngine in an app, sane users could not care the less which technologies we use. If the user switches is because for some reason the distro decided that their rules are more important than the user and forced him either to switch distro or to switch apps by not packaging something. > I could also say that Fedora+Debian+Debian derivatives (Ubuntu is mostly in > the same position as us) is also a large userbase for KDE to loose. > > But *it's not really* about which distro or app is going to loose more user > base, it's about keeping the current one. I don't want Debian nor KDE to > loose users, in the same way I do not want to ship something that's > unmaintainable. Maybe you guys should just trust the Qt project to maintain QtWebEngine and just run with what they provide instead of needing 3 people to "maintain" it yourselves? What's wrong with that besides it going against your rules? That you need to provide longer maintaince times than what Qt upstream provides? Just state that there's no such long maintaince time for that package or just install the newer version of Qt. And yes again that probably goes against your rules, but it's your rules, so you can just improve them for everyone's benefit :) Cheers, Albert > > So if any of us with with an upstream hat is going to code something, please > consider that having a hard dependency on QtWebEngine might mean his/her > code might not get available to everyone as it used to be, that's all. signature.asc Description: This is a digitally signed message part.
Re: Distros and QtWebEngine
On Monday, 20 April 2015 21:12:44 CEST, Franz Fellner wrote: Is it really necessary to use a multiprocess web framework just to view HTML mails? I suppose that it is necessary to use an HTML content renderer which: - is still supported, - remains reasonably secure and up-to-date, - provides sufficient features to make sure that users' privacy is not compromised. Whether it implies using multiprocess architecture or not is an internal implementation detail. We might think that it's an overengineered beast, but our opinion is not as important as the opinion of the guys who are doing the actual work. Can't this be done with different backends, so users/distros have the option to simply use KHTML? I cannot speak for KDEPIM, but I can speak for Trojita which is currently using QtWebKit. Based on a quick glance through the KHTMLPart's public API, I cannot use it in Trojita. One of the reasons is that HTML e-mails use the cid: URL scheme for accessing data from other MIME parts in the same message. I don't see any way to implement custom URL schemes *and* to disable arbitrary network access on a per-message basis at the same time. The e-mail clients unfortunately ar especial; their use case is much different from a web browser model, they cannot work through a "just render this HTML you read from this QIODevice", and at the same time thay are expected to render rich HTML with full support for modern CSS. I'm not surprised that KHTML's API is not sufficient; the QML-based API of Qt's WebKit2 wasn't sufficient, either. Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: Distros and QtWebEngine
Jan Kundrát ha scritto: > On Monday, 20 April 2015 21:14:51 CEST, Sune Vuorela wrote: >> And Red Hat is following Fedora. > > RHEL might not be a good example here because they are a rather a strange > beast. RHEL has actually never shipped QtWebKit (!) and they also aren't > shipping Qt5 so far. Just my guess, as I'm not involved in the operating system, but Qt5 was not stable enough (and no applications) when RHEL7 was frozen. As for QtWebKit, problem of maintainability (count the CVE). Ciao -- Luigi
Re: Distros and QtWebEngine
On Monday, 20 April 2015 21:14:51 CEST, Sune Vuorela wrote: And Red Hat is following Fedora. RHEL might not be a good example here because they are a rather a strange beast. RHEL has actually never shipped QtWebKit (!) and they also aren't shipping Qt5 so far. Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: Distros and QtWebEngine
Albert Astals Cid wrote: > El Dilluns, 20 d'abril de 2015, a les 13:28:59, Lisandro Damián Nicanor Pérez > Meyer va escriure: > > 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. > > IMHO the duty of a distro is providing software to their users to use, if the > rules of the distro make providing software hard/impossible they need to be > updated or these distros need to understand they will lose users to more > flexible distros. Or they will switch PIM applications. Or even the DE. Don't think users are married with your application... Is it really necessary to use a multiprocess web framework just to view HTML mails? Can't this be done with different backends, so users/distros have the option to simply use KHTML? > > Cheers, > Albert
Re: Distros and QtWebEngine
On 2015-04-20, Albert Astals Cid wrote: > IMHO the duty of a distro is providing software to their users to use, = > if the=20 > rules of the distro make providing software hard/impossible they need t= > o be=20 > updated or these distros need to understand they will lose users to mor= > e=20 > flexible distros. Unless distros and KDE work together somehow, it is going to be a lose/lose situation for both KDE and and for the distros in question. And maybe even for the free software desktop. The exact problem here is that packaging chromium in Debian is something that needs at least 2 skilled dedicated people to. Packaging QtWebEngine is like packaging chromium (because it is chromium) + a little bit more. The rumors is that (K)Ubuntu is likely following Debian. To the best of my knowledge, chromium aren't shipped at all in fedora because maintenance nightmare. And Red Hat is following Fedora. That's likely half of the actual linux desktop landscape. We (as KDE) can either insist saying "if you don't ship this technology we won't deal with you" or we can try to work together with our downstreams to find a way to somehow make everyone somehow happy. We (as KDE) need to understand that if we don't have our software in distributions, it is just as likely that people will switch applications, as it is that they will switch distributions. So, all in all, if everyone takes a hard stance, everyone will lose. Let's find a way so we all can win. /Sune
Re: Distros and QtWebEngine
> > 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. > gold linker seems to handle this a /lot/ better than normal ld. It made my little laptop able to cope. David
Re: Distros and QtWebEngine
On Monday 20 April 2015 20:17:13 Albert Astals Cid wrote: [snip] > IMHO the duty of a distro is providing software to their users to use, if > the rules of the distro make providing software hard/impossible they need > to be updated or these distros need to understand they will lose users to > more flexible distros. Let me begin that I acknowledge you have a fair point there. But using the same reasoning users can also switch to using other apps. I could also say that Fedora+Debian+Debian derivatives (Ubuntu is mostly in the same position as us) is also a large userbase for KDE to loose. But *it's not really* about which distro or app is going to loose more user base, it's about keeping the current one. I don't want Debian nor KDE to loose users, in the same way I do not want to ship something that's unmaintainable. So if any of us with with an upstream hat is going to code something, please consider that having a hard dependency on QtWebEngine might mean his/her code might not get available to everyone as it used to be, that's all. -- 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
El Dilluns, 20 d'abril de 2015, a les 13:28:59, Lisandro Damián Nicanor Pérez Meyer va escriure: > 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. IMHO the duty of a distro is providing software to their users to use, if the rules of the distro make providing software hard/impossible they need to be updated or these distros need to understand they will lose users to more flexible distros. Cheers, Albert signature.asc Description: This is a digitally signed message part.
Distros and QtWebEngine
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 :( -- 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.
Review Request 123437: FinKexiv2: Use FindPkgConfig instead of UsePkgConfig
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123437/ --- Review request for kdelibs. Repository: kdelibs Description --- The latter is deprecated and doesn't respect the PKG_CONFIG environment variable which makes it easy to deal with differently named pkg-config executables, e.g. arch-prefixed ones. Diffs - cmake/modules/FindKexiv2.cmake ad9969ab9c1e7f3848922ce6160a5725cb6641bb Diff: https://git.reviewboard.kde.org/r/123437/diff/ Testing --- I built okular and checked that it finds and links against libkexiv2. Thanks, Heiko Becker
Re: Review Request 117345: Fix crash in KIO due to exposing inconsistent views of internal data.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117345/#review79240 --- Should be committed to kdelibs4 indeed. Preferrably with the unittest improvements that you wrote for KF5. Sorry for the delay before I reviewed it. - David Faure On Dec. 19, 2014, 6:50 p.m., Simeon Bird wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/117345/ > --- > > (Updated Dec. 19, 2014, 6:50 p.m.) > > > Review request for kdelibs. > > > Repository: kdelibs > > > Description > --- > > Fix crash in KIO due to exposing inconsistent views of internal data. > > This can be triggered by renaming a directory while one of the files in it is > open in gwenview. > > It occurs because when KDirListerCache::emitRedirections is called, > itemsInUse contains the old url. However, KDirLister::Private::redirect > changes lstDirs to the new url. Thus at this point lstDirs contains an > item not in itemsInUse, which causes an assertion if forgetDirs is > called. > > In gwenview, the redirection signal is connected to openURL. This calls > forgetDirs, and causes the assertion. > > The solution: update itemsInUse *before* emitting redirections. > > This fixes the crash, but gwenview opens the first file in > the new directory instead of the file open before renaming. > This is probably an unrelated gwenview bug. > > I wrote this for kdelibs 4, but the code seems unchanged in kdelibs 5. > > > Diffs > - > > kio/kio/kdirlister.cpp aad6893f47eba81c3f78ed1ca7327adf6fb587bb > > Diff: https://git.reviewboard.kde.org/r/117345/diff/ > > > Testing > --- > > It fixes the crash! It might break something else. > > > Thanks, > > Simeon Bird > >
