Marc, I'm not sure if you're arguing for or against nullptr :-)...
On 2015-02-10 18:23, Marc Mutz wrote:
On Tuesday 10 February 2015 20:13:12 André Pönitz wrote:
Can't you simply wait until 'nullptr' is available?
No.
For a simple reason: using nullptr (Q_ or not) is more expressive than
On 2015-02-10 18:33, Thiago Macieira wrote:
Eh... have you tried to convert a UTF-8 or UTF-16 or UCS-4 string to the
locale's narrow character set without using QString?
Yup... we would need to standardize libiconv (or an equivalent) for that
:-).
Have you tried to convert a number to
On 2015-02-10 18:40, Marc Mutz wrote:
On Tuesday 10 February 2015 22:26:50 Thiago Macieira wrote:
It's not insurmountable. I can think of two solutions:
1) pre-allocate enough space for the UTF-16 data (strlen(utf8) * 2), so
that the const functions can implicitly write to the UTF-16 block
On 2015-02-06 09:22, Robert Knight wrote:
It is just not practical to ship a second copy of dozens
of system libraries, all built as part of QtWebEngine. This is a nightmare
in terms of disk space, RAM use, potential for symbol conflicts and
delivery of security updates.
These are all valid
On 2015-02-02 17:51, Thiago Macieira wrote:
On Monday 02 February 2015 14:29:21 Matthew Woehlke wrote:
* Q_DECL_EQ_DEFAULT - really discouraged
I can't think of any case where you could use this and let the code still
compile in C++98, so don't use it
I'd actually like to see this used
On 2015-01-08 17:33, Thiago Macieira wrote:
I think it's time to institute a policy that we should fix our sources to use
the new C++11 keywords. I'd like to propose the following.
Policy per keyword:
* Q_NULLPTR - strongly encouraged
Use it whenever your literal zero is a null
On 2014-11-21 05:22, Renaud wrote:
I saw in your small example that you use updateGL(), I suggest you to
change it to update().
It may help the performance on Qt5.
Hoo boy... I'm not sure why this would work better on Qt4 (see possible
idea, below), but updateGL() *IMMEDIATELY* calls your
On 2014-11-17 08:57, Pau Garcia i Quiles wrote:
On Mon, Nov 17, 2014 at 1:57 PM, Lopes Yoann wrote:
I’d recommend to use libav (https://libav.org) to do this.
I would use ffmpeg instead of libav (ffmpeg merges every commit from libav
+ their own)
Agreed. I did my own research when I had to
On 2014-07-27 02:00, liuyanghejerry wrote:
I'm pretty new to QtMultimedia, and I searched around found no way to
encode videos from QImage or QPixmap.
There is indeed one QMediaRecorder, however it is only possible to
record videos from QCamera, which is actually inherits QMediaObject, and
On 2014-06-13 12:48, Oswald Buddenhagen wrote:
Oswald Buddenhagen wrote:
the default orientation is meant to link the width, as i think that's
the by far more common case. whether one calls that horizontal or
vertical is an awesome bikeshed, as we have seen in various discussions
about
On 2014-04-16 03:18, Volker Krause wrote:
On Tuesday 15 April 2014 08:02:56 Thiago Macieira wrote:
In other words: use QBasicAtomicPointer.
As mentioned on https://codereview.qt-project.org/#change,83272 Kevin Funk
measured the difference between the current approach and using atomics using
On 2014-04-09 03:24, Volker Krause wrote:
- thread-safety: we might be setting the callback at a point where already
several threads are active. For us it's less relevant that we don't miss a few
calls from other threads there (attaching at runtime happens at an arbitrary
point in time
On 2014-04-03 04:47, Thomas McGuire wrote:
How about adding a Versions box to the sidebar that gives convenient
links to all other versions of the QProcess documentation?
Yes, please; that's what Python does and it seems to work well. (You
could even add a cookie to always take the user to the
On 2014-03-11 05:01, Pasion Jerome wrote:
Short summary: We will be redirecting viewers of Qt 5.0 and Qt 5.1
documentation
to Qt 5 documentation. Subsequently, we will remove the 5.0 and 5.1
documentation
from qt-project.org and we will place future Qt 5.x documentation in
Qt 5
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 crisp ... But I
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
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 2014-02-25 12:40, Thiago Macieira wrote:
Em ter 25 fev 2014, às 11:33:00, Oswald Buddenhagen escreveu:
I.e., nothing changes. I propose this branch stay named dev, for clarity
of purpose, not master.
i don't think the clarity buys us much. like the rest of the branch
naming stuff, it is
On 2014-02-25 14:12, Thiago Macieira wrote:
Also, I don't know of any project that has a CI-controlled integration.
What does that have to do with branch naming conventions?
I'll grant that there is variance in the exact definition of master.
Less so in the *existence* of the same.
--
On 2014-02-21 04:20, Koehne Kai wrote:
This is a heads up that you should avoid using qPrintable() together
with qDebug/QDebug for localized strings.
The issue is that qPrintable() does '.toLocal8Bit()', while
QDebug/qDebug and friends nowadays expect const char * arguments to
be UTF-8
On 2014-02-16 12:02, Thiago Macieira wrote:
Em dom 16 fev 2014, às 15:09:49, Giuseppe D'Angelo escreveu:
I guess that for Kate's purposes a small wrapper class around QRegExp
+ QRegularExpression would suffice for supporting both syntaxes. For
the future, we could instead think of adding
On 2014-02-14 07:12, Giuseppe D'Angelo wrote:
On 13 February 2014 18:52, Matthew Woehlke wrote:
Why does the Qt5 QRegExp documentation not mention QRegularExpression?
Because it's an oversight, I guess... patches for the docs are more
than welcome! :)
Naturally :-). Comments like the above
On 2014-02-13 11:58, Matthew Woehlke wrote:
On 2014-02-13 11:38, Milian Wolff wrote:
QRegularExpression in Qt5 does support look-behind. [snip]
There's a new regex class? Interesting; first I'd heard of it.
Why does the Qt5 QRegExp documentation not mention QRegularExpression?
Also
On 2014-02-05 12:19, Thiago Macieira wrote:
Em qua 05 fev 2014, às 10:37:27, Robert Knight escreveu:
The idea was to silently return a default-constructed type.
I'm not keen on that. Aside from adding extra restrictions to the
types that the class can be used with as you mention,
it runs the
On 2014-02-03 19:26, Thiago Macieira wrote:
Em seg 03 fev 2014, às 15:29:06, Matthew Woehlke escreveu:
If I were designing such an API from scratch, I'd probably these days go
with something like the std::expected approach. Bonus points for
implicitly converting to the value type.
Then you
On 2014-02-04 15:05, Tony Van Eerd wrote:
Yes, for QOptional you wouldn't want to name it 'isOkay()'. But you
*will* have the problem of ambiguous implicit conversion with
QOptionalbool, which I assume will be allowed even if there is no
QString::toBool(). Alternatively you could omit implicit
On 2014-02-04 15:07, Thiago Macieira wrote:
Em ter 04 fev 2014, às 13:37:44, Matthew Woehlke escreveu:
Yeah, I'm not entirely on board with the whole check the result or your
program dies idea. Qt doesn't do that now; I definitely don't feel like
it needs to be added. (I guess QOptional
On 2014-02-04 17:06, Thiago Macieira wrote:
Em ter 04 fev 2014, às 16:04:11, Matthew Woehlke escreveu:
If it were up to me, given an operator* (which is only one more
character of typing, after all), I wouldn't provide *any* (additional)
convenience access to the value. For roughly this reason
On 2014-02-04 18:00, Matthew Woehlke wrote:
(I might go with 'ifInvalid' though... )
Actually, I'll encourage defaultValue, for consistency with the
containers (unless those got renamed?).
On 2014-02-04 17:06, Thiago Macieira wrote:
Em ter 04 fev 2014, às 16:04:11, Matthew Woehlke escreveu
301 - 329 of 329 matches
Mail list logo
