buttonText: Theme.buttonTextDisabled
> button: Theme.buttonDisabld
> }
> }
> }
>
>
> Kind regards,
> Marcel
> _______
> Development mailing list
> Development@qt-project.org
> https://lists.qt-proj
Fanaskov
Cc: Simon Hausmann ; development@qt-project.org
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
On Thu, Apr 23, 2020 at 12:25:33PM +, Vitaly Fanaskov wrote:
>I think we should completely remove QList in Qt6. It was planned
>before, as far as I remember. Th
Vitaly Fanaskov wrote:
> Provide clang-based tools to (semi-)automatically port users' code bases to
> a new version of Qt. These tools might either fix a code or at least add a
> comment in potentially problematic places where a user should correct the
> code. A developer who changes API
I think we should completely remove QList in Qt6. It was planned before, as far
as I remember. The main reason is to be consistent with STL wording and do not
violate POLA too much.
I read the entire discussion, and I'd like to say this one more time: we don't
have to fight the consequences.
Regarding exceptions, I see your point. Personally I agree with using
exceptions here. If there are no well justified objections, just go for it.
On 3/5/20 4:59 PM, Bogdan Vatra wrote:
Hi,
În ziua de joi, 5 martie 2020, la 17:14:44 EET, Vitaly Fanaskov a scris:
I think something like std
I think something like std::expected is a nice thing to have.
There is some experimental implementation of std::expected:
https://github.com/TartanLlama/expected.
Another good example is Result
(https://doc.rust-lang.org/std/result/index.html) type from Rust. But
might look clumsy in C++,
Sounds like a good idea.
It also would be nice to integrate this change with gerrit somehow. For
example, if you push non-WIP changes and add reviewers, an associated
task should be moved to "In Review" state automatically.
On 2/17/20 10:13 AM, Edward Welbourne wrote:
> Hi all,
>
> We
Qt smart pointers is also a question. The best solution, in this case,
would be porting them to standard smart pointers, I think.
On 2/13/20 12:08 PM, Giuseppe D'Angelo via Development wrote:
Il 13/02/20 10:57, Vitaly Fanaskov ha scritto:
I think that moving Qt smart pointers to Qt5Compat module
is about fighting
with consequences rather than about fixing a cause.
On 2/12/20 7:37 PM, André Pönitz wrote:
> On Wed, Feb 12, 2020 at 11:13:17AM +0000, Vitaly Fanaskov wrote:
>>>> We should also move Qt smart pointers to Qt5Compat module. The
>>>> destiny of QPointer
, Alberto Mardegan wrote:
> On 12/02/20 15:20, Vitaly Fanaskov wrote:
>>> AFAIK, we don't have a procedure to make project-level decisions by
>>> majority vote.
>> True. We're discussing now. The goal here is to take people opinions and
>> arguments into account before
e rest of feedback we can. Only after we should make a
decision and define resulting artifacts (docs, recommendations, user
stories, blog posts, etc.).
On 2/12/20 12:42 PM, Konstantin Tokarev wrote:
>
> 12.02.2020, 12:36, "Vitaly Fanaskov" :
>>> You seem to repeat
smart pointers as a part of Qt6? It would be a duplication in
this case. I thought that it is just a logical consequence.
On 2/12/20 11:57 AM, Karsten Heimrich wrote:
> Many thanks Vitaly for taking the time and effort to get the discussion going.
>
> -Original Message-
>> From: D
> You seem to repeat your initial statements.
Yes, because most of the participants of this discussion tend to agree,
as far as I can see.
On 2/11/20 8:19 PM, André Pönitz wrote:
> On Tue, Feb 11, 2020 at 03:15:11PM +, Vitaly Fanaskov wrote:
>> I want to summarize intermed
management is
not such a good idea.
Irrelevant subject: something about Qt containers.
On 1/31/20 11:07 AM, Vitaly Fanaskov wrote:
> Hello everyone,
>
> 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
ters.
On 2/4/20 4:16 PM, Alberto Mardegan wrote:
> On 04/02/20 16:55, Vitaly Fanaskov wrote:
>> But if you see API like this:
>>
>> std::unique_ptr someAPI();
>>
>> You have much more information about managed object just by reading the
>> code. Th
Qt can be used with a program that uses exceptions.
On 2/4/20 12:24 PM, Alberto Mardegan wrote:
> Going back to the original question again, as I'm not sure I agree with
> this claim:
>
> On 31/01/20 13:07, Vitaly Fanaskov wrote:
>> Smart pointers are for sure much better to use than
.
On 2/4/20 1:22 PM, Konstantin Shegunov wrote:
On Tue, Feb 4, 2020 at 12:15 PM Vitaly Fanaskov
mailto:vitaly.fanas...@qt.io>> wrote:
I think, if we decide to re-implement parent-child model using smart
pointers, we would not use unique pointers at all. Even in a methods
like QObject::mak
I think, if we decide to re-implement parent-child model using smart
pointers, we would not use unique pointers at all. Even in a methods
like QObject::makeChild (because ownership is already defined). Shared +
weak pointers make perfect sense here. The main reason is that many
other objects
ight be
easier than implementing something like that :) Start using smart
pointers sounds more realistic.
On 2/3/20 3:33 PM, Konrad Rosenbaum wrote:
> On 2020-02-03 15:04, Vitaly Fanaskov wrote:
>> We don't need this method at all if everything is implemented with using
>> smart pointers.
We don't need this method at all if everything is implemented with using
smart pointers.
On 2/2/20 6:17 PM, Иван Комиссаров wrote:
> 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
On 2/2/20 12:12 AM, Giuseppe D'Angelo wrote:
Hi,
Il 01/02/20 22:55, Vitaly Fanaskov ha scritto:
The consensus was reached against such a decision. A scoped pointer
should not be able to escape scope. Yes, in C++17 this is now not
entirely true, but the name strongly implies it.
Perhaps,
consistent APIs that don't violate
principle of less astonishment is important thing. That's the main reason why
personally I vote for the option with Qt wrappers.
On 01/02/2020, 00:48, "Giuseppe D'Angelo via Development"
wrote:
On 31/01/2020 23:46, Vitaly Fanaskov wrote:
&g
1, "André Pönitz" wrote:
On Fri, Jan 31, 2020 at 03:27:29PM +0000, Vitaly Fanaskov wrote:
> Not abandoning, I think, but re-implementing properly. Raw pointers
> cause some certain problems here and changing them to something more
> smart would be nice. But it doe
to have one more entity without a real reason to do that.
On 31/01/2020, 21:07, "Development on behalf of Ville Voutilainen"
wrote:
On Fri, 31 Jan 2020 at 21:23, Alberto Mardegan
wrote:
>
> Old man here:
>
> On 31/01/20 13:07, Vitaly Fanaskov wrote:
:
> 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 muc
Not abandoning, I think, but re-implementing properly. Raw pointers
cause some certain problems here and changing them to something more
smart would be nice. But it doesn't mean that we should get rid of
parent-child model entirely. The point is that we can make it more
explicit just by using
n Friday, 31 January 2020 11:07:52 CET Vitaly Fanaskov wrote:
>> Hello everyone,
>>
>> 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.
&g
Hi Daniel,
I'm confused that there's zero discussion of the work I have done in showing
how adding unique_ptr apis would look like. Surely, you have internally
discussed that approach.
Yes, I saw this patch (https://codereview.qt-project.org/c/qt/qtbase/+/260618).
It looks good as an example
Hello everyone,
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
many reasons. They manage lifetime
> That fork will be necessary because you can't just switch
> projects like KDE from Qt 5 to Qt 6 overnight, it will take years to do it!
In light of this, it's probably worth thinking about releasing a new
major version of Qt each year. It also might solve some other problems.
So, how about Qt
pe D'Angelo wrote:
> Il 20/12/19 13:54, Vitaly Fanaskov ha scritto:
>> This is not that easy to use std::* containers because at least the
>> following issues have to be addressed:
>>
>> * Memory management
>> * Binary compatibility
>> * Implementation c
This is not that easy to use std::* containers because at least the following
issues have to be addressed:
* Memory management
* Binary compatibility
* Implementation consistency
You probably can provide, for example, some allocators, relax compatibility
requirements and so on...
Hi,
I think that this discussion is pointless. Style is mostly the matter of
preferences, but:
1) We have a huge code base with the certain code style.
2) We have official guidelines.
3) We have a tool for auto code formatting.
I don't see any good reasons to change the entire code base or
Hi Marc,
Could you elaborate a bit, what the real value of this change?
I'm asking, because there are only cons I see now:
1) Adding inline after namespace *implicitly* throws all symbols to the
global (or outer) namespace, which, potentially might lead to name
clashes. For example, the
Hello everyone!
I think, we can use range-based approach to improve a lot of things in
Qt classes interfaces. I've performed some experiments and implemented
an access to children of QObject with this approach:
https://git.qt.io/vifanask/qobject-with-ranges . All details, pros and
cons are
container to an std::deque can (needs profiling, though) improve
> performance since it stores data in chunks. Imagine prepending a row to a
> table with 3kk rows... well, good luck reallocating a vector in QHeaderView.
>
> Иван Комиссаров
>
> 6 июня 2019 г., в 10:17, Vi
> As a library implementer, you are simply not _allowed_ the freedom to
> use a convenient tool over the most efficient one. That is, to put it
> mildly, a disservice to users and a disgrace to the profession of
> programmers.
Well, optimization is probably good, but not always, I would say. If
> APIs in libraries are meant to be used. I consider it an entirely reasonable
> expectation by developers using the APIs that they will not be removed under
> them because the library developers consider them "obsolete". Imagine the
> chaos if Intel or AMD decided to remove some random "obsolete"
All these have the same issue: You are proposing to deprecate Qt types in
favor of STL types, which have a different naming convention (_ vs. camel
case) and often terse, harder to understand names (e.g., ptr vs. Pointer,
push/pop for a queue vs. enqueue/dequeue, etc.), and which do not support
Well, but what about MSVC, for example, or some other compilers/|platforms?
This is rhetorical question, of course. I just want to say, that we cannot
guarantee this sort of compatibility for all build configurations. Hence, this
is unreliable unless we have a sort of public contract like “we
mailto:development@qt-project.org>> wrote:
On 2019-05-29 16:06, Vitaly Fanaskov wrote:
=== QAtomic -> std::atomic ===
It already is just a thin wrapper around std::atomic, so there's not
much point keeping it.
There is the interesting question in light of this: are we really going
to widel
> === QAtomic -> std::atomic ===
>
> It already is just a thin wrapper around std::atomic, so there's not
> much point keeping it.
There is the interesting question in light of this: are we really going
to widely use std::* in public interfaces of Qt? If so, how all related
mess is supposed
Going forward, we should be looking into removing more and more owning
containers from the interface and replace them with views. The standard is
working on a solution for the stale reference problem, and by the time Qt 7
comes around, it will be hopefully widely available.
This is good
Hi,
Sounds good. This module might be useful for some companies that develop VFX
software.
On 5/9/19 10:21 AM, Thomas Hartmann wrote:
Hi,
I would like to request for a new module:
Name of the repository: qt/qtquicktimeline.git
Description: Module for keyframe-based timeline construction.
Well, it should be possible, to support parents, created on the stack. We
already have the code to do it. The code is private, unfortunately, but it
doesn't matter. In the following file:
qtbase/src/corelib/tools/qsharedpointer_impl.h
We have the following constructor, used by QPointer:
Hi Simon,
Thank you for the update.
It's not clear why you included version to a package name (e.g. Qt5/Qt6). With
CMake you can pass a version as the second argument, e.g.: find_package(Qt 5.12)
Perhaps it would be better, what do you think?
On 2/13/19 10:33 AM, Simon Hausmann wrote:
Hi,
eping them and so on... Wouldn't
this sort of API useful for a developer who wants to use move-to-trash
operation?
On 2/11/19 1:22 PM, Volker Hilsheimer wrote:
Hey Vitaly,
See inline.
On 11 Feb 2019, at 11:42, Vitaly Fanaskov
mailto:vitaly.fanas...@qt.io>> wrote:
Making QFile::remove(bo
s that your program is not an exclusive owner
of files. The trash bin can be re-created/moved/removed and so on. How would
you locate your files in this case?
On 2/8/19 11:08 PM, Volker Hilsheimer wrote:
On 8 Feb 2019, at 10:43, Vitaly Fanaskov
mailto:vitaly.fanas...@qt.io>> wrote:
On 2/7
Hi,
I've read QTBUG-47703 very carefully and I think that adding some file managers
is overkill in this particular case. I would suggest the following changes:
1. Extract an abstract class (i.e., interface) for common file operations
2. Both QFile and QDir should implement this interface
>Why not X instead?
>--
>
>- GitFlow, GitHub <= both are based on feature branches, that doesn't work
> well with gerrit.
So, the only problem here is gerrit (aside from personal preferences and
habits of course). The question is shouldn't we abandon gerrit as this
I vote for shorter form as well.
But the documentation should be extended with the Philippe's second
example. Trailing return type is rarely required, but we cannot omit
parameters list in this case, because it leads to compilation error.
On 1/9/19 8:31 PM, Philippe wrote:
> I like the shorter
51 matches
Mail list logo
