Sze Howe Koh wrote:
> I'm curious about the rationale behind this API design. I can't think
> of any other Qt function that returns an implicitly-shared object by
> pointer, so this seems inconsistent. e.g. QWidget::font() returns a
> QFont by const-ref.
Probably because the pointer can be null. C
Lisandro Damián Nicanor Pérez Meyer wrote:
> Which means that lots of archs will not be able to have QtWebEngine.
Right. This is one of the many problems of QtWebEngine and its Chromium
dependency. (It will affect the Fedora secondary architectures, too.)
If you want to know the others:
* bundli
Hi all,
I'm curious about the rationale behind this API design. I can't think
of any other Qt function that returns an implicitly-shared object by
pointer, so this seems inconsistent. e.g. QWidget::font() returns a
QFont by const-ref.
Regards,
Sze-Howe
___
On Tuesday 25 November 2014 02:44:35 Kevin Kofler wrote:
> Timo Jyrinki wrote:
> > Debian plans to not have Qt 4 after Debian 8.0 [1]. But that means
> > ~2017 indeed for stable release users, the removal itself happening
> > during 2015-2016 in the development version. The main reason is that
> >
On Monday 24 November 2014 09:38:17 Timo Jyrinki wrote:
> 2014-11-17 18:49 GMT+02:00 Thiago Macieira :
> > By the way, I read somewhere that some distros are considering not
> > shipping
> > Qt 4 as early as their next releases. I also think that's shortsighted.
> > Keep it in your repos all the wa
On Friday 28 November 2014 05:08:43 Kevin Kofler wrote:
> Thiago Macieira wrote:
> > Since Qt doesn't use V8 anymore, there should not be any clashes at all.
>
> Be warned though that QtWebEngine does use V8 through Chromium.
Which means that lots of archs will not be able to have QtWebEngine.
-
On 2014-11-28, Simon Hausmann wrote:
> I feel that Q_GADGET has its primary use with structures and the default
> access level for those is public. I find it awkward that you currently have
> to
> write:
I have a lot of code in the wild using classes and Q_GADGET.
Having Q_GADGET not change
