Kevin Kofler wrote:
> it looks like the Qt-x64 project, which used to build Qt binaries for
> 32-bit and 64-bit Windows, including compiler/platform combinations not
> supported by the official releases (in particular, there were MinGW64
> builds for both Qt 4 and Qt 5), was not only discontinued,
Hi,
it looks like the Qt-x64 project, which used to build Qt binaries for 32-bit
and 64-bit Windows, including compiler/platform combinations not supported
by the official releases (in particular, there were MinGW64 builds for both
Qt 4 and Qt 5), was not only discontinued, but wiped their enti
On Thursday 09 April 2015 11:45:20 Thiago Macieira wrote:
> It wasn't a gratuitous change, though. It was required so I could move some
> QStringList methods to QList. Since qlist.h needs to include
> qstringlist.h to ensure the full specialisation of
> QListSpecialMethods is present before QList
On Thursday 09 April 2015 13:20:41 Matthew Woehlke wrote:
> Slightly off-topic: included ? Ick, that's one
> change I'm glad to see.
Yes, because it had inline operator>>(QDataStream&, const QStringList &) and
qdatastream.h requires qiodevice.h.
However, that operator was useless, since qdatast
On 2015-04-09 07:04, André Somers wrote:
> I think it *is* reasonable to remove such indirect includes if they are
> not needed for Qt itself. However, it is worth looking into how the
> thing was documented to begin with. In the case of qHash(), the
> documentation for that one actualy says the
Hello,
I have a question about QInstaller. How can I make the Uninstaller check
exe is running or not before uninstalling? I can do this with installing
process but I can not write correct script (installscript.qs) for
uninstalling process.
Should I write another script for Uninstaller? Actually,
On Thursday 09 April 2015 14:47:06 kl222 wrote:
> -I../../include/QtCore -I../../include/QtCore/5.5.0
> -I../../include/QtCore/5.5.0/QtCore -Itmp -Iglobal -I../3rdparty/pcre
> -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4
> -I../3rdparty/sha3 -I.moc/release -I../../mkspecs/win32-g+
On Thursday 09 April 2015 11:20:30 Frank Osterfeld wrote:
> > My vote obviously goes to allowing them.
>
> I had to fix includes when building client code with 5.5 branch (coming from
> 5.4.1), so this is an actual issue right now, not just a theoretical one. I
> can do more research which headers
We want to give you the code, here it is :)
https://codereview.qt-project.org/#/admin/projects/qt-labs/qtquickcontrols2
It is in the qt-labs namespace which means "no guarantees, no commitment,
we'll rename and break everything".
Besides this little warning, I think there is a great repository t
On Thursday, April 09, 2015 01:19:24 PM Aleix Pol wrote:
> On Thu, Apr 9, 2015 at 10:27 AM, Tomasz Siekierda
wrote:
> > On 8 April 2015 at 17:35, Oswald Buddenhagen
> >
> > wrote:
> >> On Wed, Apr 08, 2015 at 04:39:52PM +0200, Frederik Gladhorn wrote:
> >>> On Wednesday, April 08, 2015 04:30:23
On Thursday 09 April 2015 12:46:11 Simon Hausmann wrote:
> > So, by this line of reasoning, the list of #includes in a public header
> > file must be a monotonically increasing function of the Qt version.
> > Since we're keeping SC even across major versions these days, we'll thus
> > slowly conver
On Thursday 09 April 2015 13:04:21 André Somers wrote:
> I think it is reasonable to remove such indirect includes if they are
> not needed for Qt itself. However, it is worth looking into how the
> thing was documented to begin with. In the case of qHash(), the
> documentation for that one actu
On Thu, Apr 9, 2015 at 10:27 AM, Tomasz Siekierda wrote:
> On 8 April 2015 at 17:35, Oswald Buddenhagen
> wrote:
>> On Wed, Apr 08, 2015 at 04:39:52PM +0200, Frederik Gladhorn wrote:
>>> On Wednesday, April 08, 2015 04:30:23 PM Oswald Buddenhagen wrote:
>>> so ideally we find the perfect new name
On Thursday 9. April 2015 11.52.31 Simon Hausmann wrote:
> On Wednesday 8. April 2015 23.45.29 Sze Howe Koh wrote:
> [...]
>
> > Going off on a slight tangent:
> > https://doc.qt.io/qt-5/qjsvalue.html#toVariant says that an Object "is
> > converted to a QVariantMap. Each property is converted to a
Simon Hausmann schreef op 9-4-2015 om 10:39:
> On Wednesday 8. April 2015 14.34.03 Olivier Goffart wrote:
>> On Wednesday 08 April 2015 13:13:19 Marc Mutz wrote:
>>> Hi,
>>>
>>> I have in the past fixed #include mistakes such as #include
>>> for QSharedDataPointer, and even though each time the
>>
Hi,
I have been looking at how the DirectFB QPA platform inside QT works.
I have seen how inside QDirectFbIntegration::connectToDirectFb() the
DirectFB interface is initialised followed by the screen and input module.
On my platform atleast, when I create a widget, I see a QDirectbWindow
being cr
On Thursday 9. April 2015 12.34.17 Marc Mutz wrote:
> On Thursday 09 April 2015 10:39:57 Simon Hausmann wrote:
> > On Wednesday 8. April 2015 14.34.03 Olivier Goffart wrote:
> > > On Wednesday 08 April 2015 13:13:19 Marc Mutz wrote:
> > > > Hi,
> > > >
> > > > I have in the past fixed #include mis
On Thursday 09 April 2015 10:39:57 Simon Hausmann wrote:
> On Wednesday 8. April 2015 14.34.03 Olivier Goffart wrote:
> > On Wednesday 08 April 2015 13:13:19 Marc Mutz wrote:
> > > Hi,
> > >
> > > I have in the past fixed #include mistakes such as #include
> > > for QSharedDataPointer, and even t
On Wednesday 8. April 2015 23.45.29 Sze Howe Koh wrote:
[...]
> Going off on a slight tangent:
> https://doc.qt.io/qt-5/qjsvalue.html#toVariant says that an Object "is
> converted to a QVariantMap. Each property is converted to a QVariant,
> recursively". However, calling toVariant() on an Error ob
> On 08 Apr 2015, at 13:13, Marc Mutz wrote:
>
> Hi,
>
> I have in the past fixed #include mistakes such as #include
>
> for QSharedDataPointer, and even though each time the issue came up that this
> is a SiC change (but only for users that unduly rely on indirect includes),
> so
> far t
On 08-Apr-15 17:45, Sze Howe Koh wrote:
> May I suggest adding a bit of documentation on our side to help people
> discover the features? Currently,
> http://doc.qt.io/qt-5/qjsengine.html#script-exceptions only recommends
> using toString() to probe errors. That's an ideal place to add a list
> of
On Wednesday 8. April 2015 14.34.03 Olivier Goffart wrote:
> On Wednesday 08 April 2015 13:13:19 Marc Mutz wrote:
> > Hi,
> >
> > I have in the past fixed #include mistakes such as #include
> > for QSharedDataPointer, and even though each time the
> > issue came up that this is a SiC change (but
On Thu, Apr 9, 2015 at 7:47 AM, kl222 wrote:
> Environment:
>
> Operation System: windows7 Ultimate
>
> Msys2: MINGW32_NT-6.1 l-PC 2.1.0(0.287/5/3) 2015-04-05 21:26 i686 Msys
>
> Bash: GNU bash，version 4.3.33(3)-release (i686-pc-msys)
>
> Gcc: gcc.exe (Rev5, Built by MSYS2 project) 4.9.2
>
> Perl:
On 8 April 2015 at 17:35, Oswald Buddenhagen
wrote:
> On Wed, Apr 08, 2015 at 04:39:52PM +0200, Frederik Gladhorn wrote:
>> On Wednesday, April 08, 2015 04:30:23 PM Oswald Buddenhagen wrote:
>> so ideally we find the perfect new name for both module and
>> repository. Sadly we didn't manage to com
24 matches
Mail list logo
