Re: [Development] New Qt example development guideline and revamping examples
Hi,
Heads up for anyone involved in the work of revamping examples and specifically
their documentation:
We've updated the guideline for adding an example to a specific category.
Instead of using the \meta {category} {} command directly, please use
the newly introduced \examplecategory macro instead. This macro expands to the
above \meta command and also adds the example to a category-specific group.
This enables automatic listing of examples per category, as in
https://doc-snapshots.qt.io/qt6-dev/qtexamplesandtutorials.html#application-examples.
Here's the updated part of the guideline:
https://wiki.qt.io/Qt6/Example-Guideline#Categorisation
We've already updated existing occurrences in all qt5 submodules.
Thanks!
\topi
From: Development on behalf of Tuukka
Turunen via Development
Sent: Friday, February 3, 2023 4:07 PM
To: Shawn Rutledge ; Qt Development
Subject: Re: [Development] New Qt example development guideline and revamping
examples
”The point of examples is to show how to use Qt to do specific things. Some of
them are redundant? Well there is not only one way to do things; why should we
hide something cool just because it’s only the second of several choices? In
the future I think we will hesitate to write new examples if the risk of
deletion is so high. ”
On the contrary, target is to make the examples more useful by ensuring all
examples follow the best practices and improving how they are shown in
documentation and creator welcome page. No-one want to delete examples that are
good and useful for our users.
The list I sent is examples that are currently not shown in docs or creator, so
users are not that likely to find them. We should also think why these examples
are not shown? Typically this is not by accident, but it has been determined
that it is better to hide the example.
The list contains 113 examples, so I am sure there are some that would be
better to fix to meet the example guideline, write the documentation and show
the example. But for many of these the value as an example is low. Thus is
better to move to manual tests in case we need it for testing purposes.
Yours,
Tuukka
From: Development on behalf of Shawn
Rutledge via Development
Date: Friday, 3. February 2023 at 15.56
To: Qt Development
Subject: Re: [Development] New Qt example development guideline and revamping
examples
On 3 Feb 2023, at 13:56, Tuukka Turunen via Development
wrote:
pdf/pdfviewer
Depends which one you mean. They are all new and maintained at this point.
There is some redundancy on purpose, because there are multiple PDF-viewing
components. So I wouldn’t delete any of them.
quick/delegatechooser
We need to make sure we are showing DelegateChooser somewhere; it’s quite
useful. I don’t see it in any other examples.
quick/pointerhandlers
I plan to give the pointerhandlers example some proper docs. It only recently
graduated from being a manual test. It may not look like a “proper desktop
application” but that’s not the point.
… many more I don’t remember so well, and then...
wayland/custom-extension
wayland/custom-extension/compositor
wayland/custom-extension/cpp-client
wayland/custom-extension/qml-client
wayland/custom-shell/client-plugin
wayland/custom-shell/compositor
wayland/hwlayer-compositor
wayland/minimal-cpp
wayland/server-buffer
wayland/server-buffer/compositor
wayland/server-buffer/cpp-client
widgets/itemviews/flattreeview
widgets/itemviews/storageview
...
As Kimmo mentioned, we should aim to check and move (or remove if not seen
relevant as a manual test by the module maintainer) these during February.
You are talking about removing them from the manifest, not removing the code, I
hope? Even so...
The point of examples is to show how to use Qt to do specific things. Some of
them are redundant? Well there is not only one way to do things; why should we
hide something cool just because it’s only the second of several choices?
In the future I think we will hesitate to write new examples if the risk of
deletion is so high.
Move them to manual tests? Well that’s better than deleting, but users will
not tend to find those, because we don’t ship them.
Snippets? I think those should be complete enough to actually run. Otherwise
it’s too much work to keep re-verifying that they still work. And it is more
useful to users to start with a complete, minimal example that already runs,
and then add the extra functionality that they want, rather than just some
stanza of code that got broken at some point along the way. With QML that’s
not too hard; so my rule is every QML snippet should be a complete standalone
file that can run with the qml tool. But with C++ snippets it’s not convenient
to make them runnable; so when we convert C++ examples to snippets, we can
expect them to rot, unless we come up with a way to auto-wrap
Re: [Development] New Qt example development guideline and revamping examples
”The point of examples is to show how to use Qt to do specific things. Some of them are redundant? Well there is not only one way to do things; why should we hide something cool just because it’s only the second of several choices? In the future I think we will hesitate to write new examples if the risk of deletion is so high. ” On the contrary, target is to make the examples more useful by ensuring all examples follow the best practices and improving how they are shown in documentation and creator welcome page. No-one want to delete examples that are good and useful for our users. The list I sent is examples that are currently not shown in docs or creator, so users are not that likely to find them. We should also think why these examples are not shown? Typically this is not by accident, but it has been determined that it is better to hide the example. The list contains 113 examples, so I am sure there are some that would be better to fix to meet the example guideline, write the documentation and show the example. But for many of these the value as an example is low. Thus is better to move to manual tests in case we need it for testing purposes. Yours, Tuukka From: Development on behalf of Shawn Rutledge via Development Date: Friday, 3. February 2023 at 15.56 To: Qt Development Subject: Re: [Development] New Qt example development guideline and revamping examples On 3 Feb 2023, at 13:56, Tuukka Turunen via Development wrote: pdf/pdfviewer Depends which one you mean. They are all new and maintained at this point. There is some redundancy on purpose, because there are multiple PDF-viewing components. So I wouldn’t delete any of them. quick/delegatechooser We need to make sure we are showing DelegateChooser somewhere; it’s quite useful. I don’t see it in any other examples. quick/pointerhandlers I plan to give the pointerhandlers example some proper docs. It only recently graduated from being a manual test. It may not look like a “proper desktop application” but that’s not the point. … many more I don’t remember so well, and then... wayland/custom-extension wayland/custom-extension/compositor wayland/custom-extension/cpp-client wayland/custom-extension/qml-client wayland/custom-shell/client-plugin wayland/custom-shell/compositor wayland/hwlayer-compositor wayland/minimal-cpp wayland/server-buffer wayland/server-buffer/compositor wayland/server-buffer/cpp-client widgets/itemviews/flattreeview widgets/itemviews/storageview ... As Kimmo mentioned, we should aim to check and move (or remove if not seen relevant as a manual test by the module maintainer) these during February. You are talking about removing them from the manifest, not removing the code, I hope? Even so... The point of examples is to show how to use Qt to do specific things. Some of them are redundant? Well there is not only one way to do things; why should we hide something cool just because it’s only the second of several choices? In the future I think we will hesitate to write new examples if the risk of deletion is so high. Move them to manual tests? Well that’s better than deleting, but users will not tend to find those, because we don’t ship them. Snippets? I think those should be complete enough to actually run. Otherwise it’s too much work to keep re-verifying that they still work. And it is more useful to users to start with a complete, minimal example that already runs, and then add the extra functionality that they want, rather than just some stanza of code that got broken at some point along the way. With QML that’s not too hard; so my rule is every QML snippet should be a complete standalone file that can run with the qml tool. But with C++ snippets it’s not convenient to make them runnable; so when we convert C++ examples to snippets, we can expect them to rot, unless we come up with a way to auto-wrap them with boilerplate and test them automatically on a periodic basis (in CI, in pre-release testing or whatever). -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
On 3 Feb 2023, at 13:56, Tuukka Turunen via Development wrote: pdf/pdfviewer Depends which one you mean. They are all new and maintained at this point. There is some redundancy on purpose, because there are multiple PDF-viewing components. So I wouldn’t delete any of them. quick/delegatechooser We need to make sure we are showing DelegateChooser somewhere; it’s quite useful. I don’t see it in any other examples. quick/pointerhandlers I plan to give the pointerhandlers example some proper docs. It only recently graduated from being a manual test. It may not look like a “proper desktop application” but that’s not the point. … many more I don’t remember so well, and then... wayland/custom-extension wayland/custom-extension/compositor wayland/custom-extension/cpp-client wayland/custom-extension/qml-client wayland/custom-shell/client-plugin wayland/custom-shell/compositor wayland/hwlayer-compositor wayland/minimal-cpp wayland/server-buffer wayland/server-buffer/compositor wayland/server-buffer/cpp-client widgets/itemviews/flattreeview widgets/itemviews/storageview ... As Kimmo mentioned, we should aim to check and move (or remove if not seen relevant as a manual test by the module maintainer) these during February. You are talking about removing them from the manifest, not removing the code, I hope? Even so... The point of examples is to show how to use Qt to do specific things. Some of them are redundant? Well there is not only one way to do things; why should we hide something cool just because it’s only the second of several choices? In the future I think we will hesitate to write new examples if the risk of deletion is so high. Move them to manual tests? Well that’s better than deleting, but users will not tend to find those, because we don’t ship them. Snippets? I think those should be complete enough to actually run. Otherwise it’s too much work to keep re-verifying that they still work. And it is more useful to users to start with a complete, minimal example that already runs, and then add the extra functionality that they want, rather than just some stanza of code that got broken at some point along the way. With QML that’s not too hard; so my rule is every QML snippet should be a complete standalone file that can run with the qml tool. But with C++ snippets it’s not convenient to make them runnable; so when we convert C++ examples to snippets, we can expect them to rot, unless we come up with a way to auto-wrap them with boilerplate and test them automatically on a periodic basis (in CI, in pre-release testing or whatever). -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
Hi, …and in case unsure what is shown in docs & Creator, it is the ones listed in the manifest file as described at https://doc.qt.io/qt-6/26-qdoc-configuration-example-manifest-files.html and https://wiki.qt.io/Qt_Examples_in_Qt_Creator Mostly these are examples that have not been deemed relevant to show to the users in docs and Creator, often ones that would take quite an effort to update according to the guideline. Rough listing of these: activeqt/simpleqml applicationmanager/application-features/imports/terminator2 applicationmanager/application-features/native/widgets applicationmanager/startup-plugin charts/chartinteractions charts/qmlboxplot charts/qmlcandlestick charts/qmlpiechart core5/widgets/tools/codecs corelib/bindableproperties/bindablesubscription corelib/bindableproperties/subscription corelib/permissions corelib/tools/customtypesending dbus/remotecontrolledcar embedded/digiflip embedded/flickable embedded/flightinfo embedded/lightmaps embedded/raycasting embedded/styleexample ifvehiclefunctions/window-qml interfaceframework/qface-remote/demo interfaceframework/qface-remote/frontend interfaceframework/qface-remote/server_qtro location/geojson_viewer mqtt/consolepubsub mqtt/quickpublication multimedia/audiodecoder multimedia/devices network/dnslookup network/multistreamclient network/multistreamserver oauth/redditclient oauth/twittertimeline opcua/waterpump/simulationserver opengl/computegles31 opengl/contextinfo opengl/hellowindow opengl/paintedwindow opengl/qopenglwidget opengl/qopenglwindow opengl/threadedqopenglwidget pdf/pdfviewer qml/qmldom qml/shell qmltest/qmltest qpa/qrasterwindow qpa/windows qt3d/3d-text qt3d/anaglyph-rendering qt3d/compute-particles qt3d/controls qt3d/controlsunderlay qt3d/instanced-arrays-qml qt3d/lights qt3d/phong-cubes qt3d/qardboard qt3d/qgltf quick/customitems/maskedmousearea quick/delegatechooser quick/customitems/scrollbar/scrollbar.pro quick/customitems/tabwidget/tabwidget.pro quick/embeddedinwidgets quick/multieffect/itemswitcher quick/multieffect/testbed quick/particles/itemparticle quick/pointerhandlers quick/scenegraph/threadedanimation quick3d/helloqtquick3d quick3d/offlineshaders remoteobjects/ble/bleclient remoteobjects/ble/bleserver remoteobjects/clientapp remoteobjects/cppclient remoteobjects/plugins remoteobjects/remoteobjects_server remoteobjects/simpleswitch/directconnectclient remoteobjects/simpleswitch/directconnectdynamicclient remoteobjects/simpleswitch/directconnectserver remoteobjects/simpleswitch/registryconnectedclient remoteobjects/simpleswitch/registryconnectedserver remoteobjects/ssl/sslcppclient remoteobjects/ssl/sslserver remoteobjects/websockets/wsclient remoteobjects/websockets/wsserver sensors/grue/console_app sensors/grue/plugin serialport/receiver serialport/sender spatialaudio/audiopanning svg/draganddrop/delayedencoding svg/embedded/desktopservices svg/embedded/fluidlauncher svg/embedded/weatherinfo svg/embeddedsvgviewer wayland/custom-extension wayland/custom-extension/compositor wayland/custom-extension/cpp-client wayland/custom-extension/qml-client wayland/custom-shell/client-plugin wayland/custom-shell/compositor wayland/hwlayer-compositor wayland/minimal-cpp wayland/server-buffer wayland/server-buffer/compositor wayland/server-buffer/cpp-client widgets/itemviews/flattreeview widgets/itemviews/storageview widgets/scroller/graphicsview widgets/tools/plugandpaint widgets/windowcontainer xml/htmlinfo xml/rsslisting As Kimmo mentioned, we should aim to check and move (or remove if not seen relevant as a manual test by the module maintainer) these during February. Yours, Tuukka From: Development on behalf of Kimmo Leppälä via Development Date: Friday, 3. February 2023 at 9.03 To: development@qt-project.org Subject: Re: [Development] New Qt example development guideline and revamping examples Hi, There has been slight modifications to the guideline document https://wiki.qt.io/Qt6/Example-Guideline Most important change being that the examples that are not shown in Qt documentation should be moved under tests/manual/examples. This cleanup should be done preferably during February so that we have cleared away the examples we don’t want to revamp at this point. Thanks! -Kimmo On 19.1.2023, 9.25, "Kimmo Leppälä" wrote: Hi, Thank you for the proposals Giuseppe! On 18.1.2023, 14.14, "Development" wrote: On 18/01/2023 10:51, Kimmo Leppälä via Development wrote: > Also, the guideline is a living document in wiki and we would be happy > to hear feedback and proposals for it! > Here's a few considerations: > RECOMMENDED > Consider also compiling with the more strict warning flags and fix any issues > they reveal. As history shows, this is not going to happen unless we enforce it. The cmake-magic macros that are used to build examples should set those more strict flags and enforce them (-Werror). > Clang > Use -Weverything co
Re: [Development] New Qt example development guideline and revamping examples
Hi,
There has been slight modifications to the guideline document
https://wiki.qt.io/Qt6/Example-Guideline
Most important change being that the examples that are not shown in Qt
documentation should be moved under tests/manual/examples. This cleanup should
be done preferably during February so that we have cleared away the examples we
don’t want to revamp at this point.
Thanks!
-Kimmo
On 19.1.2023, 9.25, "Kimmo Leppälä" wrote:
Hi,
Thank you for the proposals Giuseppe!
On 18.1.2023, 14.14, "Development" wrote:
On 18/01/2023 10:51, Kimmo Leppälä via Development wrote:
> Also, the guideline is a living document in wiki and we would be happy
> to hear feedback and proposals for it!
>
Here's a few considerations:
> RECOMMENDED
> Consider also compiling with the more strict warning flags and fix any issues
> they reveal.
As history shows, this is not going to happen unless we enforce it. The
cmake-magic macros that are used to build examples should set those more
strict flags and enforce them (-Werror).
> Clang
> Use -Weverything compiler parameter
> Visual Studio
> Use /Wall compiler parameter
These aren't good recommendations. There's basically no code that
survives those flags, incl. libc++/MS-STL own headers.
Yes, if we enforce with (-Werror) these would be too strict but the warning
flags were meant to be enabled without enforcing and then use human judgement
if something needs to be fixed.
I changed wiki page to make it clear that consideration should be used and also
that focus is on fixing the example codebase, not all the dependencies.
In addition we could define explicit set of warning flags that should be used
when enforced with -werror.
Did you already have a list of flags in mind?
> RECOMMENDED
>
> Prefer signal/slot connection with lambdas:
> https://doc.qt.io/qt-6/signalsandslots.html
All the contrary, do NOT do that, as it results in 200+ lines unnamed
lambdas. Strongly prefer named slots. Keep the lambdas short and to the
point. Do not use unnamed lambdas.
I changed the wiki page like so:
*Consider using signal/slot connection with lambdas:
https://doc.qt.io/qt-6/signalsandslots.html
**Keep lambdas short and to the point
**Don't use unnamed lambdas
> Check Qt Coding conventions: https://wiki.qt.io/Coding_Conventions
This shouldn't be "recommended" but mandatory. We must follow the same
style in examples as we do in the rest of our code.
> Consider using clazy plugin (comes also with Qt Creator):
> https://www.qt.io/blog/porting-from-qt-5-to-qt-6-using-clazy-checks
This should also be mandatory and enforced by CI.
I moved these under mandatory.
> Add example application to correct category, for instance by adding '\meta
> category {Graphics & UI}' below '\examples'
Is there a list of categories to pick from?
This is still being worked on but should be available this week.
The list will then be linked or included in the guideline document.
-Kimmo
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
On 20 Jan 2023, at 10:45, Tor Arne Vestbø via Development wrote: On 20 Jan 2023, at 09:49, Eike Ziller wrote: Am 19/01/2023 um 13:33 schrieb Giuseppe D'Angelo via Development : Il 19/01/23 10:27, Tor Arne Vestbø ha scritto: All the contrary, do NOT do that, as it results in 200+ lines unnamed lambdas. Strongly prefer named slots. Keep the lambdas short and to the point. Do not use unnamed lambdas. No, strongly prefer lambdas if they are within a reasonable size. No-one is arguing for 200+ line lambdas. The reason for such a harsh rule is that "reasonable size" tends to go out of control very quickly. Is 10 lines too much? Maybe 15? Giving it a fixed size opens up the door to a sorites paradox. The point is that when you write the lambda the first time, it'll be completely obvious what it does to you, even if it's long. You'll even avoid giving it a name and connect straight to it, as it makes "perfect sense", in the context of the code surrounding the lambda. But on the long run, this makes the code worse to read and understand. No one will understand what the lambda is _meant_ to do without analyzing the body of the lambda, line by line (cf.: a named lambda/slot, where a proper name tells you everything). And reasoning on the code surrounding the lambda is also much harder as it's intermingled with the lambda itself. If anything: the fact that this is seen as _questionable_ and people disagree on it should be a good indication that examples shouldn't do it, as examples shouldn't feature _questionable_ code styles. I think with that argument any code style fall apart. People find using "auto" questionable, and other people find _not_ using "auto" questionable. Some people find that not using braces for bodies of conditional statements, even if they are just one line, is questionable, other people find that using braces for one-line bodies would bloat the code. I find not using unnamed lambdas at all questionable. IMO named lambdas are worse, since they are also inline inbetween other code in the function, so they need to be small too (with the same question of what "small" means), but a reader trying to figure out what happens at the place where it is used need to redirect to whereever it is defined. Names are often not good enough to convey enough meaning, often the actual details matter, and glancing on the handful of lines of code directly inline is often faster to read. And not using lambdas at all means creating lots of member functions that are only used once, bloat the class API, with the same issue of requiring redirection when read, and possibly creating class member variables just for use of single methods which could be easily solved by capturing in a lambda. Exactly. All of what Eike said. 200+ line lambdas are bad. So are single-line slots that could have been a lambda. Let’s trust people to use good judgement to decide each case, including when to rewrite a lambda as a slot when it becomes bigger. Tor Arne I think the respective statement should actually rather say: "Use pointer-to-member-function syntax for signal/slot connections.” And this statement should then be mandatory. There are cases where we need to use string-based connection, but they are obscure and probably not good example-material in the first place, unless it’s an example about the meta object system. As for the “length of lambdas": code changes often require refactoring to keep the code readable and maintainable. That doesn’t always happen, but it doesn’t mean that we have to always code like we can’t move things around later. I sometimes end up with a long lambda in a function that has one line of code before and one line after it. It wouldn’t be very helpful to move that lambda into a different function. But if the code before and after grows, then the right thing to do will be to split things up. Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
On 20 Jan 2023, at 09:49, Eike Ziller wrote: Am 19/01/2023 um 13:33 schrieb Giuseppe D'Angelo via Development : Il 19/01/23 10:27, Tor Arne Vestbø ha scritto: All the contrary, do NOT do that, as it results in 200+ lines unnamed lambdas. Strongly prefer named slots. Keep the lambdas short and to the point. Do not use unnamed lambdas. No, strongly prefer lambdas if they are within a reasonable size. No-one is arguing for 200+ line lambdas. The reason for such a harsh rule is that "reasonable size" tends to go out of control very quickly. Is 10 lines too much? Maybe 15? Giving it a fixed size opens up the door to a sorites paradox. The point is that when you write the lambda the first time, it'll be completely obvious what it does to you, even if it's long. You'll even avoid giving it a name and connect straight to it, as it makes "perfect sense", in the context of the code surrounding the lambda. But on the long run, this makes the code worse to read and understand. No one will understand what the lambda is _meant_ to do without analyzing the body of the lambda, line by line (cf.: a named lambda/slot, where a proper name tells you everything). And reasoning on the code surrounding the lambda is also much harder as it's intermingled with the lambda itself. If anything: the fact that this is seen as _questionable_ and people disagree on it should be a good indication that examples shouldn't do it, as examples shouldn't feature _questionable_ code styles. I think with that argument any code style fall apart. People find using "auto" questionable, and other people find _not_ using "auto" questionable. Some people find that not using braces for bodies of conditional statements, even if they are just one line, is questionable, other people find that using braces for one-line bodies would bloat the code. I find not using unnamed lambdas at all questionable. IMO named lambdas are worse, since they are also inline inbetween other code in the function, so they need to be small too (with the same question of what "small" means), but a reader trying to figure out what happens at the place where it is used need to redirect to whereever it is defined. Names are often not good enough to convey enough meaning, often the actual details matter, and glancing on the handful of lines of code directly inline is often faster to read. And not using lambdas at all means creating lots of member functions that are only used once, bloat the class API, with the same issue of requiring redirection when read, and possibly creating class member variables just for use of single methods which could be easily solved by capturing in a lambda. Exactly. All of what Eike said. 200+ line lambdas are bad. So are single-line slots that could have been a lambda. Let’s trust people to use good judgement to decide each case, including when to rewrite a lambda as a slot when it becomes bigger. Tor Arne ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
> Am 19/01/2023 um 13:33 schrieb Giuseppe D'Angelo via Development > : > > Il 19/01/23 10:27, Tor Arne Vestbø ha scritto: >>> All the contrary, do NOT do that, as it results in 200+ lines unnamed >>> lambdas. Strongly prefer named slots. Keep the lambdas short and to the >>> point. Do not use unnamed lambdas. >> No, strongly prefer lambdas if they are within a reasonable size. No-one is >> arguing for 200+ line lambdas. > > The reason for such a harsh rule is that "reasonable size" tends to go out of > control very quickly. Is 10 lines too much? Maybe 15? Giving it a fixed size > opens up the door to a sorites paradox. The point is that when you write the > lambda the first time, it'll be completely obvious what it does to you, even > if it's long. You'll even avoid giving it a name and connect straight to it, > as it makes "perfect sense", in the context of the code surrounding the > lambda. > > But on the long run, this makes the code worse to read and understand. No one > will understand what the lambda is _meant_ to do without analyzing the body > of the lambda, line by line (cf.: a named lambda/slot, where a proper name > tells you everything). And reasoning on the code surrounding the lambda is > also much harder as it's intermingled with the lambda itself. > > If anything: the fact that this is seen as _questionable_ and people disagree > on it should be a good indication that examples shouldn't do it, as examples > shouldn't feature _questionable_ code styles. I think with that argument any code style fall apart. People find using "auto" questionable, and other people find _not_ using "auto" questionable. Some people find that not using braces for bodies of conditional statements, even if they are just one line, is questionable, other people find that using braces for one-line bodies would bloat the code. I find not using unnamed lambdas at all questionable. IMO named lambdas are worse, since they are also inline inbetween other code in the function, so they need to be small too (with the same question of what "small" means), but a reader trying to figure out what happens at the place where it is used need to redirect to whereever it is defined. Names are often not good enough to convey enough meaning, often the actual details matter, and glancing on the handful of lines of code directly inline is often faster to read. And not using lambdas at all means creating lots of member functions that are only used once, bloat the class API, with the same issue of requiring redirection when read, and possibly creating class member variables just for use of single methods which could be easily solved by capturing in a lambda. Br, Eike ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
On Thu, Jan 19, 2023 at 01:44:16PM +, Friedemann Kleint via Development wrote: > Hi, > > we also need to agree on whether the Qt library rules apply to the > full extent; for example: > > - Do we use the modern string literals (u"bla"_s, previously, example > code just constructed QString from ASCII and did not care about > -DQT_NO_CAST_FROM_ASCII, IIRC) I'd rather keep it concise, i.e. undecorated or _at most_ u"..." The prefered "modern" decoration changes rather rapidly (I think the previous incarnation barely survived a year in Qt base) and on the application side there's practically no user-noticable benefit at the price of serious developer time to stay "up to date". I wouldn't encourage through the examples. So: -1 > - Should tr() be used for all user-facing messages (although examples > mostly do not have translations set up) On the pro side this solves the string decoration problem, on the con side this uses the automatic class contexts which I don't think are a good idea for larger application and also requires "weird" Q_OBJECT / Q_DECLARE_TR_FUNCTION setup. So: +/- 0 on this one... > - Do we use std::as_const to avoid detaching > containers in loops (mostly missing for code ported from Q_FOREACH) +1 > Generally, when polishing examples, I found that member initialization > greatly simplifies code. +1 Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
Den tors 19 jan. 2023 13:34Giuseppe D'Angelo via Development < development@qt-project.org> skrev: > Il 19/01/23 10:27, Tor Arne Vestbø ha scritto: > >> All the contrary, do NOT do that, as it results in 200+ lines unnamed > lambdas. Strongly prefer named slots. Keep the lambdas short and to the > point. Do not use unnamed lambdas. > > No, strongly prefer lambdas if they are within a reasonable size. No-one > is arguing for 200+ line lambdas. > > The reason for such a harsh rule is that "reasonable size" tends to go > out of control very quickly. Is 10 lines too much? Maybe 15? Giving it a > fixed size opens up the door to a sorites paradox. The point is that > when you write the lambda the first time, it'll be completely obvious > what it does to you, even if it's long. You'll even avoid giving it a > name and connect straight to it, as it makes "perfect sense", in the > context of the code surrounding the lambda. > > But on the long run, this makes the code worse to read and understand. > No one will understand what the lambda is _meant_ to do without > analyzing the body of the lambda, line by line (cf.: a named > lambda/slot, where a proper name tells you everything). And reasoning on > the code surrounding the lambda is also much harder as it's intermingled > with the lambda itself. > > If anything: the fact that this is seen as _questionable_ and people > disagree on it should be a good indication that examples shouldn't do > it, as examples shouldn't feature _questionable_ code styles. > Agree. Code base I'm working on now is starting to get infested with "swollen" lambdas. Happens easier than you think. Elvis > My 2 c, > -- > Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > KDAB - The Qt, C++ and OpenGL Experts > > ___ > 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] New Qt example development guideline and revamping examples
On Thursday, 19 January 2023 05:44:16 PST Friedemann Kleint via Development wrote: > - Do we use the modern string literals (u"bla"_s, previously, example code > just constructed QString from ASCII and did not care about > -DQT_NO_CAST_FROM_ASCII, IIRC) I don't mind using modern string literals, but don't set QT_NO_CAST_FROM_ASCII. That means non u"" strings are fine. Separate problem: we have to figure out a way that u"bla" without _s also works. It HAS to work. > - Should tr() be used for all user-facing messages (although examples > mostly do not have translations set up) Would be good, yes. > - Do we use std::as_const to avoid detaching containers in loops (mostly > missing for code ported from Q_FOREACH) Yes, that's good practice. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
Hi, we also need to agree on whether the Qt library rules apply to the full extent; for example: - Do we use the modern string literals (u"bla"_s, previously, example code just constructed QString from ASCII and did not care about -DQT_NO_CAST_FROM_ASCII, IIRC) - Should tr() be used for all user-facing messages (although examples mostly do not have translations set up) - Do we use std::as_const to avoid detaching containers in loops (mostly missing for code ported from Q_FOREACH) and probably some more? Generally, when polishing examples, I found that member initialization greatly simplifies code. Regards, Friedemann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
Il 19/01/23 10:27, Tor Arne Vestbø ha scritto: All the contrary, do NOT do that, as it results in 200+ lines unnamed lambdas. Strongly prefer named slots. Keep the lambdas short and to the point. Do not use unnamed lambdas. No, strongly prefer lambdas if they are within a reasonable size. No-one is arguing for 200+ line lambdas. The reason for such a harsh rule is that "reasonable size" tends to go out of control very quickly. Is 10 lines too much? Maybe 15? Giving it a fixed size opens up the door to a sorites paradox. The point is that when you write the lambda the first time, it'll be completely obvious what it does to you, even if it's long. You'll even avoid giving it a name and connect straight to it, as it makes "perfect sense", in the context of the code surrounding the lambda. But on the long run, this makes the code worse to read and understand. No one will understand what the lambda is _meant_ to do without analyzing the body of the lambda, line by line (cf.: a named lambda/slot, where a proper name tells you everything). And reasoning on the code surrounding the lambda is also much harder as it's intermingled with the lambda itself. If anything: the fact that this is seen as _questionable_ and people disagree on it should be a good indication that examples shouldn't do it, as examples shouldn't feature _questionable_ code styles. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
> On 18 Jan 2023, at 13:12, Giuseppe D'Angelo via Development > wrote: > >> RECOMMENDED >>Prefer signal/slot connection with lambdas: >> https://doc.qt.io/qt-6/signalsandslots.html > > All the contrary, do NOT do that, as it results in 200+ lines unnamed > lambdas. Strongly prefer named slots. Keep the lambdas short and to the > point. Do not use unnamed lambdas. No, strongly prefer lambdas if they are within a reasonable size. No-one is arguing for 200+ line lambdas. Tor Arne ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
On 1/18/23 19:56, A. Pönitz wrote: As a data point, even at it's height of .ui usage, Qt Creator (which is a "namespace aware" code base, see https://wiki.qt.io/Qt_In_Namespace) needed the QT_*_NAMESPACE for about 30 of its >200 .ui classes, and that in the presence of ~680 places where it was needed for other reasons. That's probably because we went out of our way to explicitly add a namespace to the types in the ui file. If it had been considered a problem at the time, we'd probably had the uic flag for 13 years or so... There are various bug reports along the lines of https://bugreports.qt.io/browse/QTCREATORBUG-19590, which we basically ignored. Christian ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
Hi,
Thank you for the proposals Giuseppe!
On 18.1.2023, 14.14, "Development" wrote:
On 18/01/2023 10:51, Kimmo Leppälä via Development wrote:
> Also, the guideline is a living document in wiki and we would be happy
> to hear feedback and proposals for it!
>
Here's a few considerations:
> RECOMMENDED
> Consider also compiling with the more strict warning flags and fix any issues
> they reveal.
As history shows, this is not going to happen unless we enforce it. The
cmake-magic macros that are used to build examples should set those more
strict flags and enforce them (-Werror).
> Clang
> Use -Weverything compiler parameter
> Visual Studio
> Use /Wall compiler parameter
These aren't good recommendations. There's basically no code that
survives those flags, incl. libc++/MS-STL own headers.
Yes, if we enforce with (-Werror) these would be too strict but the warning
flags were meant to be enabled without enforcing and then use human judgement
if something needs to be fixed.
I changed wiki page to make it clear that consideration should be used and also
that focus is on fixing the example codebase, not all the dependencies.
In addition we could define explicit set of warning flags that should be used
when enforced with -werror.
Did you already have a list of flags in mind?
> RECOMMENDED
>
> Prefer signal/slot connection with lambdas:
> https://doc.qt.io/qt-6/signalsandslots.html
All the contrary, do NOT do that, as it results in 200+ lines unnamed
lambdas. Strongly prefer named slots. Keep the lambdas short and to the
point. Do not use unnamed lambdas.
I changed the wiki page like so:
*Consider using signal/slot connection with lambdas:
https://doc.qt.io/qt-6/signalsandslots.html
**Keep lambdas short and to the point
**Don't use unnamed lambdas
> Check Qt Coding conventions: https://wiki.qt.io/Coding_Conventions
This shouldn't be "recommended" but mandatory. We must follow the same
style in examples as we do in the rest of our code.
> Consider using clazy plugin (comes also with Qt Creator):
> https://www.qt.io/blog/porting-from-qt-5-to-qt-6-using-clazy-checks
This should also be mandatory and enforced by CI.
I moved these under mandatory.
> Add example application to correct category, for instance by adding '\meta
> category {Graphics & UI}' below '\examples'
Is there a list of categories to pick from?
This is still being worked on but should be available this week.
The list will then be linked or included in the guideline document.
-Kimmo
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
On Wed, Jan 18, 2023 at 04:10:20PM +, Kai Köhne via Development wrote: > > -Original Message- > >[...] > > > > MANDATORY > > > > > > Do not use QT_BEGIN_NAMESPACE ... QT_END_NAMESPACE for example > > types. This namespace is exclusively for types in the Qt libraries. > > > > This is broken. How is one going to correctly forward declare Qt names > > in a namespaced build of Qt without using those macros? > > Option 1: Do not forward declare the Qt type, but just include the right Qt > header. > Option 2: Use QT_BEGIN_NAMESPACE..QT_END_NAMESPACE, but only for Qt types, > _not_ for all header content. Option 3: Add a flag to uic to give the user control on the emission of the macros. There's a patch on gerrit for that now. Lacking that, I'd go for Option 1: The examples are small, #include'ing a "unneeded" header is not deadly. > The rule just says that wrapping all of your headers with QT_BEGIN_NAMESPACE, > QT_END_NAMESPACE is a misfeature which shouldn't be cargo-culted. Was this ever the rule for examples? > > Is there perhaps a more comprehensive discussion regarding how to > > write examples that cope with namespaced Qt builds? > > Personally, I wouldn't even mind if Qt examples wouldn't compile with > a namespaced Qt (-qtnamespace configure argument), because I feel it's > a somewhat specialist feature. > But alas, we have at least one CI configuration that builds with > -qtnamespace and Qt examples, so we might as well keep it working. Yes, please. > (A nasty feature of uic is btw that it also does generate C++ code > inside QT_BEGIN_NAMESPACE, QT_END_NAMESPACE. That is, if you have a > .ui file for a Dialog, and you want to pre-declare the type generated > by uic, you have to also put it in QT_BEGIN_NAMESPACE, > QT_END_NAMESPACE, Not quite. This is only ever needed once (non-personally) you want to use a namespaced Qt for your own code or at least for one configuration of the code. Anywhere else you can sprinkle in QT_BEGIN_NAMESPACE or leave it out at will, it doesn't do anything. As you (personally) correctly state, this is a somewhat specialist feature, so in practice not many are affected at all, and these that are affected have to sprinkle QT_BEGIN_NAMESPACE and QT_END_NAMESPACE around forward-declarations of Qt classes anyway. As a data point, even at it's height of .ui usage, Qt Creator (which is a "namespace aware" code base, see https://wiki.qt.io/Qt_In_Namespace) needed the QT_*_NAMESPACE for about 30 of its >200 .ui classes, and that in the presence of ~680 places where it was needed for other reasons. So basically, this "evil misfeature" adds < 5% to the overall problem of having a Qt-namespace-aware (and 0% for a Qt-namespaced) codebase, a ratio that was not exactly predicted, but very roughly expected and accepted so at the time the feature was implemented. If it had been considered a problem at the time, we'd probably had the uic flag for 13 years or so... > which is a bit surprising to me Anyhow, changing > this is probably not worth the breakages anymore ... I still think there is no Real Problem (with the solution for the examples being to #include the Q* headers), and - as fallback if that's considered too pragmatic for 2023 - to have a uic flag. In neither case anything would break. [Nor would I need to think about what "not worth ... anymore" could possibly mean...] Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
Il 18/01/23 17:10, Kai Köhne ha scritto: (A nasty feature of uic is btw that it also does generate C++ code inside QT_BEGIN_NAMESPACE, QT_END_NAMESPACE. That is, if you have a .ui file for a Dialog, and you want to pre-declare the type generated by uic, you have to also put it in QT_BEGIN_NAMESPACE, QT_END_NAMESPACE, which is a bit surprising to me . Anyhow, changing this is probably not worth the breakages anymore ... Well, it also makes no sense to keep doing it that way. The code that uic generates belongs to the application, not to Qt. uic could get a -namespace X option and generate things in that namespace. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
Il 18/01/23 17:10, Kai Köhne ha scritto: Do not use QT_BEGIN_NAMESPACE ... QT_END_NAMESPACE for example types. This namespace is exclusively for types in the Qt libraries. This is broken. How is one going to correctly forward declare Qt names in a namespaced build of Qt without using those macros? Option 1: Do not forward declare the Qt type, but just include the right Qt header. Option 2: Use QT_BEGIN_NAMESPACE..QT_END_NAMESPACE, but only for Qt types,_not_ for all header content. The rule just says that wrapping all of your headers with QT_BEGIN_NAMESPACE, QT_END_NAMESPACE is a misfeature which shouldn't be cargo-culted. OK, so, the right way to read that rule is that examples shouldn't themselves be declaring things in Qt's namespace. That makes total sense -- no one is allowed to declare things in Qt's namespace but Qt. Using the namespace macros themselves is fine in order to cope with namespaced builds, e.g. to forward declare Qt types. I would then also extend the rule, i.e. examples must not introduce any identifier that Qt reserves for itself: * no class beginning with capital Q * no function beginning with lower q * no macro beginning with Q * ... unless of course they're customization points, like qHash. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
> -Original Message- >[...] > > MANDATORY > > > > Do not use QT_BEGIN_NAMESPACE ... QT_END_NAMESPACE for example > types. This namespace is exclusively for types in the Qt libraries. > > This is broken. How is one going to correctly forward declare Qt names > in a namespaced build of Qt without using those macros? Option 1: Do not forward declare the Qt type, but just include the right Qt header. Option 2: Use QT_BEGIN_NAMESPACE..QT_END_NAMESPACE, but only for Qt types, _not_ for all header content. The rule just says that wrapping all of your headers with QT_BEGIN_NAMESPACE, QT_END_NAMESPACE is a misfeature which shouldn't be cargo-culted. > Is there perhaps > a more comprehensive discussion regarding how to write examples that > cope with namespaced Qt builds? Personally, I wouldn't even mind if Qt examples wouldn't compile with a namespaced Qt (-qtnamespace configure argument), because I feel it's a somewhat specialist feature. But alas, we have at least one CI configuration that builds with -qtnamespace and Qt examples, so we might as well keep it working. (A nasty feature of uic is btw that it also does generate C++ code inside QT_BEGIN_NAMESPACE, QT_END_NAMESPACE. That is, if you have a .ui file for a Dialog, and you want to pre-declare the type generated by uic, you have to also put it in QT_BEGIN_NAMESPACE, QT_END_NAMESPACE, which is a bit surprising to me . Anyhow, changing this is probably not worth the breakages anymore ... Kai ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
On 18/01/2023 10:51, Kimmo Leppälä via Development wrote:
Also, the guideline is a living document in wiki and we would be happy
to hear feedback and proposals for it!
Here's a few considerations:
RECOMMENDED
Consider also compiling with the more strict warning flags and fix any issues they reveal.
As history shows, this is not going to happen unless we enforce it. The
cmake-magic macros that are used to build examples should set those more
strict flags and enforce them (-Werror).
Clang
Use -Weverything compiler parameter
Visual Studio
Use /Wall compiler parameter
These aren't good recommendations. There's basically no code that
survives those flags, incl. libc++/MS-STL own headers.
RECOMMENDED
Prefer signal/slot connection with lambdas:
https://doc.qt.io/qt-6/signalsandslots.html
All the contrary, do NOT do that, as it results in 200+ lines unnamed
lambdas. Strongly prefer named slots. Keep the lambdas short and to the
point. Do not use unnamed lambdas.
Check Qt Coding conventions: https://wiki.qt.io/Coding_Conventions
This shouldn't be "recommended" but mandatory. We must follow the same
style in examples as we do in the rest of our code.
Consider using clazy plugin (comes also with Qt Creator):
https://www.qt.io/blog/porting-from-qt-5-to-qt-6-using-clazy-checks
This should also be mandatory and enforced by CI.
Add example application to correct category, for instance by adding '\meta category
{Graphics & UI}' below '\examples'
Is there a list of categories to pick from?
MANDATORY
Do not use QT_BEGIN_NAMESPACE ... QT_END_NAMESPACE for example types. This
namespace is exclusively for types in the Qt libraries.
This is broken. How is one going to correctly forward declare Qt names
in a namespaced build of Qt without using those macros? Is there perhaps
a more comprehensive discussion regarding how to write examples that
cope with namespaced Qt builds?
Thank you,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
Hi, Yes, intention is to improve also the application / project examples in qtdoc repo. In addition to the Qt 6 best practices, these could also get a bit of visual or functionality polish. Problematic or unnecessary existing examples could be removed. Intention is also to adjust how the examples are categorized and thus provide these ones more towards the user (e.g. top of the Creator welcome page). Some selected examples from other repos could be moved to qtdoc and extended. See: https://bugreports.qt.io/browse/QTBUG-108751 for planning related to the qtdoc examples. Note that while qtdoc has these example apps under ‘examples/demos’ folder, they are still in principle examples of how to use Qt to make an application. Yours, Tuukka From: Development on behalf of Rui Oliveira Date: Wednesday, 18. January 2023 at 12.14 To: development@qt-project.org Subject: Re: [Development] New Qt example development guideline and revamping examples Hello, I'd like to point to https://bugreports.qt.io/browse/QTBUG-100100 where you can read: "Ah, those examples are in the qtdoc repository, where nobody looks at them..." "Back when we worked on QTBUG-98130, we forgot to add the examples in qtdoc to the list." Are these going to receive love as well? I don't like to see scattered stuff diverge... Thanks, Rui Às 09:37 de 18/01/2023, Kimmo Leppälä via Development escreveu: Hi, We have started revamping Qt examples (https://doc.qt.io/qt-6/qtexamples.html) to follow the new example development guideline: https://wiki.qt.io/Qt6/Example-Guideline. Target is to go through all the ~600 examples and either modify according the guideline or remove, if the example is obsolete or redundant and complete this activity by the end of June 2023. Cheers, Kimmo Leppälä ___ Development mailing list Development@qt-project.org<mailto: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] New Qt example development guideline and revamping examples
Hi, Typically pick to 6.5 as the examples like documentation is unproblematic to update. Yours, Tuukka From: Development on behalf of Ivan Solovev via Development Date: Wednesday, 18. January 2023 at 12.09 To: development@qt-project.org , Kimmo Leppälä Subject: Re: [Development] New Qt example development guideline and revamping examples Hi, Should the example updates be picked to 6.5, or is it only a 6.6 thing? Is there any general guideline from the Release Team? Best regards, Ivan From: Development on behalf of Kimmo Leppälä via Development Sent: Wednesday, January 18, 2023 10:51 AM To: development@qt-project.org Subject: Re: [Development] New Qt example development guideline and revamping examples Also, the guideline is a living document in wiki and we would be happy to hear feedback and proposals for it! -Kimmo From: Kimmo Leppälä Date: Wednesday, 18. January 2023 at 11.37 To: development@qt-project.org Subject: New Qt example development guideline and revamping examples Hi, We have started revamping Qt examples (https://doc.qt.io/qt-6/qtexamples.html) to follow the new example development guideline: https://wiki.qt.io/Qt6/Example-Guideline. Target is to go through all the ~600 examples and either modify according the guideline or remove, if the example is obsolete or redundant and complete this activity by the end of June 2023. Cheers, Kimmo Leppälä ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
Hello, I'd like to point to https://bugreports.qt.io/browse/QTBUG-100100 where you can read: "Ah, those examples are in the qtdoc repository, where nobody looks at them..." "Back when we worked on QTBUG-98130, we forgot to add the examples in qtdoc to the list." Are these going to receive love as well? I don't like to see scattered stuff diverge... Thanks, Rui Às 09:37 de 18/01/2023, Kimmo Leppälä via Development escreveu: Hi, We have started revamping Qt examples (https://doc.qt.io/qt-6/qtexamples.html) to follow the new example development guideline: https://wiki.qt.io/Qt6/Example-Guideline. Target is to go through all the ~600 examples and either modifyaccording the guidelineor remove, if the example is obsolete or redundant and complete this activity by the end of June2023. Cheers, Kimmo Leppälä ___ 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] New Qt example development guideline and revamping examples
Hi, Should the example updates be picked to 6.5, or is it only a 6.6 thing? Is there any general guideline from the Release Team? Best regards, Ivan From: Development on behalf of Kimmo Leppälä via Development Sent: Wednesday, January 18, 2023 10:51 AM To: development@qt-project.org Subject: Re: [Development] New Qt example development guideline and revamping examples Also, the guideline is a living document in wiki and we would be happy to hear feedback and proposals for it! -Kimmo From: Kimmo Leppälä Date: Wednesday, 18. January 2023 at 11.37 To: development@qt-project.org Subject: New Qt example development guideline and revamping examples Hi, We have started revamping Qt examples (https://doc.qt.io/qt-6/qtexamples.html) to follow the new example development guideline: https://wiki.qt.io/Qt6/Example-Guideline. Target is to go through all the ~600 examples and either modify according the guideline or remove, if the example is obsolete or redundant and complete this activity by the end of June 2023. Cheers, Kimmo Leppälä ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
Also, the guideline is a living document in wiki and we would be happy to hear feedback and proposals for it! -Kimmo From: Kimmo Leppälä Date: Wednesday, 18. January 2023 at 11.37 To: development@qt-project.org Subject: New Qt example development guideline and revamping examples Hi, We have started revamping Qt examples (https://doc.qt.io/qt-6/qtexamples.html) to follow the new example development guideline: https://wiki.qt.io/Qt6/Example-Guideline. Target is to go through all the ~600 examples and either modify according the guideline or remove, if the example is obsolete or redundant and complete this activity by the end of June 2023. Cheers, Kimmo Leppälä ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] New Qt example development guideline and revamping examples
Hi, We have started revamping Qt examples (https://doc.qt.io/qt-6/qtexamples.html) to follow the new example development guideline: https://wiki.qt.io/Qt6/Example-Guideline. Target is to go through all the ~600 examples and either modify according the guideline or remove, if the example is obsolete or redundant and complete this activity by the end of June 2023. Cheers, Kimmo Leppälä ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
