[Development] Cannot click flash setting dialog with QtWebkit on Mac and Qt 5 window version
Hi Qt team, Could you please check https://bugreports.qt-project.org/browse/QTBUG-30766? It happens to both Windows and Mac. To produce the issue, you just need to make sure that you have camera and open http://testmycam.com/ with fancybrowser or qttestbrowser. Thanks, Bobber ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
On 04/22/2013 05:11 PM, Thiago Macieira wrote: And where is it documented for winrt? why should it be? Because people need to know what to expect if they are going to participate. Just in case somebody is interested: We are rebasing the 4.8-bb10 branch as well. I don't think this is an issue in practice, because not many people are using it and the ones who do know that already I would assume... Peter - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
On Mon, Apr 22, 2013 at 10:19:05AM -0700, Thiago Macieira wrote: On segunda-feira, 22 de abril de 2013 17.44.41, Oswald Buddenhagen wrote: On Mon, Apr 22, 2013 at 08:11:22AM -0700, Thiago Macieira wrote: On segunda-feira, 22 de abril de 2013 16.59.27, Oswald Buddenhagen wrote: And where is it documented for winrt? why should it be? Because people need to know what to expect if they are going to participate. while not entirely invalid, i don't think this is of particular concern. somebody who joins the work on a project is supposed to be talking to the respective people. Not necessarily. They may have simply found out about the branch due to our public posts and blogs, so they're just looking around. Hypothetically, there are also people maybe working for companies who cannot yet disclose their interest on WinRT. sure These people need to be warned that the branch rebases. why would they? they can adapt once it happens. i mean, it's a bit of a surprise, but it doesn't change much in the end. Ok, then add rebasing to the branch name somewhere. Preferably: wip/rebasing/xxx sounds over-engineered to me. and unnecessarily restrictive, as the policy may change ad-hoc as things progress. Change the branch name when the policy changes. i really wouldn't want to do that. i don't think we should put any more energy into discussing this matter. the only action point is documenting on the wiki that wip/ branches (winrt should have had that prefix, obviously) may be subject to history rewriting. The wip prefix does help to identify that the branch is not ready and could be unstable. If most wip branches rebase, then we can declare that the entire wip/ prefix is subject to rebasing. If there's just one, I'd rather have it clearly marked. i'd say it's perfectly mixed, so just wip/ is not a sufficient discriminator. and i really don't think we need one, because i don't see it as a practical problem. In any case, why does this branch rebase? Can't they live with merges? well, the wip/ branches often have rather lax review policies (often bypassing domain experts in the case of platform ports) and no CI. this results in a messy history (and sometimes bug fixes that actually need to be applied to more stable branches to start with). therefore i'm advocating history reshaping and early mainline submission of generic fixes (which of course means rebasing in turn). it worked really well for ios, sort of well for android (they went for a squash merge instead of rebasing, which kind of made sense given the history of the import), and appears to be going just fine for winrt. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] 6 conflicting symbols between QtQuick 1 and 2
Hi! Don't ask why but we ran into the known[1] segfault caused by symbol name conflicts between Qt5Qml and Qt5Declarative. Checking the symbol tables it appears to because by 6 symbols only: qmlContext(QObject const*) qmlExecuteDeferred(QObject*) qmlAttachedPropertiesObject(int*, QObject const*, QMetaObject const*, bool) qmlAttachedPropertiesObjectById(int, QObject const*, bool) qmlInfo(QObject const*) qmlEngine(QObject const*) At least for non-VS compilers the partially different return types (QQml* vs. QDeclarative*) don't help with having a different symbol name mangling. At the same time the functions cannot be used interchangeably either. So I assume that this conflict was a simply copypaste oversight during the porting. I have not checked the respective use cases of the functions but I guess that they are internal to Qt despite being exported? Anyone sees a problem with renaming the functions of v1 or v2 to make their names unique? If not, we'll prepare a patch and present it. To stress one point: we are not attempting to run both types of GUIs in a single application. We'd just like to have the possibility to have the two libraries co-exist and optionially be used. Harri. [1] https://bugreports.qt-project.org/browse/QTBUG-29584 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 6 conflicting symbols between QtQuick 1 and 2
Hi Harri, having the symbols clash is not a good idea in any case, so please go ahead and rename one set. I'd go for changing the ones in Qt Quick 1. Cheers, Lars On 4/23/13 1:04 PM, Harri Porten por...@froglogic.com wrote: Hi! Don't ask why but we ran into the known[1] segfault caused by symbol name conflicts between Qt5Qml and Qt5Declarative. Checking the symbol tables it appears to because by 6 symbols only: qmlContext(QObject const*) qmlExecuteDeferred(QObject*) qmlAttachedPropertiesObject(int*, QObject const*, QMetaObject const*, bool) qmlAttachedPropertiesObjectById(int, QObject const*, bool) qmlInfo(QObject const*) qmlEngine(QObject const*) At least for non-VS compilers the partially different return types (QQml* vs. QDeclarative*) don't help with having a different symbol name mangling. At the same time the functions cannot be used interchangeably either. So I assume that this conflict was a simply copypaste oversight during the porting. I have not checked the respective use cases of the functions but I guess that they are internal to Qt despite being exported? Anyone sees a problem with renaming the functions of v1 or v2 to make their names unique? If not, we'll prepare a patch and present it. To stress one point: we are not attempting to run both types of GUIs in a single application. We'd just like to have the possibility to have the two libraries co-exist and optionially be used. Harri. [1] https://bugreports.qt-project.org/browse/QTBUG-29584 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
On terça-feira, 23 de abril de 2013 11.18.33, Oswald Buddenhagen wrote: On Mon, Apr 22, 2013 at 10:19:05AM -0700, Thiago Macieira wrote: Not necessarily. They may have simply found out about the branch due to our public posts and blogs, so they're just looking around. Hypothetically, there are also people maybe working for companies who cannot yet disclose their interest on WinRT. sure These people need to be warned that the branch rebases. why would they? they can adapt once it happens. i mean, it's a bit of a surprise, but it doesn't change much in the end. Because the surprise is quite big. If you do a git pull --rebase or git pull, it might blow up after dozens lines have scrolled out. People don't pay attention to the output of the fetch part. Though I have to grant that novice users are unlikely to be following those branches in the first place. But then, we're left with somewhat knowledgeable users following the branches, so they are more likely to have extra commits and then have no clue on how to rebase their work on top of the rebased base. I, for one, will not touch any of the rebasing branches, not even to test them. It's too much work to rebase on top of a moving base. Ok, then add rebasing to the branch name somewhere. Preferably: wip/rebasing/xxx sounds over-engineered to me. and unnecessarily restrictive, as the policy may change ad-hoc as things progress. Change the branch name when the policy changes. i really wouldn't want to do that. But you're not offering a better solution either. You're just dismissing the problem completely: i'd say it's perfectly mixed, so just wip/ is not a sufficient discriminator. and i really don't think we need one, because i don't see it as a practical problem. I'm sorry, just because it is not a problem for you and for the handful of developers working on that branch, it does not mean it's not a problem for anyone. And maybe it isn't the case for the winrt branch, but who knows what other branches we may have in the future. Sorry, I want it to be a policy that either: a) branches do not rebase (no force pushes allowed, period) or b) branches that do rebase have rebasing in their names I'd much rather it be option (a). In any case, why does this branch rebase? Can't they live with merges? well, the wip/ branches often have rather lax review policies (often bypassing domain experts in the case of platform ports) and no CI. this results in a messy history (and sometimes bug fixes that actually need to be applied to more stable branches to start with). therefore i'm advocating history reshaping and early mainline submission of generic fixes (which of course means rebasing in turn). it worked really well for ios, sort of well for android (they went for a squash merge instead of rebasing, which kind of made sense given the history of the import), and appears to be going just fine for winrt. If they're bypassing the reviewers and bypassing the CI, why do they need to be in the main Git repositories in Gerrit in the first place? Especially if they're bypassing the CI, they could and should just use a repository elsewhere. When the branch is ready, it will be submitted as individual patches to be reviewed by the regular reviewers, maybe starting the work branch. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Bootstrapping QDoc
Hello, Not too long ago, I was able to compile Qt's HTML documentation by simply running 'configure' followed by 'make html_docs'. It was really easy and really fast, as I didn't have to build an entire git repo first. That's not the case anymore -- calling 'make html_docs' after 'configure' led to an attempt to run qdoc.exe, which did not yet exist. I'm guessing it's because QDoc is no longer bootstrapped (https://codereview.qt-project.org/#change,52739). The patch mentioned making bootstrapping optional -- does that mean I can re-enable it? If so, how? Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 6 conflicting symbols between QtQuick 1 and 2
On terça-feira, 23 de abril de 2013 13.04.22, Harri Porten wrote: I have not checked the respective use cases of the functions but I guess that they are internal to Qt despite being exported? Anyone sees a problem with renaming the functions of v1 or v2 to make their names unique? If not, we'll prepare a patch and present it. All of those functions are declared in public headers. qmlAttachedPropertiesObject is documented in QtQml: http://qt-project.org/doc/qt-5.0/qtqml/qqmlengine.html#qmlAttachedPropertiesObject and it's used in QtQuick1 documentation: http://qt-project.org/doc/qt-4.8/qml-extending.html#attached-properties (the documentation for QtQuick1 5.0 is not online) qmlContext and qmlEngine are not documented but they are used in QtQml documentation: http://qt-project.org/doc/qt-5.0/qtqml/qqmlengine.html#qmlRegisterSingletonType-2 Also add to your list: qmlRegisterTypeNotAvailable (it's AUTOTEST_EXPORT in QtQuick1) To make matters worse, the following *documented* functions are duplicated: qmlRegisterRevision qmlRegisterInterface qmlRegisterType qmlRegisterUncreatableType And the following are also duplicated, but not documented: qmlRegisterCustomType qmlRegisterExtendedType They are inline and non-exported, so the impact is minimised. On all modern platforms, the use of those functions inside one Qt library will not affect other libraries, even though it's a violation of the C++ standard. However, it does make it impossible to use both QtQuick1 and QtQml inside the same library or application, or to use two third-party or user libraries, one for each QML iteration. The only way to use both QML1 and QML2 in one application or library is to use a plugin and make the decision application- wide (you can't load the two plugins at the same time). I'm going to wait for other people to suggest solutions to this. Mine, for the moment, is a hammer... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bootstrapping QDoc
On terça-feira, 23 de abril de 2013 23.30.42, Sze Howe Koh wrote: That's not the case anymore -- calling 'make html_docs' after 'configure' led to an attempt to run qdoc.exe, which did not yet exist. I'm guessing it's because QDoc is no longer bootstrapped (https://codereview.qt-project.org/#change,52739). The patch mentioned making bootstrapping optional -- does that mean I can re-enable it? If so, how? It's bootstrapped only if you're cross-compiling. That's how it's optional: it's an option made by the build. If you're not cross-compiling, you don't need a bootstrapped qdoc or qdbusxml2cpp. Therefore, simply build it normally. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bootstrapping QDoc
On Tue, Apr 23, 2013 at 11:30:42PM +0800, Sze Howe Koh wrote: Not too long ago, I was able to compile Qt's HTML documentation by simply running 'configure' followed by 'make html_docs'. i find that hard to believe, because configure never built qdoc. That's not the case anymore -- calling 'make html_docs' after 'configure' led to an attempt to run qdoc.exe, which did not yet exist. I'm guessing it's because QDoc is no longer bootstrapped (https://codereview.qt-project.org/#change,52739). The patch mentioned making bootstrapping optional -- does that mean I can re-enable it? If so, how? you can run ../bin/qmake -r -config force_bootstrap in qtbase/src/ after configuring. but that still needs to be followed by make sub-qdoc. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bootstrapping QDoc
On terça-feira, 23 de abril de 2013 18.09.58, Oswald Buddenhagen wrote: Not too long ago, I was able to compile Qt's HTML documentation by simply running 'configure' followed by 'make html_docs'. i find that hard to believe, because configure never built qdoc. It wasn't configure. doc/doc.pri had: adp_docs.depends += sub-qdoc3 # qdoc3 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bootstrapping QDoc
On Tue, Apr 23, 2013 at 09:12:39AM -0700, Thiago Macieira wrote: On terça-feira, 23 de abril de 2013 18.09.58, Oswald Buddenhagen wrote: Not too long ago, I was able to compile Qt's HTML documentation by simply running 'configure' followed by 'make html_docs'. i find that hard to believe, because configure never built qdoc. It wasn't configure. doc/doc.pri had: adp_docs.depends += sub-qdoc3 # qdoc3 right. that can't work any more due to the doc build being much more complex now. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
On terça-feira, 23 de abril de 2013 18.20.11, Oswald Buddenhagen wrote:
I, for one, will not touch any of the rebasing branches, not even to test
them. It's too much work to rebase on top of a moving base.
i call that making a mountain out of a molehill.
$ git fetch
$ git rebase --onto @{u} HEAD~4
Would you call me experienced with Git?
Well, I have never successfully used git rebase --onto without reading the man
page first and paying attention to the ASCII Art graphs.
Besides, that's unwieldy. I don't carry a handful of commits in my branches. I
carry somewhere from 60 to 120. So, no, moving target == off-limits for me.
Change the branch name when the policy changes.
i really wouldn't want to do that.
But you're not offering a better solution either. You're just dismissing
the
problem completely:
indeed, my solution is dismissing this NON-problem.
Thank you for your opinion. Since I'm entitled to mine, we have an impasse.
Especially if they're bypassing the CI, they could and should just use
a repository elsewhere. When the branch is ready, it will be submitted
as individual patches to be reviewed by the regular reviewers, maybe
starting the work branch.
it's unreasonable to ban everything that does not comply with the
standard workflow for mainline branches.
Yes, it is. Why do they need to use the mainline repositories if they are not
going to adhere to the policies that are in place?
No, really, why do those branches need to be in the main repositories?
I'll give one answer, out of past discussion, and just to prove that yes I am
trying to understand both sides:
it is nice to be there because other people sometimes see the commits coming
in and will comment on them.
With that in mind, I change my proposal and I will say that rebasing branches
are acceptable in the mainline repositories, provided they are clearly marked.
It's minimal impact and it solves the problem of surprise by selecting the
people who may use that branch.
and if you did, you'd need to ban playground repos as well (where
typically non-approvers can approve changes).
By definition, a playground repository is not a mainline repository.
We no longer mark the repository by giving it a different path, so they now can
be confused and someone might think that they are official and mainline. But to
be honest, granting extra privileges to some people is less of a problem than
rebasing.
Besides, the fact that we made it worse in one aspect is not a justification
for accepting it elsewhere too.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
On Tue, Apr 23, 2013 at 09:46:03AM -0700, Thiago Macieira wrote:
On terça-feira, 23 de abril de 2013 18.20.11, Oswald Buddenhagen wrote:
I, for one, will not touch any of the rebasing branches, not even to test
them. It's too much work to rebase on top of a moving base.
i call that making a mountain out of a molehill.
$ git fetch
$ git rebase --onto @{u} HEAD~4
Would you call me experienced with Git?
Well, I have never successfully used git rebase --onto without reading the
man
page first and paying attention to the ASCII Art graphs.
that's unfortunate. :P
Besides, that's unwieldy. I don't carry a handful of commits in my branches.
I
carry somewhere from 60 to 120. So, no, moving target == off-limits for me.
this is an entirely constructed example. you are not going to have 100
changes on top of a wip branch which is too quickly moving to adhere to
the mainline submission policies.
and, ehm, you are the only person within qt-project who has 100 pending
changes in a single branch. seriously.
Especially if they're bypassing the CI, they could and should just use
a repository elsewhere. When the branch is ready, it will be submitted
as individual patches to be reviewed by the regular reviewers, maybe
starting the work branch.
it's unreasonable to ban everything that does not comply with the
standard workflow for mainline branches.
Yes, it is. Why do they need to use the mainline repositories if they are not
going to adhere to the policies that are in place?
No, really, why do those branches need to be in the main repositories?
I'll give one answer, out of past discussion, and just to prove that yes I am
trying to understand both sides:
it is nice to be there because other people sometimes see the commits coming
in and will comment on them.
With that in mind, I change my proposal and I will say that rebasing branches
are acceptable in the mainline repositories, provided they are clearly
marked.
It's minimal impact and it solves the problem of surprise by selecting the
people who may use that branch.
as far as i can see, the admin who created the winrt branch (not me)
failed to comply with the wip/ policy. i'm sure adding more naming
policies will improve that situation ... not.
and if you did, you'd need to ban playground repos as well (where
typically non-approvers can approve changes).
By definition, a playground repository is not a mainline repository.
but it lives on our gerrit, so it's official.
i don't see a difference between a non-mainline branch of an accepted
repository and the branches of a playground repository. there is no such
thing as a mainline _repository_ - on the server, we don't clone: we
branch.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 6 conflicting symbols between QtQuick 1 and 2
On Tuesday 23 April 2013 08:48:41 Thiago Macieira wrote: I'm going to wait for other people to suggest solutions to this. Mine, for the moment, is a hammer... My suggested solution: In the header: Put those functions in an inline namespace. (Or a normal namespace followed by an using declaration). In one translation unit, keep an exported version of the old symbols which calls the new symbol in the namespace, to keep binary compatibility. That way, the problem is solved if the application is compiled against Qt 5.1 or later. If the application or one linked library is compiled against QtQml or QtDeclarative from 5.0, and that this library uses one of the problematic symbol, the crash can still happen. So one must still not link both QtQml, QtDeclarative, and an old library together. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
Hi guys,
don't want to stop your discussion, but personally I see that mainly as a
documentation issue. Surely having some convention about branch names (and
sticking to it) would help, but even better would be to put the details about
the branches on something that shows up very high in google qt git branches
:) Right now there's
http://qt-project.org/wiki/Branches
which is qt creator only. We should have the same for qt.git, or list both on
the page.
Regards
Kai
PS: Yet another example: http://gcc.gnu.org/svn.html, where all the gcc
branches are described.
From: development-bounces+kai.koehne=digia@qt-project.org
[development-bounces+kai.koehne=digia@qt-project.org] on behalf of Oswald
Buddenhagen [oswald.buddenha...@digia.com]
Sent: 23 April 2013 19:11
To: development@qt-project.org
Subject: Re: [Development] Please warn of force pushes...
On Tue, Apr 23, 2013 at 09:46:03AM -0700, Thiago Macieira wrote:
On terça-feira, 23 de abril de 2013 18.20.11, Oswald Buddenhagen wrote:
I, for one, will not touch any of the rebasing branches, not even to test
them. It's too much work to rebase on top of a moving base.
i call that making a mountain out of a molehill.
$ git fetch
$ git rebase --onto @{u} HEAD~4
Would you call me experienced with Git?
Well, I have never successfully used git rebase --onto without reading the man
page first and paying attention to the ASCII Art graphs.
that's unfortunate. :P
Besides, that's unwieldy. I don't carry a handful of commits in my branches. I
carry somewhere from 60 to 120. So, no, moving target == off-limits for me.
this is an entirely constructed example. you are not going to have 100
changes on top of a wip branch which is too quickly moving to adhere to
the mainline submission policies.
and, ehm, you are the only person within qt-project who has 100 pending
changes in a single branch. seriously.
Especially if they're bypassing the CI, they could and should just use
a repository elsewhere. When the branch is ready, it will be submitted
as individual patches to be reviewed by the regular reviewers, maybe
starting the work branch.
it's unreasonable to ban everything that does not comply with the
standard workflow for mainline branches.
Yes, it is. Why do they need to use the mainline repositories if they are not
going to adhere to the policies that are in place?
No, really, why do those branches need to be in the main repositories?
I'll give one answer, out of past discussion, and just to prove that yes I am
trying to understand both sides:
it is nice to be there because other people sometimes see the commits coming
in and will comment on them.
With that in mind, I change my proposal and I will say that rebasing branches
are acceptable in the mainline repositories, provided they are clearly marked.
It's minimal impact and it solves the problem of surprise by selecting the
people who may use that branch.
as far as i can see, the admin who created the winrt branch (not me)
failed to comply with the wip/ policy. i'm sure adding more naming
policies will improve that situation ... not.
and if you did, you'd need to ban playground repos as well (where
typically non-approvers can approve changes).
By definition, a playground repository is not a mainline repository.
but it lives on our gerrit, so it's official.
i don't see a difference between a non-mainline branch of an accepted
repository and the branches of a playground repository. there is no such
thing as a mainline _repository_ - on the server, we don't clone: we
branch.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 6 conflicting symbols between QtQuick 1 and 2
On terça-feira, 23 de abril de 2013 19.47.25, Olivier Goffart wrote: On Tuesday 23 April 2013 08:48:41 Thiago Macieira wrote: I'm going to wait for other people to suggest solutions to this. Mine, for the moment, is a hammer... My suggested solution: In the header: Put those functions in an inline namespace. (Or a normal namespace followed by an using declaration). Thank you! That's why I wanted someone to provide a solution. Yours is definitely much simpler and helpful than what I had in mind. In one translation unit, keep an exported version of the old symbols which calls the new symbol in the namespace, to keep binary compatibility. Right, that falls under the de-inlining a function category of binary compatibility. We keep the source compatibility by using an inline namespace. It's highly unlikely that anyone will #include both modules in the same translation unit. That way, the problem is solved if the application is compiled against Qt 5.1 or later. If the application or one linked library is compiled against QtQml or QtDeclarative from 5.0, and that this library uses one of the problematic symbol, the crash can still happen. So one must still not link both QtQml, QtDeclarative, and an old library together. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 6 conflicting symbols between QtQuick 1 and 2
On Tuesday, April 23, 2013 12:27:17 Thiago Macieira wrote: It's highly unlikely that anyone will #include both modules in the same translation unit. In the future, we're going to laugh at this :). -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiling with GCC 4.8
On segunda-feira, 8 de abril de 2013 00.43.16, David Narvaez wrote: (Note: this does not mean it was a bad idea to work around the bug) Thanks for the clarification, I reported the bug[0] - just fixed the section number to 7.1.5. Your sample code compiles fine in Clang, btw. [0] was missing. Can you give me the link? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 6 conflicting symbols between QtQuick 1 and 2
qmlEngine() and qmlContext() are documented via qdoc comments in qqmlengine.cpp and should show up in the related functions section of the generated documentation. As you've noticed, however, for some reason the documentation does not show up in the generated documentation. I don't know why. Perhaps Jerome knows. qmlInfo() should be documented also - if it isn't, we need to fix that. Anyway, I agree with Lars: the QtQuick1 ones could be renamed. I really don't think people should be using QtQuick1 and QtQuick2 in the same application, at all, but I guess that's a bit beside the point. This is definitely something we overlooked when doing the QtQuick1-in-Qt5 stuff. Cheers, Chris. On Wed, Apr 24, 2013 at 1:48 AM, Thiago Macieira thiago.macie...@intel.comwrote: On terça-feira, 23 de abril de 2013 13.04.22, Harri Porten wrote: I have not checked the respective use cases of the functions but I guess that they are internal to Qt despite being exported? Anyone sees a problem with renaming the functions of v1 or v2 to make their names unique? If not, we'll prepare a patch and present it. All of those functions are declared in public headers. qmlAttachedPropertiesObject is documented in QtQml: http://qt-project.org/doc/qt-5.0/qtqml/qqmlengine.html#qmlAttachedPropertiesObject and it's used in QtQuick1 documentation: http://qt-project.org/doc/qt-4.8/qml-extending.html#attached-properties (the documentation for QtQuick1 5.0 is not online) qmlContext and qmlEngine are not documented but they are used in QtQml documentation: http://qt-project.org/doc/qt-5.0/qtqml/qqmlengine.html#qmlRegisterSingletonType-2 Also add to your list: qmlRegisterTypeNotAvailable (it's AUTOTEST_EXPORT in QtQuick1) To make matters worse, the following *documented* functions are duplicated: qmlRegisterRevision qmlRegisterInterface qmlRegisterType qmlRegisterUncreatableType And the following are also duplicated, but not documented: qmlRegisterCustomType qmlRegisterExtendedType They are inline and non-exported, so the impact is minimised. On all modern platforms, the use of those functions inside one Qt library will not affect other libraries, even though it's a violation of the C++ standard. However, it does make it impossible to use both QtQuick1 and QtQml inside the same library or application, or to use two third-party or user libraries, one for each QML iteration. The only way to use both QML1 and QML2 in one application or library is to use a plugin and make the decision application- wide (you can't load the two plugins at the same time). I'm going to wait for other people to suggest solutions to this. Mine, for the moment, is a hammer... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiling with GCC 4.8
On Tue, Apr 23, 2013 at 6:45 PM, Thiago Macieira thiago.macie...@intel.com wrote: [0] was missing. Can you give me the link? It was left as an exercise for the reader. David E. Narvaez [0] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56871 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
