On 2014-11-28, Simon Hausmann simon.hausm...@theqtcompany.com 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.
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 Monday 24 November 2014 09:38:17 Timo Jyrinki wrote:
2014-11-17 18:49 GMT+02:00 Thiago Macieira thiago.macie...@intel.com:
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
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
Qt 4
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
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:
*
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++
