On Tue, 7 Jan 2014 06:18:19 Qi Liang wrote:
> Looks like it's a qml plugin, then maybe there is an example/practice in
> qtquickcontrols.
They are not a QML plugin, they are position and geoservices plugins that
happen to have qml in there names for some reason.
> https://github.com/qtproject/qt
Hi,
Have you checked the qt auto tests? You could have a look into
qtdeclarative/tests/auto (quick) and/or qtquickcontrols/tests/auto folder.
There are plenty of tests there and you can probably find some that are
relevant to you.
Regards,
Caroline
Fro
Looks like it's a qml plugin, then maybe there is an example/practice in
qtquickcontrols.
https://github.com/qtproject/qtquickcontrols/blob/stable/tests/auto/auto.pro
https://github.com/qtproject/qtquickcontrols/tree/stable/tests/auto/testplugin
https://github.com/qtproject/qtquickcontrols/blob/s
Hi,
Qt Positioning and Qt Location use moc plugins in various test cases. These
tests run fine locally with a developer build of Qt but fail when run in the
CI system. From what it looks like this is because the moc plugins are not
installed and cannot be loaded, see integration failure in [1].
Hi,
I've spent the last few weeks going over the current print support and
trying to map out a plan to improve things. We've long intended to
create a new QtPrint module to replace QtPrintSupport in which we
separate the painting code from the print job management code and
support a more modern w
On Mon, Jan 6, 2014 at 9:41 AM, Qi Liang wrote:
> What is qt modularization for? We want to have different release cycles for
> different qt modules.
As I recall, that means we want to be able to have different
release/versioning cycles, but there will still be a regular Qt
release package conta
2014/1/6 David Faure
> On Monday 06 January 2014 19:43:45 Konstantin Ritt wrote:
> > I don't like the idea of removing QT_NO_DEBUG_STREAM. Even if Qt itself
> > doesn't build with it (which is fixable), one might define it globally
> > after it built, to avoid building an unnecessary code in his/
On Monday 06 January 2014 19:43:45 Konstantin Ritt wrote:
> I don't like the idea of removing QT_NO_DEBUG_STREAM. Even if Qt itself
> doesn't build with it (which is fixable), one might define it globally
> after it built, to avoid building an unnecessary code in his/3rd-party
> modules.
You don't
I don't like the idea of removing QT_NO_DEBUG_STREAM. Even if Qt itself
doesn't build with it (which is fixable), one might define it globally
after it built, to avoid building an unnecessary code in his/3rd-party
modules.
We already have
#define qDebug QMessageLogger(__FILE__, __LINE__, Q_FUNC_I
What is qt modularization for? We want to have different release cycles for
different qt modules.
Then +1 for that.
For offline installer, I suggest, a separate installer for it, but it should
based on installed qt directory. It is compatible with 5.2.0 release in this
way.
For online installe
Mandag 6. januar 2014 15.35.14 skrev Thiago Macieira:
> On segunda-feira, 6 de janeiro de 2014 17:23:43, Frederik Gladhorn wrote:
> > Hello,
> >
> > we (some of us at Digia) have been working on Enginio - a convenient cloud
> > storage for Qt applications. Since the library is actively maintained
On segunda-feira, 6 de janeiro de 2014 17:23:43, Frederik Gladhorn wrote:
> Hello,
>
> we (some of us at Digia) have been working on Enginio - a convenient cloud
> storage for Qt applications. Since the library is actively maintained we
> would like to integrate it into the official Qt release for
On segunda-feira, 6 de janeiro de 2014 15:52:35, Koehne Kai wrote:
> So, anyone would mind if I remove QT_NO_DEBUG_STREAM from the code base? I
> already started to do so for QtCore:
> https://codereview.qt-project.org/#change,74745 . But it's a lot of
> (tedious) work to do for the other modules t
On Monday 06 January 2014 16:08:12 Allan Sandfeld Jensen wrote:
> On Monday 06 January 2014, Oswald Buddenhagen wrote:
> > On Sat, Dec 28, 2013 at 02:51:41PM -0300, Lisandro Damián Nicanor Pérez
>
> Meyer wrote:
> > > The archs arm, i386, i686, mips and s390 can get their memory exhausted
> > > wh
Hello,
we (some of us at Digia) have been working on Enginio - a convenient cloud
storage for Qt applications. Since the library is actively maintained we would
like to integrate it into the official Qt release for Qt 5.3.
For those curious now, there is already the option to get it when using
Thanks, that’s helpful. I didn’t think to just use an import in the qml test
file itself. I’ll test today, but it doesn’t seem like that would work with
nested objects. If it does then great, but rather non-intuitive magic.
Also, currently I’m just stubbing out qml objects to represent c++ ob
Hi,
Today I've stumbled another time over QT_NO_DEBUG_STREAM ... you know, one of
this infamous QT_NO macros that we keep 'alive' by mere copy and paste :) And
because it's a new year, a new dawn , etc, I decided to do something about it.
- I'm pretty sure nobody could compile QtCore with QT_NO
On 04.01.2014 17:04, Pau Garcia i Quiles wrote:
> But it says nothing about building the installer for the Qt VS Add-in.
That's because the open source repository doesn't contain the files
needed to build the installers. The actual installer files where never
publicly released, because they are
cd qt5
git checkout release
git submodule update
git submodule foreach 'git clean -dxf' // this doesn't work properly
git submodule foreach 'git reset --hard'
git submodule foreach 'git checkout release ||:'
git submodule foreach 'git pull --rebase ||:'
./configure -developer-build -confirm-license
On Monday 06 January 2014, Oswald Buddenhagen wrote:
> On Sat, Dec 28, 2013 at 02:51:41PM -0300, Lisandro Damián Nicanor Pérez
Meyer wrote:
> > The archs arm, i386, i686, mips and s390 can get their memory exhausted
> > when building QtWebkit, so at least on Debian we are replacing -g with
> > -gs
Hello Sze-Howe,
I have re-opened this bug and added a comment, thanks.
Caroline
From: Sze Howe Koh [szehowe@gmail.com]
Sent: Monday, January 06, 2014 3:44 PM
To: Chao Caroline
Cc: Joshua Kolden; development@qt-project.org
Subject: Re: [Development] qte
On Mon, Jan 06, 2014 at 02:01:53PM +0100, Frederik Gladhorn wrote:
> we'd like to make Enginio part of the release. qtenginio behaves like any
> other module. What are the criteria for it to become part of a regular
> release?
>
you should start a separate thread for that. nobody complains, lars
On Mon, Dec 30, 2013 at 03:36:13PM +0100, Kurt Pattyn wrote:
> I noticed that the oldest open item in Gerrit dates back to 7 October 2011.
> There are around 2000 items still open. I suppose a lot of them are not
> relevant anymore.
>
> Wouldn’t it a good idea that the maintainers of the differe
On 6 January 2014 20:40, Chao Caroline wrote:
> Hi,
>
> The TestCase doc should refer to QtQuickTest and not QtTest indeed, please
> log a documentation bug for it.
>
> Also I have attached a small example to get you started, with a source
> component to test under src/qml and the test file unde
On Sat, Dec 28, 2013 at 02:51:41PM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> The archs arm, i386, i686, mips and s390 can get their memory exhausted when
> building QtWebkit, so at least on Debian we are replacing -g with -gstabs for
> those archs. As I understand this comes from a sug
Hi,
we'd like to make Enginio part of the release. qtenginio behaves like any
other module. What are the criteria for it to become part of a regular
release?
(I can do the merge myself, but I wouldn't mind if it was part of the big
merge etc.)
Greetings,
Frederik
Fredag 3. januar 2014 13.35.
Hi,
The TestCase doc should refer to QtQuickTest and not QtTest indeed, please log
a documentation bug for it.
Also I have attached a small example to get you started, with a source
component to test under src/qml and the test file under specs/qml. It should
work with both qmltestrunner or a Q
On Thursday 02 January 2014 21:04:27 Jiergir Ogoerg wrote:
> buffer() // getter
> buffer_set(..) // setter
> BufferSupportsFind() // bool
>
> selection() // getter
> SelectionMove(..) // move selection
> selection_set(..) // setter
> SelectionUnset(...) // unset something
You might find the std p
On Monday 30 December 2013 00:24:58 Jiergir Ogoerg wrote:
> And because of that I have to (can) resize() it,
A better way is to reserve() + push_back(), but IIRC QVector never contains
uninitialised memory. std::vector, however, does, and expands to less code,
too, with private element types suc
On Monday 30 December 2013 02:42:25 Konstantin Ritt wrote:
> > the 1st one is created automatically when the parent class
>
> is created which holds the vector, and a second vector is created when
> calling "fromRawData()" when I got the data on the heap to replace
> the vector's buffer.
>
> >Fr
30 matches
Mail list logo