Re: [Development] Qbs development

The patchset is still blocked. Gerrit Admins, could you please remove the -2 vote? Ivan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development

Re: [Development] Qbs development

I believe there were several other cases, both in gerrit and discord. I think, we should proceed with a formal vote. Ivan > 16 сент. 2021 г., в 14:50, David Skoland написал(а): > >  > >> On 15 Sep 2021, at 16:52, Oswald Buddenhagen >> wrote: >> your arrogance, dismissiveness, and cynicism

Re: [Development] Qbs development

> 15 сент. 2021 г., в 14:03, Oswald Buddenhagen > написал(а): > > in a nutshell, though, i think ivan's initial message is revealing > enough - for example, he plainly admits that his documentation doesn't > match the code. that's an automatic -1, and a yellow card for attitude. That’s not

Re: [Development] Qbs development

OK, it will be fair to list the problems/inconveniences we have right now (or, in other way, the advantages of GitHib) - It is hard for the newcomers to get familiar with gerrit - some people submitted raw patches in JIRA claiming they don’t have time to learn Gerrit while knowing the

Re: [Development] Qbs development

the migration - it should not be very hard to do. Ivan > 14 сент. 2021 г., в 17:33, Lars Knoll написал(а): > >  Hi, > > Let’s also take up the formal part of the request. > >>> On 13 Sep 2021, at 22:59, Иван Комиссаров wrote: >>> Also, some actions migh

[Development] Qbs development

Hello everybody I would like to raise an issue about Oswald Buddenhagen abusing his maintainer rights. He is constantly blocking the merge of the patchset which implements a new feature in Qbs [0]. I started working on this almost a year ago and the issue was approved for the first time in

[Development] QHash references stability in Qt6

Hello, when porting Qbs to Qt6 I’ve noticed a lot of bugs/crashes when using QHash. With Qt5 that was never a problem and simple change QHash -> std::unordered_map fixes those. From what I understood all affected places rely on the fact that QHash in Qt5 (as well as std::unordered_map)

Re: [Development] Important recent changes in QList/QString/QByteArray

In the awful world of the standard library we call vector.shrink_to_fit() to ensure that. Note that while you have your «please free the memory» use-case someone might have the «please do not free memory, I still need it» use-case. Ivan > 3 сент. 2020 г., в 09:40, Jaroslaw Kobus написал(а): >

[Development] QAIV new virtual methods (was: Feature freeze next Tuesday)

> On 2 Sep 2020, at 10:38, Lars Knoll wrote: >> >> Pure ABI changes are no problem until 6.0 is released. >> >> Source incompatible changes are something we should restrict to where >> required now, and you’ll need to be prepared to follow up with commits in

Re: [Development] Feature freeze next Tuesday

to the signal from the model. Dunno if I will find time to do that, but I wonder if this is still possible. Should be a pretty simple refactor. Иван Комиссаров > 26 авг. 2020 г., в 08:47, Lars Knoll написал(а): > > Hi all, > > This is just a gentle reminder that feature freeze for Qt 6

Re: [Development] Important recent changes in QList/QString/QByteArray

better arguments than that. Ivan > 1 сент. 2020 г., в 22:31, Thiago Macieira > написал(а): > > On Tuesday, 1 September 2020 13:06:39 PDT Иван Комиссаров wrote: >> Sorry, but you’re wrong here. Cppreference clearly says > > Cppreference is irrelevant. > > --

Re: [Development] Important recent changes in QList/QString/QByteArray

Sorry, but you’re wrong here. Cppreference clearly says Invalidates iterators and references at or after the point of the erase, including the end() iterator. https://en.cppreference.com/w/cpp/container/vector/erase

Re: [Development] qsizetype and classes working with QStrings or QList

corner use-cases, haven’t they? Ivan > 25 авг. 2020 г., в 01:09, Thiago Macieira > написал(а): > > On Monday, 24 August 2020 15:10:24 PDT Иван Комиссаров wrote: >> It would be nice if QAbstractItemModel will support qsizetype instead of >> int, but I do not see how this

Re: [Development] Codereview maintenance break is over

I can no longer select and comment part of the line. macOS, Safari. Chrome works though. Am I the only one having this issue? Ivan > 24 авг. 2020 г., в 08:19, Tuukka Turunen написал(а): > > Hi, > > Thanks! That was fast. Codereview seems to be working nicely with the new > version. > >

Re: [Development] qsizetype and classes working with QStrings or QList

It would be nice if QAbstractItemModel will support qsizetype instead of int, but I do not see how this is possible considering the fact that rowCount/columnCount return int. I suppose, it is not very hard to patch QModelIndex, but what to do with virtual functions? The user code will break.

Re: [Development] Qt5.14 Prl files are missing for Mac framework build?

> 29 июля 2020 г., в 09:54, Alexandru Croitor > написал(а): > > Are these from the 6.0 snapshot files, or are you building Qt yourself? I am using a snapshot. Should I try more recent version? > > I suggest to open a bug report for them. https://bugreports.qt.io/browse/QTBUG-85801

Re: [Development] Qt5.14 Prl files are missing for Mac framework build?

л(а): > > > >> On 27 Jul 2020, at 23:55, Иван Комиссаров wrote: >> >> Hello again! >> >> What about qt6? In the snapshot files are back in framework root… Is that a >> regression? > > Yeah, that’s a regression when transitioni

Re: [Development] Qt5.14 Prl files are missing for Mac framework build?

Hello again! What about qt6? In the snapshot files are back in framework root… Is that a regression? Ivan > 2 янв. 2020 г., в 00:24, Иван Комиссаров написал(а): > > Ah, cool, thanks for clarification > > Ivan > >> 1 янв. 2020 г., в 19:50, Tor Arne Vestbø > &l

Re: [Development] Nominating Ivan Komissarov as approver

Thanks everybody! Ivan. > 28 мая 2020 г., в 10:50, Alex Blasche написал(а): > > Congrats to Ivan. Approver rights have been set. > > -- > Alex > > > From: Development on behalf of Christian > Kandeler > Sent: Thursday, 7 May 2020 10:23 > To:

Re: [Development] Views in APIs (was: Re: QString and related changes for Qt 6)

/ const QSet &. So, as I said, I do not see the problem. Can we always return views? Yes. Do they gives us benefits in every case? No. Ivan > 14 мая 2020 г., в 02:15, Thiago Macieira > написал(а): > > On quarta-feira, 13 de maio de 2020 01:41:26 PDT Иван Комиссаров wrote: >

Re: [Development] Views in APIs (was: Re: QString and related changes for Qt 6)

Nope, that would not be C++ if it wasn’t broken: class C1 { public: std::string_view getMember() const & { return member; } std::string member; }; std::string_view m = C1().getMember(); // compiles! You have to delete the method explicitly: std::string_view getMember() const && =

Re: [Development] Views in APIs (was: Re: QString and related changes for Qt 6)

ts = createProject().products() | std::views::transform(…); // compile error, no need for Clazy! Ivan > 13 мая 2020 г., в 10:14, Иван Комиссаров написал(а): > > > >> 13 мая 2020 г., в 09:04, Lars Knoll > <mailto:lars.kn...@qt.io>> написал(а): >> >> The

Re: [Development] Views in APIs (was: Re: QString and related changes for Qt 6)

> 13 мая 2020 г., в 09:04, Lars Knoll написал(а): > > The above example is rather weirdly constructed. > > But anyhow, those data lifetime issues when using views as return values > extensively are a lot less obvious to spot when a human reads the code. APIs > should be safe to use

Re: [Development] QString and related changes for Qt 6

12 мая 2020 г., в 16:12, Giuseppe D'Angelo via Development > написал(а): > > On 5/12/20 12:20 PM, Иван Комиссаров wrote: >>> * Exceptions can be done where significant performance gains can be >>> demonstrated and the API will by design not require a copy of the dat

Re: [Development] QString and related changes for Qt 6

> 12 мая 2020 г., в 09:49, Lars Knoll написал(а): > > Hi all, > First of all, the plan sounds great! > > Most other classes: > > * Only take and return QString > * Exceptions can be done where significant performance gains can be > demonstrated and the API will by design not require a

Re: [Development] Proposal: Deprecate QVector in Qt 6

I suppose, there are plans to keep the old QList implementation under the different name (QArrayList/Q5List). Can we also add the same typedef in Qt5 (using Q5List = QList)? This will simplify the transition for the people who want to build against Qt5 and Qt6 at the same time. Ivan

Re: [Development] Proposal: Deprecate QVector in Qt 6

+1 for proposal 3. I don’t see any reason to repeat all the arguments against the original proposal, I cannot agree more. Ivan > 24 апр. 2020 г., в 08:57, Joerg Bornemann написал(а): > > On 4/23/20 15:52, Thiago Macieira wrote: > >>> Proposed: >>> >>> template using QVector = QList;

Re: [Development] The future of smart pointers in Qt API

Wait, what?? When did that decision was made? I am tired fixing performance bugs induced be the replacement QList with QList>, can we please get rid of the QList class finally? > 6 февр. 2020 г., в 20:14, Matthew Woehlke > написал(а): > I thought we decided *not* to > do that!) >

Re: [Development] The future of smart pointers in Qt API

Can we please return to the discussion about QObject parent/child with smart pointers rather than discussing Qt/stl naming? No one answered my question about QObject::deleteLater: > And what about the QObject::deleteLater() method? Any ideas how this should > look like with smart pointers?

Re: [Development] The future of smart pointers in Qt API

I would also like to add the argument about templates. Qt API is still incompatible with STL in some places, so one cannot write a template function that simply calls STL variant. For example: QString foo; if (std::empty(foo)) // oops, fails to compile because QString misses the .empty() method

Re: [Development] Make a decision for asynchronous APIs

results as QFuture does. This may be confusing for people > who are expecting QFuture to be a typical future they are used to, and I > actually saw some complains about that. > > Best regards, > Sona > > > From: Иван Комиссаров > Sent: Saturday, February 1, 202

Re: [Development] Make a decision for asynchronous APIs

Can you please elaborate the difference? > 31 янв. 2020 г., в 17:24, Sona Kurazyan написал(а): > > Additionally, there are some discussions about QFuture being a mix between a > “Task” and a “Future”. One of the options of improving this situation is to > make a QTask (or QJob) out of the

Re: [Development] The future of smart pointers in Qt API

Do I understand correctly that proposition of usage of the shared_ptr instead of unique_ptr is to have a drop-in replacement for a QPointer (weak_ptr)? Can we implement It somehow with the unique_ptr? And what about the QObject::deleteLater() method? I always found it pretty ugly (what if that

Re: [Development] Qt5.14 Prl files are missing for Mac framework build?

iew.qt-project.org/c/qt/qtbase/+/275473> > > Tor Arne > >> On 31 Dec 2019, at 00:08, Иван Комиссаров > <mailto:abba...@gmail.com>> wrote: >> >> Hello, did I miss something? Because I cannot find .prl files in the Qt >> frameworks anymore on Mac:

[Development] Qt5.14 Prl files are missing for Mac framework build?

Hello, did I miss something? Because I cannot find .prl files in the Qt frameworks anymore on Mac: $ ls /Applications/Qt/5.14.0/clang_64/lib/QtCore.framework/ Headers QtCore Resources Versions But they are in 5.13 $ ls /Applications/Qt/5.13.2/clang_64/lib/QtCore.framework/ Headers QtCore

Re: [Development] QHash for Qt 6

019 г., в 12:12, Kevin Kofler написал(а): > > Иван Комиссаров wrote: >> Well, every time I use (or try to use) QStringView I encounter the problem >> of missing methods/functionality. The same applies to the Qt containers. > > It's funny because I have that issue each time I am

Re: [Development] QHash for Qt 6

, but who’s going to support them? I am not really against Qt containers, but I have some doubts that QtCompany has enough manpower or desire to support those. Иван Комиссаров > 23 дек. 2019 г., в 11:11, Alberto Mardegan > написал(а): > > On 20/12/19 13:47, Giuseppe D'Angelo via

Re: [Development] Oslo, we have a problem [char8_t]

can change after those operations). > 8 июля 2019 г., в 8:49, Giuseppe D'Angelo via Development > написал(а): > > Il 08/07/19 07:54, Иван Комиссаров ha scritto: >> Is it possible to do an inplace toUpper() for the ASCII encoding? > > At some past QtCS it was deeme

Re: [Development] Oslo, we have a problem [char8_t]

Is it possible to do an inplace toUpper() for the ASCII encoding? > 8 июля 2019 г., в 4:43, Thiago Macieira > написал(а): > > On Sunday, 7 July 2019 23:26:40 -03 Konstantin Ritt wrote: >> As we have string views now, I'd vote for deprecating the string >> manipulation methods in QByteArray. I

Re: [Development] Coin mailing issue

Same here, also about merged ones > 14 июня 2019 г., в 21:07, Samuel Gaist написал(а): > > Hi guys, > > Does anybody know what is happening with coin ? > > Over the last couple of hours I have received more that an hundred of emails > about integration failure some of which don’t even

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

No, they should not. C++ committee understands the problem of ugly iterators and it seems they have a solution - ranges. Why do you want to use qSort instead of std::ranges::sort? QVector v; qSort(v); std::ranges::sort(v); I don’t see any advantages of the qSort() here. No more ugly

Re: [Development] Proposing CMake as build tool for Qt 6

Sorry, but the iOS should be properly supported before making the final decision. Building something on macOS is easy, building smth for iOS is harder. From the top of my head it is code signing and building "fat" binaries that should be tested as a proof of concept. Иван Комиссаров

Re: [Development] Views

prepending a row to a table with 3kk rows... well, good luck reallocating a vector in QHeaderView. Иван Комиссаров 6 июня 2019 г., в 10:17, Vitaly Fanaskov написал(а): >> As a library implementer, you are simply not _allowed_ the freedom to >> use a convenient tool over the most e

Re: [Development] Configure command lines of official Qt releases

AFAIK -R . is used to load that icu libraries I told you about in Gerrit. Otherwise it will try to load the system ones instead of the shipped ones with Qt. > 5 июня 2019 г., в 14:46, Richard Weickelt написал(а): > >> Excellent yes. That was a recent addition to the installer framework, >>

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

Until QList will be finally renamed=) > 30 мая 2019 г., в 17:34, Giuseppe D'Angelo via Development > написал(а): > > Hi, > > On 30/05/2019 10:23, Alberto Mardegan wrote: >> I bet it's unused because everyone is using QList. But once we deprecate >> QList, people will start asking for a CoW

Re: [Development] QList for Qt 6

> 4. Use QVector to implement QList, if sizeof(Foo) <= sizeof(quint64) and > Foo is movable What about fast prepend in that case? People tend to use QList as a deque because of the fast prepend/take first Иван Комиссаров > 22 мая 2019 г., в 15:49, Lars Knoll написал(а): > &

Re: [Development] Views

C++ standart is a software and like any software, it has bugs. It’s good that «auto_ptr» bug was fixed among with auto a {42}; However, reading the dev list it seems that people claim that *everything* that is done by the Committee is a bug and there’s only the «Qt way» of doing things like it

Re: [Development] QList for Qt 6

oid*) and T has been declared to be either a Q_MOVABLE_TYPE or a Q_PRIMITIVE_TYPE using Q_DECLARE_TYPEINFO. See the Pros and Cons of Using QList for an explanation. Иван Комиссаров > 20 мая 2019 г., в 13:40, NIkolai Marchenko > написал(а): > > And on the matter of "you

Re: [Development] Views

Please note that nobody said «we are removing Qt containers in Qt6». At least, I don’t have that information. The discussion is mostly about a *theoretical* case when the implementation of a *theoretical* method in a *theoretical* class may *theoretically* change and how far we should go to

Re: [Development] Views

Ah, ok, I missed that information, good to know. > 16 мая 2019 г., в 22:43, Mikhail Svetkin > написал(а): > > > std::span introduced in c++20. > ___ Development mailing list Development@qt-project.org

Re: [Development] Views

Correct me if I’m wrong, but gsl::span (or an array_view) conforms (one of) the ranges concept, i.e. it *is* a range. No need to wait for c++20 =) > 16 мая 2019 г., в 22:23, Mikhail Svetkin > написал(а): > > If we will return a range (C++20 accepted ranges) then we can provide better >

Re: [Development] Views (was: Re: QList for Qt 6)

> 16 мая 2019 г., в 18:29, Thiago Macieira > написал(а): > > When you first design the class, sure. But 5 years later, you may have the > data internally kept in a QMap or QHash, mapped to some other information. So > your function that used to "return d->member;" now does > "return

Re: [Development] unique_ptr and Qt, Take 2

:06:39 +0200 > Allan Sandfeld Jensen wrote: > >> On Samstag, 4. Mai 2019 00:43:10 CEST Thiago Macieira wrote: >>> On Friday, 3 May 2019 13:00:52 PDT Иван Комиссаров wrote: >>>> Which should be considered bad practice and banned on an API level >>> >>

Re: [Development] unique_ptr and Qt, Take 2

her auto_ptr, so confider this as a crazy idea. > 4 мая 2019 г., в 0:36, Giuseppe D'Angelo > написал(а): > > Il 04/05/19 00:33, Иван Комиссаров ha scritto: >> Back to the topic - in case we really want to support the "stack case", I’d >> say shared_p

Re: [Development] unique_ptr and Qt, Take 2

me, I know what I’m doing, this is intended». > 4 мая 2019 г., в 0:43, Thiago Macieira написал(а): > > On Friday, 3 May 2019 13:00:52 PDT Иван Комиссаров wrote: >> Which should be considered bad practice and banned on an API level > > No way. > > Are you going

Re: [Development] unique_ptr and Qt, Take 2

nly option (in combination with enable_shared_from_this which is already a kinda part of QObject, as mentioned above) > 3 мая 2019 г., в 23:54, Giuseppe D'Angelo via Development > написал(а): > > Il 03/05/19 23:03, Иван Комиссаров ha scritto: >> I’d say it’s an implementati

Re: [Development] unique_ptr and Qt, Take 2

Or maybe you can’t I didn’t think about the fact that public ctor allocates d_ptr itself… Need to think a bit more=( > 3 мая 2019 г., в 23:03, Иван Комиссаров написал(а): > > You can use the same technique in qMakeChild as in std::make_shared - to > allocate MyObjectPriva

Re: [Development] unique_ptr and Qt, Take 2

detail - it *is* possible to implement the creation of QObjects more efficient than it is done now without «forcing» user to use objects on stack to avoid allocations. > 3 мая 2019 г., в 22:39, Konstantin Tokarev написал(а): > > > > 03.05.2019, 23:31, "Иван Комиссаров"

Re: [Development] unique_ptr and Qt, Take 2

use cases are considered voodoo and bad practice. > 3 мая 2019 г., в 22:15, Giuseppe D'Angelo via Development > написал(а): > > Il 03/05/19 22:00, Иван Комиссаров ha scritto: >> Which should be considered bad practice and banned on an API level >> QWidget w2 >&g

Re: [Development] unique_ptr and Qt, Take 2

Which should be considered bad practice and banned on an API level QWidget w2 QWidget w1; w1.setParent(); QWidget w1; QWidget w2 w1.setParent(); Which one will crash?=) > 3 мая 2019 г., в 21:40, Thiago Macieira > написал(а): > > On Friday, 3 May 2019 12:32:01 PDT Allan Sandfeld Jensen

Re: [Development] unique_ptr and Qt, Take 2

That’s exactly why observer_ptr should not* be implemented as alias to a raw pointer; the main difference is that constructor from T* is explicit and there’s no implicit cast from observer_ptr to unique_ptr, so your example will not compile =) * well, the clang implementation I used forbids

Re: [Development] unique_ptr and Qt, Take 2

Thiago, can you please elaborate how you see this? For a simple TreeItem a pair of std::unique_ptr/std::observer_ptr should be enough (with a bunch of convenience methods to insert children): struct TreeItem { observer_ptr parent; vector> children; }; Yes, the code becomes a bit verbose,

Re: [Development] unique_ptr and Qt, Take 2

IMHO, it should be a Qt6 feature. It’s awesome. However, I liked the idea (is it deprecated or what?) of a template method template std::observer_ptr qMakeChild(gsll::not_null> parent, Args… args) { return parent->adoptChild(std::make_unique(args)); } With that method, you don’t need to

Re: [Development] Qt6 source changes

Sure. Sorry for std::array_view (it maybe a QSet or QVector or gsl::span whatever more convinient/faster). The basic idea is here: In the model: void multipleData(QModelIndex index, std::array_view roles, std::function enumerator) { for (auto&& role: roles) { if (role ==

Re: [Development] Qt6 source changes

Nice idea to have such a method. But is't it a pessimization to return a vector which certainly allocates? Don't throw rocks in me, what about passing std::function that can enumerate roles? Иван Комиссаров > 2 нояб. 2018 г., в 17:52, Giuseppe D'Angelo via Development > написал(а): &

Re: [Development] Another integer typedef OR how to prepare for 64-bit in Qt 5

Yeah, forget my argument. Go for 4. Иван Комиссаров > 2 нояб. 2018 г., в 16:02, Thiago Macieira > написал(а): > >> On Friday, 2 November 2018 06:50:50 PDT Jedrzej Nowacki wrote: >>> On Friday, November 2, 2018 4:42:52 AM CET Thiago Macieira wrote: >>> >&g

Re: [Development] Another integer typedef OR how to prepare for 64-bit in Qt 5

I vote for 3. The (small) argument is: with qint one cannot write an algorithm taking std:: class (std::vector) and a Qt class but with size_type it can. Something like template T::size_type * getSize(const T ) { return t.size(); } auto d1 = getSize(std::vector()); // ok auto d2 =

[Development] Qt6 source changes

volve and stucking with QList for the next 10 years is a bad idea IMO. Иван Комиссаров ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

Huh? Looks like they are supporting every build system alive https://github.com/openframeworks/openFrameworks/tree/patch-release/libs/openFrameworksCompiled/project > 30 окт. 2018 г., в 22:14, Jean-Michaël Celerier > написал(а): > > OpenFrameworks, a fairly used creative coding framework has

Re: [Development] Build system for Qt 6

Wow, hold on for a minute. I’ve been using a qbs package as a standalone leaf package (sudo aptitude install qbs) to build my projects. Also, self-built QBS package was commercially used to create several Debian packages back in 2013. > 30 окт. 2018 г., в 18:18, Lisandro Damián Nicanor Pérez

Re: [Development] Build system for Qt 6

It is aware about Mac OS! Doesn't help actually, last time I tried to build kde apps on mac, I failed Иван Комиссаров 30 окт. 2018 г., в 12:23, Christian Gagneraud написал(а): >>> On 30 Oct 2018, at 05:00, Christian Gagneraud wrote: >>> - Any track record that Qbs was n

Re: [Development] Build system for Qt 6

I guess, VS still will support QBS in case VS generator is working. Unfortunately, Xcode generator doesn't, I checked recently. Иван Комиссаров > 30 окт. 2018 г., в 11:25, NIkolai Marchenko > написал(а): > > > Yes and this is relevant if it is relevant for the maintainers o

Re: [Development] Build system for Qt 6

You have one year (or 2 Qt creator releases) to rewrite everything again=) 3, 2, 1, go! Иван Комиссаров > 30 окт. 2018 г., в 9:56, NIkolai Marchenko > написал(а): > > That's basically how I switched ppl here at my workplace to QBS: I've > rewritten their .pro files for them

Re: [Development] Build system for Qt 6

Иван Комиссаров > 30 окт. 2018 г., в 4:34, Thiago Macieira > написал(а): > >> On Monday, 29 October 2018 18:20:35 PDT NIkolai Marchenko wrote: >> Lars, I have to wonder, don't you guys miss an opportunity here? >> Qt 5 was not developed with QBS in mind. As

Re: [Development] Build system for Qt 6

RIP Qbs=( Иван Комиссаров > 29 окт. 2018 г., в 17:32, Ray Donnelly написал(а): > > Agreed, a brilliant bit of technology, such a shame to see it deprecated. >> On Mon, Oct 29, 2018 at 4:24 PM Corentin wrote: >> >> >> Having had the pleasure to use QBS qu

Re: [Development] gsl::owner (Was: Setters: Clarifying the ownership)

Иван Комиссаров > 31 июля 2018 г., в 21:39, Konstantin Tokarev написал(а): > > > > 31.07.2018, 21:35, "Иван Комиссаров" : >> I prefer the solution from the thread "unique_ptr and Qt" about using smart >> pointers for transferring ownership ex

Re: [Development] gsl::owner (Was: Setters: Clarifying the ownership)

y that can be source and (maybe) binary compatible, but that's a workaround, not a solution. However, the solution can require too much work to do. Иван Комиссаров > 31 июля 2018 г., в 16:04, Eric Lemanisser > написал(а): > > Please, don't introduce another type alias. It wou

Re: [Development] Qt 6 buildsystem support requirements

QBS generates Qt Modules file depending on the information that QMake provides about modules installed in the system to make sure you won;t be able to import module that doesn’t exist on your system. According to the fact that you can have multiple versions of Qt (i have 3 Qt versions on my

Re: [Development] Qt 6 buildsystem support requirements

> 21 июля 2018 г., в 23:04, Thiago Macieira > написал(а): > > On Saturday, 21 July 2018 10:39:49 PDT Иван Комиссаров wrote: >> 1. IDE integration. I really need the IDE know the correct CXX flags for >> each separate file in my project - that is includes, c++ version

Re: [Development] Qt 6 buildsystem support requirements

What you wrote reminds me how government officials spent budget money for the new cars in my country. They write specific tender documentation that fits only one car, say Chevrolet Tahoe (for example, "the car that fits 9 people, has leather interior and has the power of 200hp»). The

Re: [Development] unique_ptr and Qt

It would be nice if makeChild returned a some kind of «stupid» smart pointer (gsl::not_null maybe?) to indicate that object is not owned by holder (compare with raw pointer where the ownership is not known without reading doc): template QNonOwningPointer QObject::makeChild(Args&&... args);

Re: [Development] qdds image format

compressed jpeg, it is decompressed before usage (correct me if i'm wrong, but videocards uses DDS because it's decompression algorithm can be easily implemented in hardware) 2018-04-17 14:28 GMT+03:00 Giuseppe D'Angelo <giuseppe.dang...@kdab.com>: > On 17/04/18 13:21, Иван Комиссаров wrote

Re: [Development] qdds image format

Ok, there's another problem with QImage - ARGB64 and friends... This can be solved adding QImage::pixel64() or something like that... or use QTexture with 64bit "pixel" 2018-04-17 11:48 GMT+03:00 Иван Комиссаров <abba...@gmail.com>: > > > 2018-04-17 11:02 GM

Re: [Development] qdds image format

2018-04-17 11:02 GMT+03:00 Giuseppe D'Angelo <giuseppe.dang...@kdab.com>: > On 17/04/18 08:09, Иван Комиссаров wrote: > >> Looking at the email archives: it was fuzzed through AFL. I don't have >>> the test images still around, but in my experience a simple mult

Re: [Development] qdds image format

> 16 апр. 2018 г., в 16:03, Giuseppe D'Angelo <giuseppe.dang...@kdab.com> > написал(а): > > On 16/04/18 12:23, Иван Комиссаров wrote: >> So, how those issues are checked? Any tool or what? > > Looking at the email archives: it was fuzzed through AFL. I don't

Re: [Development] qdds image format

So, how those issues are checked? Any tool or what? 2018-04-16 0:41 GMT+03:00 Thiago Macieira <thiago.macie...@intel.com>: > On Sunday, 15 April 2018 12:59:35 PDT Giuseppe D'Angelo wrote: > > Hello, > > > > Il 15/04/2018 18:14, Иван Комиссаров ha scritto: > &g

Re: [Development] qdds image format

> 15 апр. 2018 г., в 18:59, Giuseppe D'Angelo <giuseppe.dang...@kdab.com> > написал(а): > > Il 15/04/2018 17:32, Иван Комиссаров ha scritto: >> Hello, what happened to the qdds image plugin? >> I found the note in the docs: "For security reasons, the Di

[Development] qdds image format

Hello, what happened to the qdds image plugin? I found the note in the docs: "For security reasons, the Direct Draw Surface (DDS) handler is not built by default since Qt 5.8" but could not find any open issues. Does anyone know what are those "security reasons"? What need to be done to return the

Re: [Development] QtCS 2017 QtCore sessions

Sorry for digging the thread, but how is * use qssize_t and ** Wrapping std::{unordered_}map may be acceptable combines? std::*map uses size_t in it's API (size, max_size, count, reserve, begin(size_type), end(size_type)) And offtop - what about allocators? They would be accesibble for

Re: [Development] Feature Freeze Exception: QStringView

Great job! What about QByteArrayView? Do you plan to use std::string_view instead? What about toInt/toDouble/etc, toLower/toUpper, right/left/mid (aka std::string_view::remove_prefix/suffix), find and other QString methods that doesn't modify the string? Do you plan to add them later or support

Re: [Development] Texture image loading library

> 21 янв. 2017 г., в 16:25, Sean Harmer написал(а): > > It's > about being able to parse texture files into CPU addressable memory. From > there > it can be used by OpenGL, Direct3D, Vulkan, Metal, $OTHER_API. > Do I understand correctly that all is needed is to scan

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

version (or new stdlib version if we’ll support std:: in API) is released (also, users should reinstall those packages too) Иван Комиссаров 19 нояб. 2016 г., в 15:07, Marc Mutz <marc.m...@kdab.com> написал(а): > As soon as someone explains to me what the material difference i

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

) and so on. We have to move from that point somewhere, either extending our classes to make them standard-compatible (when possible) or replace them with stl ones. Иван Комиссаров 19 нояб. 2016 г., в 12:34, Alexander Nassian <nass...@bitshift-dynamics.de> написал(а): > Will t

Re: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

Maybe we should start another thread about BC? I'm not convinced that MacOS is the only system when mixing libc++/stdlib makes sence. On linux you can do the same. If we will use stl, the Qt version installed from packages can't be used for development, you should use libc++/stdlib Qt version from

Re: [Development] Compile errors, Qt configured with -qreal float

But is's not fixed yet? 2016-10-28 14:14 GMT+03:00 Marc Mutz : > > They are. It took two decades for this bug to be noticed, and while it > should > be fixed, in std2, probably, code that relies on either behaviour must atm > be > considered buggy. >

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

I was using CMake for several years (and still forced to use it now), however i moved all my projects to QBS for one reason - CMake is too complex. It has great documentation, but it can't be used without it; on the contrary, qbs is very intuitive. I don't have to remember tons of variables like

Re: [Development] Can we use std::unique_ptr in Qt base/modules sources since Qt5.7 ?

If we don't have unique_ptr, then, probably, we don't have move semantics too 2016-06-13 10:51 GMT+03:00 Sean Harmer : > On Monday 13 June 2016 06:47:44 Bo Thorsen wrote: > > Den 12-06-2016 kl. 12:59 skrev Denis Shienkov: > > >> No, use of the C++11 Standard Library

Re: [Development] Fixing QRect::width() / height()

We can also validate rect on construction and allow to create rects no bigger than QRect(*, *, MAX_INT, MAX_INT) rects? 2016-03-15 16:44 GMT+03:00 Poenitz Andre : > > On Tuesday 15 March 2016 13:08:42 Bo Thorsen wrote: > > > Den 15-03-2016 kl. 14:07 skrev Marc

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

2016-02-26 11:43 GMT+03:00 Jędrzej Nowacki : > On Thursday 25 of February 2016 19:22:55 Milian Wolff wrote: > > The thought evolved over last months and now I think that QAIM should not > be > QObject at all, it is just an unnecessary cost. > > Hm... Really?

Re: [Development] Question about QCoreApplicationData::*_libpaths

Of course, i should add mutex to the getter and setter. 2016-01-22 13:14 GMT+03:00 Marc Mutz <marc.m...@kdab.com>: > On Friday 22 January 2016 09:57:00 Иван Комиссаров wrote: > > What > > i'm missing? > > You haven't done the exercise with the int first. > > -

  1   2   >