Re: [Development] Using string literals in autotests
On Thu, Mar 28, 2024 at 12:14:35PM +0100, Friedemann Kleint via Development wrote: > Hi, > > I'd say performance should be a consideration for autotests since they are > compiled and run over and over again in the CI. So, string theory should be > applied to avoid unnecessary conversions and allocations. Even it is > considered a minor optimization, it will have an impact on energy > consumption & CO2 emission in the end, IMO. I tend to disagree, at least to make this a first approximation to some general rule, which IMNSHO rather should be "make the code easy to create and easy to understand, micro-optimize only if you have evidence that the first approximation is not sufficient". Performance surely is a consideration in general, also for autotests, and there are probably also a handful autotests that are so string-intensive (parsers?) that string related optimization actually help, but at the end of the day, this should be balanced against other costs, e.g. how quick and easy to write and to maintain code, and it should not require a (recent...) "PhD in string theory". > Of course, writing a sophisticated template squeezing out the last bit of > runtime performance on which the compiler has to chew for a while does not > help either, since the test is typically compiled and run once. And it's a full process that needs to be spawned etc etc. A few hundred, even thousands, allocations do no make a noticable difference in a stand-alone test. Even when run (optimistically) tens of thousands times in the CI this still has to offset the human time to create and review changes for this "improvement", and that's not even considering yet the recent tradition of changing the prefered decoration regularly, which basically de-values any previous effort spent on this. What was _qs's life time from invention to deprecation? A bit more than a year? Besides, most "string theory" changes rely on replacing proper objects by views (kind of fine, but:) which effectively are mere fat pointers with implicit lifetime dependencies on other objects, increasing the fragility of code and raising the maintenance costs (see e.g. 415210 and 510464 in qtbase and fallout) So, yes, ok to have for the few cases that actually benefit from it, but no, not a general, universally applicable pattern, let alone something that everyone should be bothered with by default. Regards, Andre' PS: > Surely, the Foundation Team is in the process of creating instructive > documentation on string theory? On a sarcastic day I might be tempted to suggest creating an RSS feed for that. On the other days I'd say that's a two-liner: Recommend QT_RESTRICTED_CAST_FROM_ASCII at least for non-library code (this includes tests) and be done. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Should QObject::event() be protected or public?
On Mon, Mar 18, 2024 at 02:00:06PM +0100, Giuseppe D'Angelo via Development wrote: > On 18/03/2024 13:34, André Somers wrote: > > While I know it's easy to work around, I sometimes find myself doing it > > anyway. To me, it signals what API is intended to be used in what way. > > That a class overrides `event` (or any other public virtual method) > > does not mean that that method is then intended to be called by a user > > of the class as the type you defined. That you overwrote it may just be > > an implementation detail. I think the methods you expose as "public" on > > an API are quite important*. They signal how the user is supposed to use > > an instance of your class. If you have methods in there that are just > > implementation details, then those don't fit. These methods are meant to > > be called by parts of the system that don't see your type as the actual > > type, but as something more basic: a QObject in this case. > > But I agree 100% here; this is typically realized in C++ by having the entry > point public and non-virtual, and have that dispatch to a protected virtual. The "Non-virtual interface" pattern. Been there, done that (in a different project), and sure, can be used and works. But I wouldn't call it "typical", as it imposes overhead for practically no gain even for new projects starting with that as the preferred approach, let alone to setups where this "needs" to be introduced later. > The whole problem we're discussing is that `event()` has been made public in > the base class and that means it's now public API of any QObject subclass, > whether they like it or not. :-( The subclasses can (and often do) make it protected. This is a pragmatic approach. It pretty much works and feels like NVI without having to write the redirection at the base level. Anyway, I would like to explicitly disgress here, as this is yet another instance of a pattern I see repeating again and again, and while I (grudgingly) accept that pragmatism is apparently not en vogue anymore, I still think there should be a limit to that: The actual problem here is /not/ whether or not QObject::event() should be public/overridden in derived classes, or not, whether NVI is good or not, but how much effort should be put into discussing and "solving" this kind of ivory-tower (non-)problems, and how well such a "solution" would scale to "all of Qt", instead of spending this energy and effort on fixing actual problems. Andre' PS: I had a quick look through the archive. There seems to be a pretty high correlatation between threads with more than ~20 responses and what I personally would call a "non-problem" to start with. Not 100%, but a good first approximation. PPS: If someone has doubts on the claim of things being non-problems I heartily invite them to come up with their own statistics on the actual effects of recent changes in the string zoo. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Should QObject::event() be protected or public?
On Fri, Mar 15, 2024 at 07:16:59AM +, Marc Mutz via Development wrote: > Summary as of 2024-3-14 EOD: QObject::event() has to stay public. Ok. > Please note that this means that any override (and all new QObject > classes should contain one, since, in case we ever need it, it might not > be possible to add it after the fact) should also be public. Neither is a necessary consequence, and I don't think this new rule would be helpful. What kind of setups do you expect where an event() override in the middle of the inheritance chain needs to be called from outside to warrant this rule requiring class-implementor to regularly write code that's unlikely (and I claim: Never) needed? Please note that this thread was started with the assumption that not even the base QObject::event() needs to be callable from the outside, [and also that, in principle, for truly hard cases, one can legally sneak out of the 'protected' jail via litb's trick using ISO/EIC 14882:2011 14.7.2(12)] Andre' > Thanks, > Marc > > On 13.03.24 08:58, Marc Mutz via Development wrote: > > Hi, > > > > In API review, we detected some overrides that changed the access > > specifier vis-a-vis the original virtual function > > (https://wiki.qt.io/Things_To_Look_Out_For_In_Reviews#Polymorphic_Classes > > Item 5.3). > > > > One of them was a protected reimplementation of QObject::event() (which > > itself is public). > > > > The reason why QObject::event() is public seems lost to history, but the > > feeling in the review comments¹ was that it should have been protected > > from the get-go (and QObject befriended by whoever delivers events). > > > > If you see any reason for QObject::event() to stay public in Qt 7 and > > not become protected, please speak up before we fork Qt 7.0 :) > > > > Thanks, > > Marc > > > > ¹ > > https://codereview.qt-project.org/c/qt/qtdeclarative/+/528290/comment/f51938ca_fd065a18/ > > > -- > Marc Mutz > Principal Software Engineer > > The Qt Company > Erich-Thilo-Str. 10 12489 > Berlin, Germany > www.qt.io > > Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen > Sitz der Gesellschaft: Berlin, > Registergericht: Amtsgericht Charlottenburg, > HRB 144331 B > > -- > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Using '#pragma once' instead of include guards?
On Tue, Mar 05, 2024 at 10:43:50AM +, Volker Hilsheimer via Development wrote: > > On 4 Mar 2024, at 15:56, Kai Köhne via Development > > wrote: > > > Hi Marc, > > I've nothing against using '#pragma once' for private/internal headers. > > But you said you mainly want to have this to differentiate between > > different types of headers. If this is the motivation, I think we can > > make this differentiation even more explicit. For instance, public > > headers could get a > >// This header is part of the public Qt API. > > comment. Much like the 'We mean it', or 'pragma once', syncqt could > > enforce this for public headers, and error out if it's used for > > non-public ones. > > Kai > >I think the challenge then is again how syncqt can know what a public >header is. How does syncqt know that src/plugins/**/*.h headers are not >public headers? They look like public headers, except for the “plugins” >in the path. How do we, on a build system level, distinguish between >“private installed” and “private non-installed” headers? Opt-in by a specific comment "// This is a public/private/... header" sounds like an option to me. >In the end, syncqt can ideally rely on an explicit decision that has >become manifest through an easily recognizable pattern in each header >file. Whether we replace include guards with #pragma in all non-public >headers, or tag all public headers with a comment doesn’t really matter >all that much, does it? > >But given that we have the “We mean it” comment already for _p.h >headers, would it not be more consistent if we simply add that comment >to all non-public headers (no matter their file path, and no matter >whether the header is installed or not)? That comment makes the >usability of the declarations in the header obvious to the reader, >without having to know the rules. > >We have agreed that for some headers we allow use of #pragma, but >taking myself as a reference, I doubt that it’s obvious to everyone >which headers are installed, and when it’s allowed to use #pragma, and >when it’s mandatory to use #pragma. Perhaps adding the “We mean it” >comment to all headers not declaring public API is less obscure? The >question is if and how we can use syncqt to enforce this reliably. Even if we find out that there's a 1:1 relation between "#pragma once" and private headers I also think it's worthwhile to make that explicit. Andre' -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Can we remove recommendation against unnamed namespaces from Qt coding conventions?
On Fri, Feb 23, 2024 at 09:49:17AM +, Jøger Hansegård via Development wrote: > >> [...] > >> Would an option be to change from: > >> > >> Avoid the use of anonymous namespaces in favor of the static keyword > >> if possible. A name localized to the compilation unit with static is > >> guaranteed to have internal linkage. For names declared in anonymous > >> namespaces the C++ standard unfortunately mandates external linkage. > >> (7.1.1/6, or see various discussions about this on the gcc mailing > >> lists) > >> > >> to > >> > >> Use unnamed namespaces for all internal/non-exported entities. > >>Functions can > >> alternatively be marked `static` in the global namespace. Marking > >>functions > >> `static` also in the unnamed namespace can help readability, > >>particularly in reviews. > > > >That's technically an option, but again not a good one in my book. There is > >no > >advantage /known to me/ /for functions/ to be in the anonymous namespace > >instead > >of being 'static', and I listed a few cases where there are disadvantages. > > > >This change also does not solve the "problem" of having /different/ rules > >than > >the (self-proclaimed...) "Core Guidelines" which was - to me - the main > >reason > >for the proposed change. > > > >Andre' > > The main reason for changing the current convention on unnamed namespaces is > that the rationale is no longer correct, which makes it confusing to use in > code > reviews. I only mention Cpp Core Guidelines because if we delete our item, Cpp > Core Guidelines would be the remaining guideline mentioning unnamed > namespaces. > However, since it appears clear that the community disagree with the Cpp Core > Guidelines on this topic, we should keep a Qt specific convention on unnamed > namespaces. > > Reading the Qt convention again, I read it as "do not replace `static` with > unnamed namespace", but does not forbid moving `static` > functions into unnamed namespaces if this otherwise would make sense, for > example if the function operates on data structures defined inside that > namespace. I can live with that. A static function does not have to be in an unnamed namespace to operate on data structures defined there. So I don't think the 'otherwise would make sense' condition is met regularly, if at all. The only reason I can think of where putting a static function into an unnamed namespace may have /some/ advantage is when this is a lonely function amidst class/enum definitions in an unnamed namespace and one doesn't want to close and re-open this just to have the 'static' on top level. This should be a rare case, and I care little whether in this case that static is inside the namespace or on top-level, as long as it is there. > But is the real question whether we should omit the `static` keyword in > unnamed > namespaces or not? The reasons 1-5 and 7 I gave previously for the top-level case still apply when the static function is wrapped in an unnamed namespace, too. So my answer to the question is "It should not be omitted". > I added a couple of proposals. Which would you prefer? > > Proposal 1 > > Use unnamed namespaces for all internal/non-exported entities. Functions > can > alternatively be marked `static` in the global namespace. Marking > functions > `static` also in the unnamed namespace can help readability, particularly > in > reviews. > > Proposal 2 (same as current convention, but with new rationale): > > Avoid the use of anonymous namespaces in favor of the static keyword if > possible. Rationale: `static` is attached to individual functions, not a > scope of uncertain extent. When working on unfamiliar code it helps to > understand the context. > > Proposal 3: > > Use the `static` keyword with local functions even if it is inside > anonymous > namespaces. Rationale: `static` is attached to individual functions, not a > scope of uncertain extent. When working on unfamiliar code it helps to > understand the context. Proposal 3 sounds ok to me. Andre' -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Can we remove recommendation against unnamed namespaces from Qt coding conventions?
On Wed, Feb 21, 2024 at 06:56:41PM +, Jøger Hansegård via Development wrote: > >> Our Qt coding conventions ([1]https://wiki.qt.io/Coding_Conventions) > >> has a statement on the use of unnamed (anonymous) namespaces. As far as > >> I understand, this statement is now outdated. > > > [I'll assume we are talking about functions here.] > > Anonymous namespaces can be quite helpful to avoid name clashes of > non-function types. Non-function types are practically not covered by the current rule, as it has an 'static [...] if possible' and there's no possibility to have 'static' on enums and types, and it has a different meaning for e.g. class members. > Quite often I see both local functions and other local entities in the same > cpp > file. I don't want to recommend against moving local functions into the > unnamed > namespace unless there is a technical reason why we shouldn't. I gave some numbers in the previous mail that I considered at the time of its writing a technical reason. What would be an acceptable 'technical reason' here? > > It would be a change to the worse in my book which I personally would not > > like. > > Anonymous namespaces are harder to set up and to maintain and produce at > > best > > identical results compared to static' > > Would an option be to change from: > >Avoid the use of anonymous namespaces in favor of the static keyword >if possible. A name localized to the compilation unit with static is >guaranteed to have internal linkage. For names declared in anonymous >namespaces the C++ standard unfortunately mandates external linkage. >(7.1.1/6, or see various discussions about this on the gcc mailing >lists) > > to > >Use unnamed namespaces for all internal/non-exported entities. Functions > can >alternatively be marked `static` in the global namespace. Marking > functions >`static` also in the unnamed namespace can help readability, particularly > in reviews. That's technically an option, but again not a good one in my book. There is no advantage /known to me/ /for functions/ to be in the anonymous namespace instead of being 'static', and I listed a few cases where there are disadvantages. This change also does not solve the "problem" of having /different/ rules than the (self-proclaimed...) "Core Guidelines" which was - to me - the main reason for the proposed change. Andre' -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Can we remove recommendation against unnamed namespaces from Qt coding conventions?
On Wed, Feb 21, 2024 at 04:26:52PM +, Jøger Hansegård via Development wrote:
>Our Qt coding conventions ([1]https://wiki.qt.io/Coding_Conventions)
>has a statement on the use of unnamed (anonymous) namespaces. As far as
>I understand, this statement is now outdated.
[I'll assume we are talking about functions here.]
The given reason there is outdated, but it's only the most obvious reason
at the time of its writing. There are more:
1. 'static' is attached to individual functions, not a scope of uncertain
extend. When working on unfamiliar code it helps to understand the context.
With 'static' the locality is obvious in the immediate context of the function
and not set by some 'namespace {' potentiall a dozen functions and hundreds of
lines of code away.
2. Anonymous namespaces typically require more lines of code / vertical space.
3. Anonymous namesoaces require extra conventions on whether (and if so, how)
to mark the closing of the namespace by comments ('} // anon' ?)
4. Anonymous namespaces are not anonymous, but effectively typically(?) only
oddly-enough-named-so-there-are-no-clashes.
5. It should be encouraged to hide functions as much as possible. This is
more work when using namespaces:
5.1) identifying such functions is more difficult, since it's not clear
from the function itself (see 1.) whether it is already hidden
5,2) actual hiding a so-far-visible function is more effort:
(add 'namespace {' and '}' and probably two or three empty lines
vs typing 'static' once)
So chances are biased towards not hide the hideable function.
6. Even if the optimized final compiled product is identical, intermediate
steps are not:
echo 'namespace { void foo() {} }' | gcc -xc++ - -g -S -o - | wc
156 3202509
echo 'static void foo() {}' | gcc -xc++ - -g -S -o - | wc
133 2742154
Less lines, less characters, shorter symbols. This plays a role when it comes
to compile times and debugging.
7. Visible from 6.: Less typing for the occasional hidden function.
> Can we delete this statement and lean on Cpp Core Guidelines Cpp Core
> Guidelines
> SF.22 instead
> https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rs-unna
> med2?
It would be a change to the worse in my book which I personally would not like.
Anonymous namespaces are harder to set up and to maintain and produce at best
identical results compared to static'
Andre'
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Raising the minimum to C++20
On Fri, Feb 09, 2024 at 06:51:44PM +0100, Philippe wrote: > >So, as much as I'd like for some of the things I'mworking on to be > >able to benefit from C++ 20, I'd also say that we should rather slow > >down, and only require C++20 if we have something to show for it. > > C++20 makes for a more enjoyable coding experience; this human factor > should not be ruled out of the equation. > > With the key to sometimes more readable code and a certain gain in > productivity. This is an argument in favour of making it possible to /use/ Qt in a C++20-using environment or application. This is already possible right now. Nobody stops anyone from using C++20 in their own code of a Qt-based application and enjoy all the coding experience found that way, But that's only loosely related to the suggestion in the original message in this thread which was asking to make C++20 mandatory to use for all Qt users, which has the potential to leave behind people and projects who cannot simply use a C++20, be it that there is no such thing as a C++20-capable compiler in the environment they (have to) live in, or that they are simply lacking the resources to adapt their enviroment, or that they have other restrictions in their overall setup that prevent arbitrary changes to their environment. Qt benefits from a very broad range of users. For me it seems counter-productive to leave people behind needlessly. Insofar I agree with the previously voiced sentiments that convincing arguments to _force_ people into a C++20 environment (or drop the use of Qt) have not been presented yet. This is not saying such argument cannot exist, it's just not clear - at least to me - what they may be. So if you - who is apparently a happy user of C++20 - have examples what C++20 features make the coding experience better to a degree to compensate for the potential loss on the other side, I am all eears. Andre' -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] 6.7 FF vs. C++20 comparisons
On Fri, Dec 15, 2023 at 05:40:28AM +, Marc Mutz via Development wrote: > On 13.12.23 18:36, Thiago Macieira wrote: > > So, +1 for me on going ahead. > > Thanks! > > Is anyone else here for/against? To me this doesn't look like a new feature, so I don't see the feature freeze blocking this formally. But there is also no rule that everything that is formally permitted /has/ to be done. The time after the feature freeze is also useful to get some field testing by the few early adopters, and providing an effectly moving target there does not really help the cause. Recently there were two serious regression on the Qt side due to "just using string views" (which would also be formally permitted), and I've seen now a patch that changes a map to a hash to avoid part of the porting "work" to the new comparison scheme that makes that change not quite "mechanical". So, sure, in a perfect world, this kind of activity would be neutral, but apparently it is possible to fumble. Maybe I am just generally lacking a certain sense of urgency here to have this kind of changes, but I think it would be better to avoid the risk by simply not doing it. Andre' -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Request for early MOC support for C++20 Modules
On Fri, Dec 15, 2023 at 04:25:43PM +, Volker Hilsheimer via Development
wrote:
> > On 15 Dec 2023, at 16:19, Sune Vuorela wrote:
> >
> > On 2023-12-15, Elias Steurer via Development
> > wrote:
> >> No, I still need all the get/set/notify functions to change/get the
> >> variables from the outside. There is currently no way to do that, or am
> >> I missing something? Something like this
> >> https://gitlab.com/kelteseth/ScreenPlay/-/blob/master/ScreenPlayUtil/inc/public/ScreenPlayUtil/PropertyHelpers.h?ref_type=heads#L52
> >> but as a standardized Qt macro.
> >
> > My experience, after having written a few macros like that out of
> > projects, is that it is a bad idea, unless it is really thought thru.
> >
> > What I have seen is that it encourages all properties to be
> > read/write/notify where at least many of them was only supposed to be
> > read/notify or read/constant.
> >
> > /Sune
>
>
> Would it help/be a bad idea if moc would identify member functions that match
> the Qt naming convention so that you can reduce the boiler plate, e.g.
>
>
> class Thing
> {
> Q_PROPERTY(QString text)
>
> public:
> void setText(const QString ); // obviously the setter
> QString text() const; // evidently the getter
>
> signals:
>textChanged(const QString ); // there’s a notification signal
> };
>
>
> Doesn’t help you if you use snake case, but *could* perhaps be configurable
> with a command line option.
Another option that could be considered in principle would be to try to get
away with less cases that need moc magic.
I haven't tried yet, but I have the gut feeling that one should be able
to get away with
class Thing : public QObject
{
Q_OBJECT
public:
Property text; // getter and storage
Setter setText{}; // setter
signals:
textChanged(const QString ); // there’s a notification signal
};
Thing::Thing()
{
registerProperty(, "text");
}
to provide essentially the same syntax on the user side, i.e.
Thing t;
QString s = t.text();
t.setText("abc");
When going doen that road, also
class Thing
{
public:
Property text; // getter and storage
Setter setText{}; // setter
Signal textChanged{}; // signal
};
/might/ be possible. As I said, I haven't tried.
Andre'
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Proposing new Qt Creator module: Qt Creator Solutions
On Sat, Dec 02, 2023 at 11:25:16AM +0100, Giuseppe D'Angelo via Development wrote: > On 30/11/2023 19:39, apoenitz wrote: > > I propose to make this setup an official Module of Qt Creator, and herewith > > also nominate Jarek as Maintainer. Jarek has been pushing the idea and is > > the > > author of the biggest existing Qt Creator Solution: TaskTree[2], so for me > > this > > is the obvious choice. > > > > Comments/questions/opinions? > > Just wondering if we could extend the scope: > do these solutions depend on QtCreator parts somehow? No, and not really planned now, but there are a few potential candidates that depend on each other (remote file and remote process access for instance). For now the idea is to have only "pure" Qt users there, but if the idea in general flies then at some time it's imaginable that "solutions" could depend on each other. > If not (I've understood that TaskTree specifically > doesn't), why not "just" going for a playground module? It's not feature-complete yet, and as long as there are still additions expected there are benefits to have that in-tree (e.g. atomic commit instead of submodules) that we currently believe to outweigh the benefits of a "physical" separation. But this also may change at some time. Andre' -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposing new Qt Creator module: Qt Creator Solutions
On Thu, Nov 30, 2023 at 07:41:06PM +, Fabian Kosmale wrote: > Hi, > > I agree that it would be nice to properly separate Solutions (to enforce their > reusability, and to make it easier to include the module into other projects). > > I'm also convinced that Jarek would do a good job as the maintainer of the > module. > > I have however two questions: > 1. How this will affect packaging/releasing of QtCreator? In the current setup that's not affecting nor meant to be affecting anything like that at all, i.e. the main difference between libs/solution/tasktree and, say, src/plugins/git is that the former does not depend on anything outside Qt proper whereas the latter can and does depend on other items in Creator's src/plugins/* and other src/libs/* bits that cannot so eaily be split off in self-contained pieces. Once one libs/solution/* is considered reasonably complete and stable API-wise there may be a suggestion to move it over to Qt. Or not. (I don't think we need a QFakeVim in the end but I'd probably make that one of the "Solutions" at some time nevertheless.) > 2. Will the release cycle of the modle be coupled to Creator's release cycle? At least for now: As long as it's not upstreamed, yes. [The interesting granularity here would actually be individual solutions, i.e. currently "TaskTree", "Terminal", and "Spinner". I currently think that we shouldn't overengineer this by, say, having "Sub-component" maintainers, but given that the "Solutions" are by definition independent of each other _maybe_ that's the way to go mid-term. The current proposal is basically to start with minimal bureacratic and maintenance overhead and see how far we get with that.] Andre' -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Proposing new Qt Creator module: Qt Creator Solutions
Hi all. As you may know, we've started to separate parts of code originally created specifically for Qt Creator from other parts of Creator's infrastructure in order to make them more easily reusable in other projects or possible become a proper Qt module at some time. These "Solutions" are currently collected in a subdirectory[1] of the main Qt Creator repo but could be split out further in the future if needed. I propose to make this setup an official Module of Qt Creator, and herewith also nominate Jarek as Maintainer. Jarek has been pushing the idea and is the author of the biggest existing Qt Creator Solution: TaskTree[2], so for me this is the obvious choice. Comments/questions/opinions? Andre' [1] https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/libs/solutions [2] https://wiki.qt.io/TaskTree -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QtWidgets Item / Model / View: tree model examples
On Tue, Nov 21, 2023 at 05:00:43PM +0100, André Somers wrote: > > If not, could we start propagating QTreeWidgetItem or QStandardItem in > > those examples instead to avoid reinventing? > > No, please. I would suggest to instead deprecate these classes, at minimum > the Widgets (QListWidget, QTableWidget and QTreeWidget) and their *Item > classes. These classes lead to horrible code in practice. Propagating their > use in examples is going backwards. I agree with the assessment below but not with the demand to deprecate these classes. QStandardItemModel clumsy to use? When it needs to update/change - sure. Wrong name? Perhaps. Should people use a "real" model? Sure. But: /Any/ deprecation hurts and leave people and projects behind. Not everyone has the means to update at will. And if someone is happy with QStandardItemModel for the task at hand then forcefully destroying this is a bear service. > QStandardItemModel is a complete misnomer, it is anything but standard. > Instead, it should be understood as something like QPrototypeItemModel or > something: suitable to use to play around with or whip up a quick test or > something, but not for production code. The standard way of working should > be writing a real model based around your own application specific data > structures. Make it clear in the docs that this is at best for prototyping or static model, and make it clear that a "real" model will be better almost always. And maybe provide a means to create simple tree models without having to think of invalid grandparents of model indices. > Cheers, > > André Dito. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
