---
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,
2015-04-20 23:41 GMT+02:00 Thomas Lübking thomas.luebk...@gmail.com:
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
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
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
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,
On Monday 20 April 2015, Vadim Zhukov wrote:
2015-04-20 19:28 GMT+03:00 Lisandro Damián Nicanor Pérez
perezme...@gmail.com:
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
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
On 2015-04-20, Albert Astals Cid aa...@kde.org 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=
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 thomas.luebk...@gmail.com
wrote:
On Montag, 20. April 2015 22:31:24 CEST, Jeremy Whiting wrote:
Even simple applications
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.
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
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
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* -
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
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
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
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
---
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
---
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.
---
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
2015-04-20 19:28 GMT+03:00 Lisandro Damián Nicanor Pérez perezme...@gmail.com:
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
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
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123437/
---
Review request for kdelibs.
Repository: kdelibs
Description
---
---
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
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.
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
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
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
On 2015-04-20, Albert Astals Cid aa...@kde.org 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=
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
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
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
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
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
34 matches
Mail list logo
