Hi,
btw, we are facing a similar problem when generating the documentation
for the PySide2 project (Python bindings for Qt). The code snippets are
different; most of the text is similar.
So, the issue could be generalized for any language bindings of Qt.
Regards, Friedemann
--
Friedemann Kl
>What would be incorrect as those APIs are only internal for C++, but
>public for QML or v.v.
Then we need \cpponly and \qmlonly, or something like that.
From: Development on
behalf of Uwe Rathmann
Sent: Tuesday, April 25, 2017 8:12:44 AM
To: development
> On 24 Apr 2017, at 16:17, Sean Harmer wrote:
>
> Hi,
>
> On 24/04/2017 14:23, Martin Smith wrote:
>> Regarding documenting both C++ and QML at the same time, I will be happy to
>> implement it if we can get a good idea for how to do it.
>
> Well, take https://codereview.qt-project.org/#/c/1
On Tuesday 25 April 2017 06:45:04 André Somers wrote:
> Op 24/04/2017 om 20:39 schreef Marc Mutz:
> > On 2017-04-24 20:19, Ville Voutilainen wrote:
> > [...]
> >
> >> What is wrong with QArrayList?
> >
> > Nothing, IMO, in the version proposed by me:
> > https://codereview.qt-project.org/188938
>
On Tue, 25 Apr 2017 06:05:38 +, Martin Smith wrote:
> Use \internal in their qdoc comments to tell qdoc not to include them.
What would be incorrect as those APIs are only internal for C++, but
public for QML or v.v. And sometimes you have "see also" references
inside of docs for a method t
>F.e I have a couple of C++ methods, that serve no other purpose than to
>make another C++ API accessible from QML. And the other way round I don't
>want to see the API, that is made for the C++ use case being visible in
>the QML docs - even if technically being invokable.
Use \internal in their q
On Mon, 24 Apr 2017 17:09:43 +, Martin Smith wrote:
> It doesn't need a separate comment, just something in the one common
> comment that indicates the class is both C++ and QML.
Most of the decisions about what parts of the APIs have to go to the QML
docs can indeed be made without any addi
Op 24/04/2017 om 20:39 schreef Marc Mutz:
> On 2017-04-24 20:19, Ville Voutilainen wrote:
> [...]
>> What is wrong with QArrayList?
>
> Nothing, IMO, in the version proposed by me:
> https://codereview.qt-project.org/188938
>
> But since there's been no +2 forthcoming on above change, and I will
On 2017-04-24 20:19, Ville Voutilainen wrote:
[...]
What is wrong with QArrayList?
Nothing, IMO, in the version proposed by me:
https://codereview.qt-project.org/188938
But since there's been no +2 forthcoming on above change, and I will
have no part in the massive code duplication that the
On 24 April 2017 at 21:15, Marc Mutz wrote:
> On 2017-04-06 09:20, Ville Voutilainen wrote:
> [...]
>>
>> Okay, I will do it. :)
>
> [...]
>
> Interested to see the result, as I'm considering abandoning the QArrayList
> changes.
I'll try to get it done before the end of the week. As far as the
f
On 2017-04-06 09:20, Ville Voutilainen wrote:
[...]
Okay, I will do it. :)
[...]
Interested to see the result, as I'm considering abandoning the
QArrayList changes.
Thanks,
Marc
___
Development mailing list
Development@qt-project.org
http://lists.
>Not sure if qdoc is intended to be useful for 3rd party libraries as
>well, but at least for my use case it would save me a lot of work.
It is meant to be useful for 3rd party libraries, so we just need to agree on
the right way to do this.
From: Developm
>Maybe qdoc could look for qmlRegisterType etc. in the cpp files and discover
>those relationships without writing anything else? It has a better parser
>these
>days, right?
It certainly does have a better parser, but for speed, we tell it not to parse
the code blocks. Only declarations and sig
On Mon, 24 Apr 2017 15:08:25 +, Shawn Rutledge wrote:
> I guess we haven’t run into this very frequently yet because so few
> classes have both a C++ and a QML API within the same class.
Well, this is exactly my use case. All my controls are 100% implemented
in C++ offering a full featured C
> On 24 Apr 2017, at 16:38, Martin Smith wrote:
>
> The problem when combining C++ and QML documentation is qdoc has no way of
> knowing whether a QML type exists for a C++ class or whether a C++ class
> exists for a QML type.
>
> Should we add a new command like \cpp-qml to indicate that bot
The problem when combining C++ and QML documentation is qdoc has no way of
knowing whether a QML type exists for a C++ class or whether a C++ class exists
for a QML type.
Should we add a new command like \cpp-qml to indicate that both exist and are
documented the same?
And if a C++ class has a
Robin Burchell (24 April 2017 16:01)
> I'd generally like to avoid a "Utils" import, since in my opinion they
> far too easily end up as a dumping ground
+1, also for anything with "misc" in its name.
Such names are a red flag about bad modularisation,
Eddy.
__
Hi,
On 24/04/2017 14:23, Martin Smith wrote:
Regarding documenting both C++ and QML at the same time, I will be happy to
implement it if we can get a good idea for how to do it.
Well, take https://codereview.qt-project.org/#/c/192093/ as a case in
point. The docs for the QML and C++ parts ar
On 24/04/2017 14:26, Friedemann Kleint wrote:
Hi,
For starters, take a look at the script:
http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/scripts/qdoc2tasks.pl?h=4.3
You can pipe the error output of qdoc through it to convert it to a Qt
Creator task file. Opening it in Qt Creator wil
On Mon, Apr 24, 2017, at 02:36 PM, J-P Nurmi wrote:
> QML Settings, being currently in the Qt.labs namespace, could graduate
> later there. And QStandardPaths could be a nice addition too.
Since these are all QtCore types thus far, what about a QtCore import?
The source tree would of course have t
Hi,
For starters, take a look at the script:
http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/scripts/qdoc2tasks.pl?h=4.3
You can pipe the error output of qdoc through it to convert it to a Qt
Creator task file. Opening it in Qt Creator will show the issues as
build issues (see http://do
Regarding documenting both C++ and QML at the same time, I will be happy to
implement it if we can get a good idea for how to do it.
Regarding the creator issue, I don't understand the problem so I can't comment.
martin
From: Development on
behalf of Se
Hi,
are there any plans to reduce/remove the redundancy when writing
documentation for both C++ and QML? Seems a waste of time to have to
copy/paste or update the docs twice for both languages when really the
only things differing are the "Q" prefix on the class names in C++.
On a related no
On Mon, 2017-04-24 at 15:25 +0300, Alberto Mardegan wrote:
> Hi all,
> in addition to making QMimeType usable from QML [1], jpnurmi also
> suggested of exposing QMimeDatabase as a singleton.
>
> The open question is where this element should be added: I suggested
> QtQtml.Models, given that it's
Hi all,
in addition to making QMimeType usable from QML [1], jpnurmi also
suggested of exposing QMimeDatabase as a singleton.
The open question is where this element should be added: I suggested
QtQtml.Models, given that it's a database, but maybe creating a separate
module QtQml.Utils might be
> On Apr 24, 2017, at 13:45, Martin Koller wrote:
>
> On Freitag, 21. April 2017 09:08:00 CEST Jani Heikkinen wrote:
>> Hi all,
>>
>> Qt 5.9 beta2 is now available. Instructions how to get the release are here:
>> https://wiki.qt.io/How_to_get_snapshot_via_online_installer. Diff to first
>> b
On Freitag, 21. April 2017 09:08:00 CEST Jani Heikkinen wrote:
> Hi all,
>
> Qt 5.9 beta2 is now available. Instructions how to get the release are here:
> https://wiki.qt.io/How_to_get_snapshot_via_online_installer. Diff to first
> beta can be found as an attachment.
>
> Please test the releas
27 matches
Mail list logo