Re: [Development] Why does QLabel::pixmap() return `const QPixmap*`?
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++ does not allow null references. (The compiler might let you get away with it, but in principle, it is not allowed.) Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QtWebEngine (was: Re: Clarification needed for Qt Script's future over QJSEngine/Value)
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: * bundling of Chromium by QtWebEngine, * bundling of many libraries by Chromium (and thus transitively by QtWebEngine), * lack of integration with the system and even Qt itself, e.g.: - we lose QNetworkAccess, which allowed making QtWebKit use KIO (see KWebKitPart) – Chromium hardcodes its network access code instead. This also means no support for man:, info:, gopher: etc. protocols, unless they get implemented as Chromium plugins (but last I checked, QtWebEngine also didn't support those). - no GStreamer support. (Direct FFmpeg use is a PITA for distributions to deal with.) We are not even sure we will be able to import QtWebEngine into Fedora at all, because of the bundling and FFmpeg issues. (So far, nobody has dared even trying to submit it for review.) Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Why does QLabel::pixmap() return `const QPixmap*`?
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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The dark side of QtMultimedia
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 upstream support officially ends, and Debian needs to support > > Jessie's Qt4 for critical/security bug fixes at least until 2018, or > > even 2020 if the LTS effort continues. > > So what? Red Hat will probably support Qt 4 in RHEL with security fixes for > longer than that. At least I (as a community, non-Red-Hat, Fedora packager) > am prepared to also do that work in Fedora. We still ship Qt 3 in Fedora > too. I'm really glad you have the time for Fedora. Sadly we don't have people with the time and will to do it. Maybe if you have some more spare time... ;) -- Quote me as saying I was mis-quoted. -- Groucho Marx 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The dark side of QtMultimedia
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 way into 2017... > > 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 upstream support officially ends, and Debian needs to support > Jessie's Qt4 for critical/security bug fixes at least until 2018, or > even 2020 if the LTS effort continues. Correct, the main reason here is stable. If we keep Qt4 for Stretch it means we will need to support it until ~2020. Considering out current manpower that's simply impossible. Of course, if someone wants to step up to support it all the way until 2020 we might reconsider it. And yes, as Timo said, the easy of porting helps here. On the other hand, when we removed Qt3 we only had 13 packages that where not ported. -- Alas, I am dying beyond my means. Oscar Wilde, as he sipped champagne on his deathbed 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Clarification needed for Qt Script's future over QJSEngine/Value
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. -- Trabaja como si no necesitaras el dinero. Ama como si nunca hubieses sido herido. Baila como si nadie estuviera mirando. Canta como si nadie escuchara. Vive como si fuera el Cielo en la Tierra. Anónimo 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] changing Q_GADGET
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 stuff at the end is likely ok, if Q_GADGET
doesn't change accesslevel in the beginning.
But doesn't Q_GADGET start with changing accesslevel to public?
The only safe way is to then switch to private.
class MyClass
{
Q_GADGET
class MyPrivate;
int m_myCounter;
public:
MyClass);
}
> The proposed change would have two effects:
>
> 1) It makes any existing code that _relies_ on Q_GADGET turning to private
> suddenly expose members in structures.
>
> 2) On paper it breaks binary compatibility with MSVC, in the unlikely event
> that somebody
> a) produces a DLL and cares about binary compatibility
> b) exposes bare structures
> c) relies on Q_GADGET turning access permission levels to private
3) Making accesslevel public for private class members.
/Sune
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
