Re: [Interest] Using private QtQuick APIs

2018-01-19 Thread Benjamin TERRIER
2018-01-18 9:32 GMT+01:00 Uwe Rathmann : > > > And as long as C++ has not been agreed to be an officially supported API > to implemented Qt/Quick applications I don't have many arguments for my > patches. > I remember one of the Qt SceneGraph/Quick developers saying at

Re: [Interest] Using private QtQuick APIs

2018-01-18 Thread Uwe Rathmann
On Wed, 17 Jan 2018 11:59:41 -0800, Thiago Macieira wrote: > True. Maybe it has never occurred to them that the API would be needed. > You can help make it happen by adding this API yourself too. In the case of QSkinny we are not talking about some APIs it is a fundamentally different

Re: [Interest] Using private QtQuick APIs

2018-01-17 Thread Jean-Michaël Celerier
I propose the following motion: directly import the whole of github & sourceforge into the Qt project. After all why shouldn't every piece of code in the universe be part of Qt, released at a perfect six-month cadence ? This way, every project in the world will be able to access the "private" Qt

Re: [Interest] Using private QtQuick APIs

2018-01-17 Thread Thiago Macieira
On Wednesday, 17 January 2018 10:27:43 PST Uwe Rathmann wrote: > On Wed, 17 Jan 2018 09:34:54 -0800, Thiago Macieira wrote: > > It is just sharing code. The important difference is that both modules > > are developed at the same time and released at the same time, by the > > same team. > > Yes of

Re: [Interest] Using private QtQuick APIs

2018-01-17 Thread Konstantin Tokarev
17.01.2018, 21:30, "Uwe Rathmann" : > On Wed, 17 Jan 2018 09:34:54 -0800, Thiago Macieira wrote: > >>  It is just sharing code. The important difference is that both modules >>  are developed at the same time and released at the same time, by the >>  same team. > > Yes

Re: [Interest] Using private QtQuick APIs

2018-01-17 Thread Uwe Rathmann
On Wed, 17 Jan 2018 09:34:54 -0800, Thiago Macieira wrote: > It is just sharing code. The important difference is that both modules > are developed at the same time and released at the same time, by the > same team. Yes of course, but my project is developed at a different time, released at a

Re: [Interest] Using private QtQuick APIs

2018-01-17 Thread Thiago Macieira
On Wednesday, 17 January 2018 03:24:26 PST Uwe Rathmann wrote: > On Wed, 17 Jan 2018 23:19:57 +1300, Christian Gagneraud wrote: > > Why do you need private headers in the first place? > > For the same reason, why a module like QuickControls 2 is using private > headers of Quick Core. It is just

Re: [Interest] Using private QtQuick APIs

2018-01-17 Thread Uwe Rathmann
On Wed, 17 Jan 2018 23:19:57 +1300, Christian Gagneraud wrote: > Why do you need private headers in the first place? For the same reason, why a module like QuickControls 2 is using private headers of Quick Core. The qskinny project is about creating a C++ framework ( QML is only optional )

Re: [Interest] Using private QtQuick APIs

2018-01-17 Thread Christian Gagneraud
On 17 January 2018 at 21:32, Uwe Rathmann wrote: > On Wed, 17 Jan 2018 08:25:35 +, Mitch Curtis wrote: > > This how I do it ( see https://github.com/uwerat/qskinny ): > > QT += quick quick-private > CONFIG += no_private_qt_headers_warning > > To get rid of warnings

Re: [Interest] Using private QtQuick APIs

2018-01-17 Thread Uwe Rathmann
On Wed, 17 Jan 2018 08:25:35 +, Mitch Curtis wrote: This how I do it ( see https://github.com/uwerat/qskinny ): QT += quick quick-private CONFIG += no_private_qt_headers_warning To get rid of warnings from Qt headers, when doing pedantic checks I also have the following lines: linux {

Re: [Interest] Using private QtQuick APIs

2018-01-17 Thread Mitch Curtis
In qtquickcontrols2.git [1] it’s linked to like this: QT_PRIVATE += quick-private I think QT += quick-private also works.. not sure what the difference is. [1] http://code.qt.io/cgit/qt/qtquickcontrols2.git/tree/src/quicktemplates2/quicktemplates2.pro#n6 On 1/16/18, 4:43 PM, "Interest on