Em qui 20 fev 2014, às 06:21:44, Sarajärvi Tony escreveu:
> QDEBUG : tst_QTcpSocket::blockingIMAP(WithSocks5Proxy SSL)
> QSocks5SocketEngine(0x99e730) _q_controlSocketReadNotification more bytes
> available, calling _q_controlSocketReadNotification() again , read
> notifications enabled? false
Thi
Em sex 28 fev 2014, às 21:15:51, Harri Porten escreveu:
> > If not, then Laszlo's previous offer of rewriting syncqt in Python becomes
> > a lot more attractive.
>
> JavaScript is no option? Our product bootstraps an interpreter (Qt has
> several;) that can be used to perform such build tasks. No
On 2014-02-28 05:41, Koehne Kai wrote:
> While contemplating about how to best get rid of qPrintable I came up with
> the following proposal:
>
> https://bugreports.qt-project.org/browse/QTBUG-37146
Honestly, I'm pretty happy with the qPrintable way of doing things. (At
least, I am pretty sure I
On Fri, 28 Feb 2014, Thiago Macieira wrote:
Em sex 28 fev 2014, às 18:30:24, Hausmann Simon escreveu:
Note that this is not a new dependency but has been there since Qt 5.0.0
(when v8 required python)
Right.
But now we need Python for a single file, in something that is almost entirely
under
On 2014-02-28 11:46, Thiago Macieira wrote:
> Another solution is to add another wrapper, like qPrintable, [...]
Can I vote again for qRawUtf8? (Feel free to bikeshed the name; the
point is that the implementation is .toUtf8.constData().) This would
solve the printf case equally well *and* would
Em sex 28 fev 2014, às 18:30:24, Hausmann Simon escreveu:
> Note that this is not a new dependency but has been there since Qt 5.0.0
> (when v8 required python)
Right.
But now we need Python for a single file, in something that is almost entirely
under our control. Any chance we can remove the b
Note that this is not a new dependency but has been there since Qt 5.0.0 (when
v8 required python)
Simon
Opprinnelig melding
Fra: Thiago Macieira
Sendt: 18:04 fredag 28. februar 2014
Til: development@qt-project.org
Emne: [Development] Python required to build Qt from source packages
We wen
Em sex 28 fev 2014, às 19:00:20, Olivier Goffart escreveu:
> On Friday 28 February 2014 09:29:53 Thiago Macieira wrote:
> > Em sex 28 fev 2014, às 18:09:36, Olivier Goffart escreveu:
> > > > So:
> > > > qDebug("%ls\n", qWPrintable(s));
> > >
> > > That will not work because sizeof(wchar_t)
On Friday 28 February 2014 09:29:53 Thiago Macieira wrote:
> Em sex 28 fev 2014, às 18:09:36, Olivier Goffart escreveu:
> > > So:
> > > qDebug("%ls\n", qWPrintable(s));
> >
> > That will not work because sizeof(wchar_t) is 4 on linux.
> > (and QString::vsprintf wands %ls to be ushort*)
>
> Then
Em sex 28 fev 2014, às 18:09:36, Olivier Goffart escreveu:
> > So:
> > qDebug("%ls\n", qWPrintable(s));
>
> That will not work because sizeof(wchar_t) is 4 on linux.
> (and QString::vsprintf wands %ls to be ushort*)
Then we fix QString::vsprintf.
We can use %S, which is an alias for %ls on r
On Friday 28 February 2014 08:46:12 Thiago Macieira wrote:
> Em sex 28 fev 2014, às 08:17:54, Thiago Macieira escreveu:
> > Em sex 28 fev 2014, às 13:00:31, Koehne Kai escreveu:
> > > > -Original Message-
> > > > From: development-bounces+kai.koehne=digia@qt-project.org
> > > > [...]
>
We went through great pains to make sure that Perl wasn't required to build Qt
from released sources, but it looks like a dependency on Python crept back in,
for a single file (RegExpJitTables.h in qtdeclarative/src/qml).
Can we commit the generated file to the repository, or generate it during
Em sex 28 fev 2014, às 08:17:54, Thiago Macieira escreveu:
> Em sex 28 fev 2014, às 13:00:31, Koehne Kai escreveu:
> > > -Original Message-
> > > From: development-bounces+kai.koehne=digia@qt-project.org
> > > [...]
> > > qDebug("%ls", string.utf16());
> >
> > This will actually not co
Em sex 28 fev 2014, às 17:35:46, Giuseppe D'Angelo escreveu:
> Il 28/02/2014 17:21, Thiago Macieira ha scritto:
> > Please make sure they are properly namespaced: all symbols exported from
> > our libraries should start with Q or q.
>
> Not really, these symbols are the GL1 + GLES2 + EGL subset (s
> -Original Message-
> From: development-bounces+tvaneerd=rim@qt-project.org
> [mailto:development-bounces+tvaneerd=rim@qt-project.org] On
> Behalf Of Thiago Macieira
> Sent: Friday, February 28, 2014 11:26 AM
> To: development@qt-project.org
> Subject: Re: [Development] Binary Co
Il 28/02/2014 17:21, Thiago Macieira ha scritto:
Please make sure they are properly namespaced: all symbols exported from our
libraries should start with Q or q.
Not really, these symbols are the GL1 + GLES2 + EGL subset (so that apps
using glFoo* will find them in QtGui).
See
https://code
Em sex 28 fev 2014, às 14:29:05, Sebastian Lehmann escreveu:
> This can be discussed for QBA and QString separately. Typically you
> don't have null chars in a QString and _most_ strings only contain
> printable chars (except '\n'), yet when you debug them (again, that's
> what qDebug & frien
> Can you create a bug report, so it's not forgotten?
Done: https://bugreports.qt-project.org/browse/QTBUG-37163
I tried to put it in an RFC kind of bug report, but I guess it's a bit
incomplete to be called an RFC. Someone might want to add details, or
rename it if it may not be called RFC
Em sex 28 fev 2014, às 13:08:26, Koehne Kai escreveu:
> I doubt any sane application on the assumption how QDebug formats
> QByteArray's with 0's in it
Applications may have assumptions on how QByteArrays with backslashes are
printed...
--
Thiago Macieira - thiago.macieira (AT) intel.com
Soft
On 2014-02-28 04:16, Koehne Kai wrote:
>> [...]
>> What about adding e.g. qRawUtf8() which would do like qPrintable but
>> toUtf8() instead of toLocal8Bit()?
>
> I've been pondering with this something similar too, since
>
> qDebug("%s", string.toUtf8().constData());
>
> isn't really short and cris
Em sex 28 fev 2014, às 11:10:41, André Somers escreveu:
> To me, it doesn't sound reasonable to expect an unqualified &func to
> stay source compatible. If you want your code to be source compatible
> with future vesions and you use function pointers, I'd suggest to always
> use the longer, ugly ca
Em sex 28 fev 2014, às 11:49:56, Agocs Laszlo escreveu:
> I realize however that there are genuine concerns around exporting all the
> symbols from QtGui, and that the approach will most likely not scale to
> other platforms.
Please make sure they are properly namespaced: all symbols exported from
Em sex 28 fev 2014, às 13:00:31, Koehne Kai escreveu:
> > -Original Message-
> > From: development-bounces+kai.koehne=digia@qt-project.org
> > [...]
> > qDebug("%ls", string.utf16());
>
> This will actually not compile with gcc, because we tell the compiler
> explicitly we're printf-co
Yes, it should be pretty simple: Just remove qopenglproxy_win.cpp and leave
everything else in place. This provides an excellent foundation for continuing
the feature with a different approach.
The other modules are not an issue since the related changes have not been
merged (with the exception
Hi Andre,
On Thursday 27 February 2014 20:36:51 andre wrote:
> On Thu, Feb 27, 2014 at 02:28:26PM +, Sean Harmer wrote:
> You miss the point that Qt "users" are typically developers themselves,
> who have not just their own development machine to take care of (plus
> their corporate IT...) but
On Friday 28 February 2014 14:53:02 Friedemann Kleint wrote:
> Hi,
>
> >Thank you. Sorry this means it gets reverted for now. I think we all
>
> agree that having the common ES2 / desktop 2 subset magically work
> everywhere on Windows
>
> Ok, technically speaking, how do we get this through th
Hi,
how about omitting quotes automatically for anything else but Q[C]Debug?
The common problem seems to me that warning messages automatically get
quotes which looks semi-professional:
qWarning() << "Cannot open:" << file.name() << ": " << file.errorString();
typically results in:
Cannot open
Hi,
>Thank you. Sorry this means it gets reverted for now. I think we all
agree that having the common ES2 / desktop 2 subset magically work
everywhere on Windows
Ok, technically speaking, how do we get this through the CI (considering
the modules which have follow-up changes ..can we leave t
Hi Laszlo,
On Friday 28 February 2014 12:25:19 Agocs Laszlo wrote:
> Keep in mind, though, that the primary goal of QtGui is to enable Qt Quick
> and related modules, like Controls, which are all based on OpenGL [ES] 2.0.
> Supporting 3rd party renderers that explicitly rely on GL3+ features and
>
Hi Laszlo,
On Friday 28 February 2014 13:27:40 Agocs Laszlo wrote:
> It is most likely better to postpone this whole feature, especially since it
> is not really user visible anyhow, and instead try mitigating the pain
> using some less intrusive methods for the time being, agreed. I am
> currentl
Hi Sean,
It is most likely better to postpone this whole feature, especially since it is
not really user visible anyhow, and instead try mitigating the pain using some
less intrusive methods for the time being, agreed. I am currently preparing a
revert commit.
As for the role of qtbase and QtG
> -Original Message-
> From: development-bounces+kai.koehne=digia@qt-project.org
>
> [...]
> Of course, this feature should be disabled per default for compatibility
> reasons, unless you say we don't have guarantees for the actual format of
> qDebug output (I mean, it's for debuggin
Quoting Koehne Kai :
>> -Original Message-
>> From: development-bounces+kai.koehne=digia@qt-project.org
>>
>> [...]
>> Of course, this feature should be disabled per default for compatibility
>> reasons, unless you say we don't have guarantees for the actual format of
>> qDebug output
> -Original Message-
> From: development-bounces+kai.koehne=digia@qt-project.org
> [...]
> qDebug("%ls", string.utf16());
This will actually not compile with gcc, because we tell the compiler
explicitly we're printf-compatible:
error: format '%ls' expects argument of type 'wchar_t*',
On 28 Feb 2014, at 13:16, Björn Breitmeyer wrote:
> Since i haven't followed the discussion in detail, based on which assumptions
> do you plan to use a dynamic switch. Exported GL Symbols from QtGui sounds
> like a very bad idea. Relying on QOpenGLFunctions makes more sense.
Agreed.
>
> But
Keep in mind, though, that the primary goal of QtGui is to enable Qt Quick and
related modules, like Controls, which are all based on OpenGL [ES] 2.0.
Supporting 3rd party renderers that explicitly rely on GL3+ features and are
not interested in true portability (e.g. between desktop and mobile)
Since i haven't followed the discussion in detail, based on which assumptions
do you plan to use a dynamic switch. Exported GL Symbols from QtGui sounds
like a very bad idea. Relying on QOpenGLFunctions makes more sense.
But right now i don't really see how this buys anybody anything, you usually
You cannot include multiple GL headers. In a dynamic build you have the desktop
GL header ( + qopenglext.h), just like in a 'desktop' build. This does not
change at all.
Runtime errors are not a problem since all ES-specific paths are guarded by the
appropriate condition.
I realize however tha
On Thursday, 2014-02-27, 16:18:32, Thiago Macieira wrote:
> Em sex 28 fev 2014, às 00:39:05, Tomasz Olszak escreveu:
> > 2014-02-28 0:24 GMT+01:00 Thiago Macieira :
> > > Em qui 27 fev 2014, às 22:21:28, Tony Van Eerd escreveu:
> > >> Thanks, but it seems I don't have permissions? :-(
> > >
> > >
Hi,
I would really welcome this feature.
While we're at it, we should also add something like escape() and
noeascape() to handle special chars. Especially the null char will
truncate the whole line due to the way the internal buffer gets
finally printed in the QDebug destructor, which annoy
On Thursday 27 February 2014 17:09:59 Thiago Macieira wrote:
> Maybe techbase is deprecated and everything is moving to the newer wikis.
It's not deprecated.
--
David Faure | david.fa...@kdab.com | Managing Director KDAB France
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 8
Hi,
While contemplating about how to best get rid of qPrintable I came up with the
following proposal:
https://bugreports.qt-project.org/browse/QTBUG-37146
This is Qt 5.4 material. Anyhow, I'm keen on getting comments :) Of course
about the API as such, but also whether it can be implemented i
Hi Gunnar,
On Friday 28 February 2014 07:14:24 Gunnar Sletta wrote:
> On 27 Feb 2014, at 22:17, Agocs Laszlo wrote:
> > On Thu, Feb 27, 2014 at 02:28:26PM +, Sean Harmer wrote:
> >> The apparent problem that this is attempting to address is the need for
> >> both ANGLE and desktop OpenGL buil
Tony Van Eerd schreef op 27-2-2014 21:06:
> Sorry, there is probably a KDE email list or something that I should post
> this to, but I know it is very closely related to Qt:
>
> On http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B
> there is:
>
> You cannot...
>
> - For ex
> -Original Message-
> From: development-bounces+kai.koehne=digia@qt-project.org
>
> [...]
> What about adding e.g. qRawUtf8() which would do like qPrintable but
> toUtf8() instead of toLocal8Bit()?
I've been pondering with this something similar too, since
qDebug("%s", string.toUtf
> Qt 5.3 Alpha is now out and plan is to release Beta1 during the next few
> weeks. That’s why it is really important to recognize the issues which
> must be fixed before we can put beta1 out. There is already some issues
> linked in the beta1 metabug, see
> https://bugreports.qt-project.org/browse
Qt3D is not included in Qt 5.3 (Alpha)?!
Disappointed
Helmut
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
47 matches
Mail list logo
