Thanks, Kevin.
Do you know how doxygen finds those links? Does it use the qdoc index files, or
does it construct an index from all the Qt html files?
martin
From: development-bounces+martin.smith=theqtcompany@qt-project.org
on behalf of
Kevin Kofle
On Tuesday 21 October 2014 22:04:34 Gunnar Roth wrote:
> Hello ,
> does anybody know why QQuickRectangle and QQuickPen is not exported with
> Q_QUICK_PRIVATE_EXPORT, but only with Q_AUTOTEST_EXPORT. As
> QQuickGradientStop and QQuickGradient is exported with
> Q_QUICK_PRIVATE_EXPORT, i really wonde
On Tuesday 21 October 2014 11:34:54 Thiago Macieira wrote:
[snip]
> FYI, we have a similar problem in Tizen 3.0, compounded by the fact that
> we're using Wayland.
>
> But Tomasz says that the qtmultimedia branch for GStreamer 1.0 is working
> fine. We've got that branch rebased on qtmultimedia d
Smith Martin wrote:
> If you want your documentation to link to the Qt documentation, it might
> be easier to use qdoc. I'm not sure that's correct, because I haven't
> actually used doxygen for that purpose, but I know you can link to Qt
> documentation using qdoc.
Doxygen can definitely link to
Hello ,
does anybody know why QQuickRectangle and QQuickPen is not exported with
Q_QUICK_PRIVATE_EXPORT, but only with Q_AUTOTEST_EXPORT.
As QQuickGradientStop and QQuickGradient is exported with
Q_QUICK_PRIVATE_EXPORT, i really wonder why its not the case for these two
classes in qquickrectang
Just want to humbly remind that we still need to get rid of .prl files from Qt
module frameworks roots. Either move the one level up or into Resources/
--Adam
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/li
> For now, I'll create that bug report for you.
For reference: https://bugreports.qt-project.org/browse/QTBUG-42103
Joerg
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On 21-Oct-14 15:56, kl222 wrote:
[...]
> Test program in the Annex.
I can reproduce this issue on Windows.
For the next bug you find, please report it at
http://bugreports.qt-project.org/ and ideally follow the guideline on
http://qt-project.org/wiki/ReportingBugsInQt
For now, I'll create that
Hi,
https://bugreports.qt-project.org/browse/QTBUG-40881 might be related?
Regards,
Friedemann
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On Tuesday, October 21, 2014 8:19 AM Simon Hausmann wrote:
> The QTime is literally the result of string copy&paste from the token in the
> header file into the moc generated C++ code.
> There's no type lookup, resolution or analysis involved :)
But that's the point, isn't it? The type itself n
Crystal clear!
Thanks all for the useful information and the kindness.
Cheers,
F.
On 21 October 2014 12:48, Thiago Macieira wrote:
> On Tuesday 21 October 2014 10:22:48 Federico Buti wrote:
> > So, in short, which is the current state of the affairs? It is
> > possible/advisable to use qdoc or
On Monday, October 20, 2014 7:49 AM Branislav Katreniak wrote:
> What about removing the hard dependency of type safe replicas on the rep
> language and rep compiler? Can we extend moc compiler?
In theory, yes.
> When we write the server objects, we already have the QObject with all the
> sig
On Tuesday 21. October 2014 12.14.35 Stottlemyer, Brett wrote:
> On Monday, October 20, 2014 6:45 AM Simon Hausmann wrote:
> >> I wasn't trying to suggest using protocol buffers as a wholesale
> >> replacement for MOC generated code. I was thinking only of the piece
> >> for marshalling Properties
On Monday, October 20, 2014 6:45 AM Simon Hausmann wrote:
>> I wasn't trying to suggest using protocol buffers as a wholesale
>> replacement for MOC generated code. I was thinking only of the piece
>> for marshalling Properties and Signal arguments for QueuedConnection
>> calls, and the return
On Tuesday 21 October 2014 10:22:48 Federico Buti wrote:
> So, in short, which is the current state of the affairs? It is
> possible/advisable to use qdoc or not? Is there a read me like the above in
> Qt 5.x?
qdoc is developed in lockstep with Qt's own needs. If it fullfils your needs,
great. Bu
?You can use either doxygen or qdoc, but the two have different command sets,
so they aren's interchangeable.
If you want your documentation to link to the Qt documentation, it might be
easier to use qdoc. I'm not sure that's correct, because I haven't actually
used doxygen for that purpose, b
Thanks for the fast response! I'm going to have a look to the
documentation.
Just to be totally sure: your answer implies that, as an external user of
Qt (not a developer), it is now advisable to switch from Doxygen to qdoc,
right? Or using qdoc is only suggested for Qt APIs?
Thanks again,
F.
--
Hi all,
And sorry for spamming...
Idea was to inform that 5.4 string freeze is coming... According to updated
plan (http://qt-project.org/wiki/Qt-5.4-release) string freeze will happen 31st
October so it is time to start keeping the translatable strings as it is and
fix remaining important iss
Hi,
qdoc3 is renamed as qdoc since Qt 5.0. You should find all the details you need
about qdoc on http://doc-snapshot.qt-project.org/qdoc/qdoc-index.html. Find us
on the #qt-documentation channel on freenode if you have any questions.
Venu
___
Develop
From: Heikkinen Jani
Sent: 3. huhtikuuta 2014 9:52
To: localizat...@qt-project.org
Subject: Heads up - 5.3 soft string freeze
Hi all,
Qt5.3 beta is out and work towards RC continues. Part of this is declaring a
string freeze for the modules that are part of the release. According to
updated p
Hi all.
in the git repository of Qt4.8 it is possible to read
1. qdoc3 is the tool used to generate the Qt reference documentation.
2. The source code is included as part of this package primarily to
3. fulfill our GPL obligations. We highly recommend using
4. Doxygen (http://www.stac
21 matches
Mail list logo
