Lisandro Damián Nicanor Pérez Meyer wrote:
>> Fair enough. One of them starts in [0], but there was another thread in
>> which even Lars participated. So far I haven't been able to find it, I'll
>> keep trying.
>>
> Found the other one!
FYI, if you provide a gmane link, you provide the whole thr
On Tuesday 21 April 2015 09:44:41 Lisandro Damián Nicanor Pérez Meyer wrote:
> On Tuesday 21 April 2015 09:39:35 Milian Wolff wrote:
> [snip]
>
> > > Yes we have, but on the main devel mailing list,
> > > developm...@qt-project.org
> > > It has been troughly discussed, the thread is actually very
On Tuesday 21 April 2015 09:39:35 Milian Wolff wrote:
[snip]
> > 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
> mis
On 2015-04-20, Thomas Lübking 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 h
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
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 st
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 i
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
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 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
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 -
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
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 qu
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 lik
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
> di
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
>
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
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@
: 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.
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 i
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
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* - th
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: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
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 ba
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.
>
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
> b
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 webvi
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 n
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 su
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 wo
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
ha
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'
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 QtWebEng
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
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 su
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.
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 fas
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 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
> fl
>
> 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
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
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 s
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.
43 matches
Mail list logo
