On 18/11/2020 07.34, Lisandro Damián Nicanor Pérez Meyer wrote:
Possibly also:
assistant6 for reading Qt 6 help files when not using Qt Creator
designer6 for those not using Qt Creator and needing to use Qt 6 plugins
Offtopic, but I wonder how much those standalone apps are still
On 25/08/2020 15.15, André Pönitz wrote:
On Mon, Aug 24, 2020 at 09:46:43AM +0200, Mathias Hasselmann wrote:
C++ also has a solution for that problem: [1]
https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/
AAA is a non-solution from the ivory tower.
On 25/08/2020 02.22, Mathias Hasselmann wrote:
I'd really enjoy implementing list models without having
to litter static casts all over the place. Well, but seems that chance
got missed once again with qsizetype still being signed.
That's intentional. There are problems with unsigned index
On 25/08/2020 05.58, Giuseppe D'Angelo via Development wrote:
Il 25/08/20 07:49, Thiago Macieira ha scritto:
But how about models? This is an honest question. Does it make sense for
tables and lists that big? Note that an item*view* has a purpose of
being viewed, so how does one display such
On 25/08/2020 01.24, Philippe wrote:
But then there would be the need to make QAbstractSlider be able to
handle 64 bit quantities too.
Well, since you mentioned it:
https://github.com/Kitware/qtextensions/blob/master/widgets/qtDoubleSlider.h
No, that isn't a two-headed slider, it's a slider
On 16/06/2020 13.37, Ville Voutilainen wrote:
On Tue, 16 Jun 2020 at 20:27, Kevin Kofler wrote:
Edward Welbourne wrote:
Kevin Kofler (16 June 2020 12:08)
What "shiny new features"? All that a real-world application such as
KWrite really needs from the operating system has been there at least
On 09/06/2020 14.38, Thiago Macieira wrote:
On Tuesday, 9 June 2020 00:27:35 PDT Shawn Rutledge wrote:
FWIW the configuration mechanism seems a bit less friendly so far with all
those -DSHOUTED options like -DFEATURE_developer_build=ON instead of
configure -developer-build.
The syntax of
Can I get someone to review
https://codereview.qt-project.org/c/qt/qtbase/+/302251, please? This
fixes https://bugreports.qt.io/browse/QTBUG-80577, which has been an
intermittent problem for my users since last year.
--
Matthew
___
Development
On 09/06/2020 05.05, Alexandru Croitor wrote:
On 09/06/2020 04.38, Shawn Rutledge wrote: >> At least json is easier to parse, if we try to write other tooling.>
> That's true. But using tooling to forever generate cmake files from
json also comes with its downsides (maintenance, inability to
On 09/06/2020 03.27, Shawn Rutledge wrote:
FWIW the configuration mechanism seems a bit less friendly so far
with all those -DSHOUTED options like -DFEATURE_developer_build=ON
instead of configure -developer-build. But there is cmake-gui, which
generates checkboxes for all the options after you
On 09/06/2020 03.55, Joerg Bornemann wrote:
The description of QT_NO_MAKE_TESTS is: "Should tests be built as part
of the default 'all' target." Meaning this variable controls whether
tests are build by default.
Might I suggest a less obtuse name? Something along the lines of
On 28/05/2020 13.19, Adam Light wrote:
if a .cpp file has a #include "myclass.moc" type statement, that .cpp
file has to be processed by moc
Huh? *Why*?
AFAIK that's just... wrong.
MOC needs to process files that do metaobject things (e.g. use
Q_OBJECT). Including a .moc in a .cpp does not
On 27/05/2020 11.09, Giuseppe D'Angelo via Development wrote:
Sure, augmenting the docs would help. But the whole
point of the API is for its usage to be straightforward. If you do
QTransform t;
t.translate();
t.rotate();
t.scale();
auto result = t.map(foo);
the "obvious" meaning should be
On 27/05/2020 04.34, Edward Welbourne wrote:
Matthew Woehlke (26 May 2020 18:15) wrote:
The documentation is not clear if the scale, rotate, etc. methods of
QTransform apply *before* or *after* whatever the QTransform is already
doing. The bug report indicates that they are applied *first
On 26/05/2020 13.33, Edward Welbourne wrote:
It turns out that either way round works
fine, as long as you're consistent. Which QTransform appears to be; and
its docs correctly describe it the way it is.
They are? It was *not at all* clear to me in what order the transforms
would be applied.
On 26/05/2020 12.06, Thiago Macieira wrote:
On Tuesday, 26 May 2020 08:59:09 PDT Thiago Macieira wrote:
Neither QMatrix nor QTransform have seen any change since the Qt 5.0
repository import that was related to the underlying math. Only licensing
and C++ updates.
The task
On 25/05/2020 07.37, Edward Welbourne wrote:
I would just call it QUtf8View, since (see below) I don't see value in a
separate QUtf8String for it to be a view into
On the one hand...
std::string_view is not a view into a std::string. A std::string is a
*container* for text, a
On 22/05/2020 13.43, Jason H wrote:
How about I just pay - which my company already does? The lagging
mobile support has us considering moving away from Qt. I think this
decision would confirm our direction and only hasten our departure
from the Qt ecosystem.
I guess to some degree it depends
On 20/05/2020 13.15, Lars Knoll wrote:
On 20 May 2020, at 17:34, Matthew Woehlke wrote:
On 20/05/2020 09.11, Lars Knoll wrote:
Here’s what we will do:
* QList and QVector are aliases for each other
* We make QList the main type, and QVector an alias to it
* We keep both names, QList
On 20/05/2020 09.11, Lars Knoll wrote:
Here’s what we will do:
* QList and QVector are aliases for each other
* We make QList the main type, and QVector an alias to it
* We keep both names, QList and QVector. None of them is deprecated
While I don't object to this as such, can someone remind
On 15/05/2020 14.31, Thiago Macieira wrote:
> Python's bstr still behaves string-like and has methods like
> QByteArray::indexOf(const char *). QVector has no such methods.
>
> But since we do have QListSpecialMethods, we can add inject them into
> QVector too.
Right; I was assuming that would
On 14/05/2020 21.12, Thiago Macieira wrote:
On Thursday, 14 May 2020 07:41:45 PDT Marc Mutz via Development wrote:
Also, given a function like
setFoo(const QByteArray &);
what does this actually expect? An UTF-8 string? A local 8-bit string?
An octet stream? A Latin-1 string? QByteArray
On 15/05/2020 06.39, Edward Welbourne wrote:
Thiago Macieira (15 May 2020 02:30) replied
On Thursday, 14 May 2020 12:34:54 PDT Matthew Woehlke wrote:
On 14/05/2020 14.58, Thiago Macieira wrote:
Which is:
b) misspelling "iteratable"
Be that as it may, that ship has sailed:
On 14/05/2020 14.58, Thiago Macieira wrote:
Which is:
b) misspelling "iteratable"
Be that as it may, that ship has sailed:
https://www.google.com/search?q=iteratable
Even Google thinks so, and if you insist otherwise, 12k results instead
of 2M.
--
Matthew
On 13/05/2020 11.49, Giuseppe D'Angelo wrote:
Il 13/05/20 16:44, Matthew Woehlke ha scritto:
Note that adding the QString(char16_t*) constructor
Pedantic, but surely you meant `char16_t const*`.
Hey, you can't nitpick here ...
This can be solved with a third overload:
template
On 13/05/2020 03.04, Lars Knoll wrote:
I don’t see a need to take a QStringView in those cases. With the
exception of some low level APIs, Qt’s APIs should be safe to use. An
overload taking a QStringView would either need to copy the data (in
which case we could just as well only offer the
On 12/05/2020 12.59, Marc Mutz via Development wrote:
AsidE: If you think that CoW is still a thing today: no. SSO is a thing
these days, and it seems that QString will not have it in Qt 6, either.
NOI favours SSO, QString-everywhere cements the naïve CoW world of the
1990s for yet another
On 12/05/2020 17.21, Thiago Macieira wrote:
On Tuesday, 12 May 2020 08:42:28 PDT Matthew Woehlke wrote:
How will this work? As I understand, the main advantage to
QStringLiteral is that it statically encodes the *length* as well as the
data. This isn't possible with raw literals, which
On 13/05/2020 02.33, Lars Knoll wrote:
On 12 May 2020, at 23:09, Thiago Macieira wrote:
I want rules that determine what the API should be without looking at the
implementation of those two functions.
You may be disappointed, at least as far as parameters.
This is one reason why I think we
On 12/05/2020 13.48, Giuseppe D'Angelo via Development wrote:
On 5/12/20 6:12 PM, Иван Комиссаров wrote:
So the question is - is it possible to allow to construct QString from
unicode literal?
"Not yet", but adding a constructor from char16_t to QString makes sense.
This creates a problem
On 12/05/2020 03.49, Lars Knoll wrote:
* QStringLiteral should turn into a small wrapper around u”…”, and
probably also get deprecated. Maybe we could add a user defined
literal for it instead that returns a read-only QString (QString s =
“…”_q;). So u”…” would lead to a QStringView, u”…”_q to a
On 28/04/2020 19.41, Giuseppe D'Angelo via Development wrote:
Il 28/04/20 21:45, Matthew Woehlke ha scritto:
* QList gets adapted so that its internal array allocates 3 *
sizeof(void*) per element, so that e.g. Q6StringList won't require a
per-item allocation. This would then also avoid
On 28/04/2020 03.56, Giuseppe D'Angelo via Development wrote:
1) First and foremost, in Qt 6 QString, QByteArray, QVector, are bigger
than a pointer (3 times a pointer size). So, in Qt 6:
* either QList stays unchanged, and now we heap allocate each element
for those cases too (thus it's
On 25/04/2020 10.49, André Pönitz wrote:
We all know the story that began with
"We knew for a long time that QList is not a good default
container, despite what the documentation claims. The problem
boils down to the fact that for a lot of types T, QList is
needlessly
On 23/04/2020 15.22, Sérgio Martins via Development wrote:
Specially when talking about QList -> QVector, as QVector doesn't
guarantee the stability of references due to reallocation.
Nor with Qt6 QHash... still waiting to see how much code *that* silently
breaks.
--
Matthew
On 24/04/2020 07.51, André Pönitz wrote:
So what is left is the question about what is in the name. That question was
interestingly enough not present at the begin of the crusade, it only came up
after it turned out that blind replacement of QList by QVector wasn't *that*
trivial and actually
On 23/04/2020 10.45, Giuseppe D'Angelo via Development wrote:
(Otherwise, "list" in Python is heterogeneous, why isn't QList
heterogeneous?)
That doesn't count; *variables* in Python are heterogeneous.
a = 5 # type(a) == int
a = 'foo' # type(a) == str
It should not surprise one
On 23/04/2020 05.30, Ville Voutilainen wrote:
On Thu, 23 Apr 2020 at 12:25, Philippe wrote:
QList is historically a cause of ambiguity, and Qt6 is the chance to get rid of
that.
Indeed. In Qt5, QList is sometimes a list,
sometimes a vector, but in Qt6 it's never a list.
Correction: in Qt5,
On 14/04/2020 05.28, Lars Knoll wrote:
I believe there is mostly a consensus here to find a way to get rid
of those macros. But many of our users do seem to like the ‘emit’
keyword as an annotation to a signal emission, and it is being used
extensively in existing code bases.
You know what
On 12/03/2020 01.55, Thiago Macieira wrote:
> On Wednesday, 11 March 2020 03:48:24 PDT Edward Welbourne wrote:
>> Matthew Woehlke (10 March 2020 20:24) wrote:
>>> In an ideal world...
>>
>> [snip]
>>
>>> Note that I believe nothing needs to be done
On 10/03/2020 12.19, Cristián Maureira-Fredes wrote:
> On 3/10/20 3:40 PM, Cristian Adam wrote:
>> What stops us from accepting the contributions via GitHub?
>>
>> Is it:
>>
>> 1. The CLA
>> 2. Qt Account
>>
>> For the CLA one can simply add an instance of:
>>
>>
On 28/02/2020 15.33, Lars Knoll wrote:
> This is all nice and fun to bike shed about, but I don’t think those
> proposed solutions match the scope of the original problem (which
> was relatively small). I don’t think a massive source compatibility
> breakage is what we want, just because there is
On 28/02/2020 13.39, Thiago Macieira wrote:
> That's my point: it's a reasonable feature to ask that any good IDE implement.
It may be reasonable to ask *an IDE* to implement such a feature. It is
*not* reasonable to ask every place that developers look at code — some
of which don't even do basic
On 28/02/2020 13.37, Konstantin Tokarev wrote:
> 28.02.2020, 21:34, "Thiago Macieira" :
>> On Friday, 28 February 2020 07:28:34 PST Matthew Woehlke wrote:
>>> If we had to do it over again, it might make sense to follow Python and
>>> make signals *objects
On 28/02/2020 13.32, Thiago Macieira wrote:
> On Friday, 28 February 2020 07:28:34 PST Matthew Woehlke wrote:
>> If we had to do it over again, it might make sense to follow Python and
>> make signals *objects* instead of *methods*. Then the code would look like:
>>
&g
On 27/02/2020 17.03, Allan Sandfeld Jensen wrote:
> On Thursday, 27 February 2020 21:51:18 CET Matthew Woehlke wrote:
>> On 26/02/2020 07.42, Tor Arne Vestbø wrote:
>>> As others have argued, a signal is not special, in the sense that any
>>> function can do anything,
On 27/02/2020 17.01, Allan Sandfeld Jensen wrote:
> On Thursday, 27 February 2020 21:43:33 CET Matthew Woehlke wrote:
>> On 27/02/2020 13.57, Thiago Macieira wrote:
>>> On Monday, 24 February 2020 03:30:25 PST André Somers wrote:
>>>> You seem to assume everyo
On 26/02/2020 09.10, Oliver Wolff wrote:
> For me the emit has value. It's just an annotation, but for me it
> serves a purpose. I can see that this is a signal emission and even
> if people keep arguing that this is pointless it serves a purpose to
> me. "Look here a signal is emitted, so that
On 26/02/2020 07.42, Tor Arne Vestbø wrote:
> As others have argued, a signal is not special, in the sense that any
> function can do anything, including emitting signals, so annotating it
> doesn’t seem critical, as we apparently are fine without in all other cases.
Taking a step back... I
On 27/02/2020 13.57, Thiago Macieira wrote:
> On Monday, 24 February 2020 03:30:25 PST André Somers wrote:
>> You seem to assume everyone used QtCreator as their IDE of choice. That is
>> not a reasonable assumption I think.
>
> It is a reasonable feature request for ALL IDEs to understand what a
On 25/02/2020 14.58, Ville Voutilainen wrote:
> On Tue, 25 Feb 2020 at 21:37, Matthew Woehlke wrote:
>> - Until now, `emit` has rarely been used in code that needs to mix with Qt.
>>
>> - C++20 will have modules.
>>
>> - Modules are theoretically immune to the abo
On 24/02/2020 07.34, Edward Welbourne wrote:
> Mitch Curtis (24 February 2020 13:22)
>> I don't think anyone has explained what that harm is yet.
>
> #define emit
>
> causes problems when you import a header that declares
>
> void emit(Type arg);
>
> and the compiler sees
>
> void (Type
On 21/02/2020 09.02, Ville Voutilainen wrote:
> Getting back to macro vs. function.. I think using a function wrapper
> is fine, considering that signals can't
> meaningfully return, so the prvalue/xvalue issue doesn't arise.
AFAIK, signals *can't* return, period. The signal body is written by
On 07/02/2020 03.14, Eike Ziller wrote:
> QList is most definitely a typedef to QVector in Qt/dev:
What happened to providing a container type with guaranteed indirect
storage? There remains no such type in STL.
Last I saw, I thought we were going to provide that...
--
Matthew
On 03/02/2020 16.25, Giuseppe D'Angelo via Development wrote:
> Other people are free disagree with this. (For instance, in Qt 6 the
> decision (which I disagree with) was to introduce similar gratuitous and
> very hidden source-incompatible changes, e.g. with QList and QHash both
> breaking
On 01/02/2020 07.31, Allan Sandfeld Jensen wrote:
> It is still a terrible name. Unique pointer refers to something
> std::unique_ptr can abstractly achieve, but not what it actually is.
It refers to something that had *better* be achieved, or else you're
using it wrong.
The *ownership* is
On 31/01/2020 05.07, Vitaly Fanaskov wrote:
> We’ve been discussing for a while how Qt6 API can be improved with using
> smart pointers. Recently we came into some conclusions and want to
> discuss them with the community.
>
> Smart pointers are for sure much better to use than raw pointers for
On 29/01/2020 17.13, Konstantin Shegunov wrote:
> On Wed, Jan 29, 2020 at 11:55 PM Matthew Woehlke wrote:
>> We need more open-source-meets-kickstarter...
>
> ehm, Patreon?
Aside from issues with Patreon's reputation, there's a reason I wrote
"kickstarter". I can't th
On 29/01/2020 12.12, Konrad Rosenbaum wrote:
> BTW: in the past I would have convinced one of my customers to buy
> support for the Open Source version if it had been available. If there
> was a simple possibility to buy a single support incident (say, for
> 100Euros) I would even do this
On 28/01/2020 22.27, Thiago Macieira wrote:
> On Tuesday, 28 January 2020 08:09:00 PST Matthew Woehlke wrote:
>> I agree... somewhat. Where I disagree is that I would go even further
>> and suggest rethinking their entire business model. Maybe look at
>> companies with a stron
On 28/01/2020 11.37, Volker Hilsheimer wrote:
> The Qt Company is a public company
...well, that may not be helping. How many of the shareholders both care
about the community and are sufficiently involved to make those feelings
known?
> Given how significant the Qt Company contribution to Qt
On 28/01/2020 12.03, Konstantin Tokarev wrote:
> 28.01.2020, 19:57, "Matthew Woehlke" :
>> On 28/01/2020 11.07, Alberto Mardegan wrote:
>>> But it will discourage contributions, and encourage competition from
>>> other Qt consulting companies
>>
&
On 28/01/2020 11.07, Alberto Mardegan wrote:
> But it will discourage contributions, and encourage competition from
> other Qt consulting companies
At this point, I'm not sure that's a *bad* thing...
> (I've written more on that here:
>
On 28/01/2020 10.55, NIkolai Marchenko wrote:
>> Won't someone please step up and do it for us?"
>
> Which is why I don't understand how the proposed model is supposed to help
> TQtC and the community.
> A lot of stuff they are dropping for opensource users will simply move to
> less trusted
On 28/01/2020 02.46, Bogdan Vatra via Development wrote:
> Folks, you have to understand that The Qt Company must pay its developers!
Sure... but how's that working out for them under their current business
model? Is twisting the screws even tighter on customers that (based on
my impression from
On 28/01/2020 01.37, Benjamin TERRIER wrote:
> You might have missed the info because it is in the blog post, but not in
> Lars email:
>
> There will be no more open source offline installer.
Correction: there will be no offline installer *provided by TQtC*.
Like Nikolai¹, what I expect to
On 17/10/2019 17.24, Ville Voutilainen wrote:
> On Fri, 18 Oct 2019 at 00:16, André Pönitz wrote:
>>
>> On Thu, Oct 17, 2019 at 09:04:36PM +0300, Ville Voutilainen wrote:
>>> Since we are about to do a major version upgrade, should be stop being
>>> a special snowflake in the C++ world and start
On 30/09/2019 15.35, Thiago Macieira wrote:
> On Monday, 30 September 2019 11:06:18 PDT Matthew Woehlke wrote:
>> IOW, the example would look like:
>>
>>
>> fullname.setBinding(
>> [](Foo const* self){
>> return self->surname() + "
On 30/09/2019 12.38, Ville Voutilainen wrote:
> On Mon, 30 Sep 2019 at 19:12, Matthew Woehlke wrote:
>>> QProperty fullname;
>>> fullname.setBinding([&]() { return surname() + " " + lastname(); });
>>
>> I suppose this is convenient, but
On 26/09/2019 11.02, Simon Hausmann wrote:
> I would like to propose an API that replaces the setter and getter
> functions on objects with a new property template class that
> encapsulates the property value instead, and the ability to tie
> binding expressions to these properties for automatic
On 25/09/2019 08.54, Morten Sørvig wrote:
> I see two differences between setting the DPI vs a factor:
>
> - You set one value per screen (DPI) instead of two (DPI & factor)
>
> - Qt can compute the factor, according to policy set by the application (as
> mentioned above)
>
> [...]
>
> If
On 22/08/2019 17.00, Thiago Macieira wrote:
> For Qt 6, it is possible (and is still my goal[*]) to make creating a
> QString out of a QStringView and through it from a u"" literal happen
> in constant time, inlined, with no memory allocation.
How? Unless I miss something (which your example did
On 22/08/2019 15.09, Danila Malyutin wrote:
> Can't it be alleviated/improved by providing user-defined literal for
> QString(Literal)? So that one would only write a["b"_qs] = "c"_qs.
No; there is no (portable) way in C++17 (and I think still in C++20) for
a UDL's return type to depend on the
On 22/08/2019 09.41, Martin Smith wrote:
> If Qt developers must not forget Q_DECLARE_TYPEINFO, why isn't it
> important for users?
...because users, especially application authors, typically have far
greater latitude to make BiC and even SiC changes compared to library
authors. Also, because they
On 17/08/2019 00.13, Sze Howe Koh wrote:
> QLabel returns some CoW types by-pointer as a legacy from Qt 1 times [1]:
>
> QPixmap *QLabel::pixmap() const;
> QPixture *QLabel::pixmap() const;
Does this allow one to obtain the internal pixmap and modify it in-place
without then calling
On 15/07/2019 18.19, Thiago Macieira wrote:
> On Monday, 15 July 2019 09:41:24 PDT Matthew Woehlke wrote:
>> Note also that I suggested having the template definition out-of-line;
>> it doesn't need to be in (e.g.) qstring.h or anywhere that will affect
>> *user* compi
On 14/07/2019 02.28, Mutz, Marc via Development wrote:
> If you're still not convinced, here's QStringView::endsWith() as a
> template:
>
> template
> requires std::is_convertible_v Qtf8StringView, || ... QLatin1StringView ...
> Q_ALWAYS_INLINE
> bool endsWith(Prefix ) const {
>
On 13/07/2019 15.39, Volker Hilsheimer wrote:
> As I understood the template suggestion, it’s more about not having
> to add 64 different overloads (or several more string classes) to
> the Qt API, and less about unifying all implementations into a single
> set of algorithms.
Right. At some
On 12/07/2019 16.05, Mutz, Marc via Development wrote:
> On 2019-07-12 17:27, Matthew Woehlke wrote:
>> On 11/07/2019 15.01, Thiago Macieira wrote:
> [...]
>>> Except that the whole point of those methods is that they can be more
>>> efficient when the encoding is
On 11/07/2019 15.01, Thiago Macieira wrote:
> On Thursday, 11 July 2019 13:41:49 -03 Matthew Woehlke wrote:
>> On 11/07/2019 05.05, Mutz, Marc via Development wrote:
>>> There is a cost associated with another string class, too, and it's
>>> combinatorial explosion.
On 11/07/2019 05.05, Mutz, Marc via Development wrote:
> There is a cost associated with another string class, too, and it's
> combinatorial explosion. Even when we have all view types
> (QLatin1StringView, QUtf8StringView, QStringView), consider the overload
> set of QString::replace(), ignoring
On 10/07/2019 09.10, Mutz, Marc via Development wrote:
> The other reason is about error checking: What should the result be of
> putting an æ into a QAsciiString? Assert at runtime? UB? In
> QLatin1String, this error just can't happen. Even if you feed it UTF-8,
> you may get mojibake, because
On 01/07/2019 09.56, Konstantin Tokarev wrote:
> 01.07.2019, 13:30, "Ville Voutilainen" :
>> On Sat, 29 Jun 2019 at 14:34, Konstantin Tokarev wrote:
>>> Or even better: split page into "tiles" (i.e. portions of page with height
>>> of viewport) and
>>> render long page as a sequnece of tiles.
On 30/06/2019 10.10, Holger Freyther wrote:
> On 28. Jun 2019, at 00:57, Thiago Macieira wrote:
>> In this particular case, Google loves to use Bazel. Everyone else hates that
>> they do.
>>
>> Ask anyone trying to package Tensorflow.
>
> Some Ex-Googlers like it too. It seems there is a
On 25/06/2019 17.53, Konrad Rosenbaum wrote:
> Option 2: put some elbow grease into QTextBrowser and make it understand
> some more tags and more CSS.
> Pros: documentation becomes visually more pleasing; minimal dependencies
> by assistant - easy to build and easy to bundle with applications;
>
On 19/06/2019 15.03, Giuseppe D'Angelo via Development wrote:
> On 19/06/2019 18:42, Matthew Woehlke wrote:
>> Mark wants to deprecate Q[E]SDP. That implies eventual removal, which
>> absolutely *is* depriving users of something they were previously using.
>> (Even just dep
On 18/06/2019 19.59, Giuseppe D'Angelo via Development wrote:
> On 18/06/2019 23:27, Matthew Woehlke wrote:
>> So... to be clear, your plan is to deprive Qt users of a (mostly)
>> perfectly good wheel, that *is* being used by said users, and instead
>> tell all of those users
On 18/06/2019 03.43, Mutz, Marc via Development wrote:
> BTW: this is the proposed replacement of QSDP/QESDP for Qt-internal use:
> https://codereview.qt-project.org/c/qt/qtbase/+/115213 and no, it will
> most certainly _not_ be public API again. It's the fact that these
> implementation details
On 17/06/2019 12.08, Bogdan Vatra via Development wrote:
> Or use a buildsystem that doesn't take to the hell?
Real world experience has shown that there is no such thing.
As much as people like to bitch about how "convoluted" CMake is, CMake
doesn't just set out to be obtuse. That complexity
On 15/06/2019 15.22, Bogdan Vatra via Development wrote:
> - no multi ABIs builds in one go (needed for msvc and useful also for
> Android).
...but MSVC has *never* built multiple ABI's in one go.
OTOH, MSVC is a multi-config generator and *does* support multiple ABI's
in a single build tree.
On 15/06/2019 12.32, Thiago Macieira wrote:
> On Friday, 14 June 2019 23:45:47 PDT Bogdan Vatra via Development wrote:
>>> I wouldn't call that a hard requirement. Separate builds for debug and for
>>> release are acceptable, the same way that we've ostensibly had support for
>>>
On 15/06/2019 14.24, Ville Voutilainen wrote:
> On Sat, 15 Jun 2019 at 02:30, Matthew Woehlke
> wrote:
>>>> OTOH, I just realized a problem with that... when the new child needs to
>>>> take its parent in the ctor for other reasons. I don't know if
On 17/06/2019 08.44, Konstantin Tokarev wrote:
> Also, are you trying to say that cmake's configuration system is
> more user friendly than Qt's configure
Yes. Very much so.
> (or for, that matter, autotool's configure or similar things in sane
> build systems)?
Yes. Very much so.
> All of the
On 14/06/2019 17.05, Ville Voutilainen wrote:
> On Fri, 14 Jun 2019 at 00:36, Matthew Woehlke wrote:
>> On 13/06/2019 16.09, Ville Voutilainen wrote:
>>> The minor problem being that to not so small audiences,
>>> new Whoosh(something);
>>> just looks like a
On 14/06/2019 14.35, Lisandro Damián Nicanor Pérez Meyer wrote:
> On Thu, 13 Jun 2019 at 17:02, Thiago Macieira wrote:
>> That means you should NOT do that strong dependency. app5 should
>> require qdbus >= Qt5, which means Qt 6's should suffice.>
> Except you can't ship both version in the same
On 11/06/2019 11.28, Matthew Woehlke wrote:
> A coworker just pointed out something interesting... the documentation
> of Q_NAMESPACE is in qobject.cpp, which causes it to be documented under
> the documentation for QObject. However, the *definition* comes from
> qobjectdefs.h, whic
ing like a sieve and doing
> use-after-free in all too many places.
QPointer is great for avoiding this :-). (Also, properly "owned"
signal/slot connections.)
> On Thu, 13 Jun 2019 at 22:54, Matthew Woehlke wrote:
>> My "concern", and possibly why everyone fixated on
On 13/06/2019 14.13, Daniel Teske wrote:
> On June 12, 2019 23:13:14 Matthew Woehlke wrote:>> Generally, if you follow
> three rules:>>>> - If you create an object
on the stack, either don't parent it or ensure>> its parent outlives
it. (Usually not hard!)>>
On 13/06/2019 03.03, Marco Bubke wrote:
> On June 12, 2019 23:13:14 Matthew Woehlke wrote:
>>> me here. I think Daniel is on to something and we really should explore
>>> having smart pointers in Qt 6, but at this point I'm not convinced
>>> std::unique_ptr alone
On 12/06/2019 18.14, Matthew Woehlke wrote:
> On 22/05/2019 12.41, Konstantin Tokarev wrote:
>> In the latter QList can be replaced with
>> std::vector> or QVector>
>
> No, it can't. `QList` has value semantics w.r.t. `T`. Your
> "alternatives" have point
1 - 100 of 329 matches
Mail list logo
