Re: [Development] Request for new Playground Repo
We actually have got a few more APIs which we would move to that
repository either right now, or later when it becomes an add-on. Some of
those APIs need to go under a review to sort our what would be the place
to put them in.
For now, we are asking for a home to start with.
Cheers!
--
Vladimir
On 20.11.13 23:47, André Pönitz
andre.poen...@mathematik.tu-chemnitz.de wrote:
On Wed, Nov 20, 2013 at 07:51:34PM +, Knoll Lars wrote:
On 20/11/13 20:36, Andrew Wooster awoos...@blackberry.com wrote:
Hi, I'd like to request the creation of a new playground repository.
Name: BlackBerry Extras
Description: A repository for creating BlackBerry specific APIs that
are
useful for implementing Qt functionality.
Let me know if there are any questions.
If the purpose is the same as the other QPlatformExtras modules, I¹m
happy
to add it.
I am not.
The general approach is wrong, for several reasons:
1. Splitting the platform extras already on the module level means that
everybody who wants to use some of the extras even buried behind #ifdef's
somewhere deep in his code has to add platform specific conditional code
like
!isEmpty(QT.x11extras.name) {
QT += x11extras
DEFINES += I_CAN_USE_X11EXTRAS
} else {
warning(x11extras module not found, )
}
to his buildsystem(s), for each of the platforms he want to fully
support. This is a maintanance burden not just for the buildsystem itself
but also extends to conditional packaging/installation.
2. The setup is inherently fragile as only part of the code is used, and
part
not even checked on a specific developer's machine at a time, bearing the
risk of the classic compile fix or CI ping pong.
3. The approach does not scale as it does not offer a natural place for
features that are not available on all platforms, but on more then one.
Putting random sort-of-sharable code into qtbase is not a good alternative
either.
There is no perfect solution, but the further down the conditionals
are in the code the less impact they have on all three aspects, and
the more code can be shared between the backends.
Merging the platform into a single module with fat #ifdefs QT_OS_XYZ
in the headers would already alleviate the problem on the build system
level, and upwards (packaging...), while providing the same interface
to the actual code. That'd be a uniform improvemnt over the current setup.
Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-
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] Request for new Playground Repo
On Wednesday, 2013-11-20, 19:36:00, Andrew Wooster wrote: Hi, I'd like to request the creation of a new playground repository. Name: BlackBerry Extras Description: A repository for creating BlackBerry specific APIs that are useful for implementing Qt functionality. Let me know if there are any questions. Since I saw PPS being mentioned as one of the extra APIs, isn't that also available on stock QNX? I.e. would it make sense to follow the naming used for the QPA or is the plan to mostly add BB specific APIs? Cheers, Kevin -- Kevin Krammer | kevin.kram...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Topi Reiniö (topi.rei...@digia.com) as approver
Hi again, It has been more than 15 days. We have +1's and no objections. Please update Topi to have Approver rights. martin From: Smith Martin Sent: Tuesday, October 22, 2013 11:53 AM To: development@qt-project.org Subject: Nominating Topi Reiniö (topi.rei...@digia.com) as approver I nominate Topi as an approver. Topi has been the leader of the Qt documentation team in Oslo for a long time. A search for topi.rei...@digia.com at codereview.qt-project.org shows that Topi has been very active both submitting patches and reviewing patches for the Qt documentation and for the qdoc tool. Seconds? Martin Smith ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Request for new Playground Repo
Hi, so unless this is going to be a huge beast, maybe qtbase would be actually a better target? I agree that it would be much better to have it in QtBase, if this is possible. Above all, because certain parts there use PPS (e.g. QPA and Locale). And it is not a huge beast (see https://qt.gitorious.org/qt/qtlocation/source/469cbf8f601270ac0b030202ae303939ba4c63ff:src/plugins/position/blackberry/bb) Fabian From: development-bounces+fbumberger=blackberry@qt-project.org [development-bounces+fbumberger=blackberry@qt-project.org] on behalf of Kevin Krammer [kevin.kram...@kdab.com] Sent: Thursday, November 21, 2013 10:03 AM To: development@qt-project.org Subject: Re: [Development] Request for new Playground Repo On Wednesday, 2013-11-20, 19:36:00, Andrew Wooster wrote: Hi, I'd like to request the creation of a new playground repository. Name: BlackBerry Extras Description: A repository for creating BlackBerry specific APIs that are useful for implementing Qt functionality. Let me know if there are any questions. Since I saw PPS being mentioned as one of the extra APIs, isn't that also available on stock QNX? I.e. would it make sense to follow the naming used for the QPA or is the plan to mostly add BB specific APIs? Cheers, Kevin -- Kevin Krammer | kevin.kram...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions - 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] StereoViewport for Qt3D
On to. 21. nov. 2013 kl. 09.40 +0100, Fabian Bumberger wrote: while working on this, the temporary frame buffer used for picking had a size set to 8x8 pixels(!). For picking the whole scene is rendered using the pick painter for every performed pick. And afaik, if you swich on picking then a pick is performed for every mouse event (including mouse move events). So I guess having such a small FBO was because of performance and memory reasons. But I also noticed that picking is quite unreliable with that. I think you are absolutely right - the new implementation will be a performance hit, but it is reliable. The previous implementation appears to render only a smaller part of the viewport for picking (around the mouse cursor). It might be that a bug in this implementation was causing it to be unreliable? In any case, the previous implementation was more complicated, making it harder to maintain and harder to build upon for stereoscopic viewing, in my opinion. What I could do to yield better performance is to reuse the picking buffer from last time if it the scene has not changed. That way the same scene should be painted only twice - once for the view and once for the picking buffer. This is what is done in QGLView. Svenn-Arne ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Topi Reiniö (topi.rei...@digia.com) as approver
On 11/21/2013 10:05 AM, Smith Martin wrote: Hi again, It has been more than 15 days. We have +1's and no objections. Please update Topi to have Approver rights. martin Hi, Added him to the Approvers group. Congratulations ! I guess Alex could fix the access rights in JIRA again. Cheers, -- Sergio Ahumada Release Engineer - Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Qt-creator] Nominating Nikolai Kosjar for Maintainer
On Tue, Nov 19, 2013 at 3:37 PM, Erik Verbruggen erik.verbrug...@digia.comwrote: Hello everyone, I would like to nominate Nikolai Kosjar for Maintainer of the C/C++ support in Qt Creator. He has been doing work on it for quite some time, and handling most maintainer tasks for most of this year. So I think we should make it official. Definitely +1 :) When Leandro and ckamm left, I was quite worried about C++ support in Creator. Nikolai filled this space with his extraordinary skills, deep knowledge of the code and his great ability to cover corner-cases. - Orgad ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Qt-creator] Nominating Nikolai Kosjar for Maintainer
+1 On Tue, Nov 19, 2013 at 2:37 PM, Erik Verbruggen erik.verbrug...@digia.comwrote: Hello everyone, I would like to nominate Nikolai Kosjar for Maintainer of the C/C++ support in Qt Creator. He has been doing work on it for quite some time, and handling most maintainer tasks for most of this year. So I think we should make it official. Cheers, Erik. ___ Qt-creator mailing list qt-crea...@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator -- Best regards/Pozdrawiam Przemyslaw Gorszkowski ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] StereoViewport for Qt3D
On to. 21. nov. 2013 kl. 10.17 +0100, Svenn-Arne Dragly wrote: What I could do to yield better performance is to reuse the picking buffer from last time if it the scene has not changed. That way the same scene should be painted only twice - once for the view and once for the picking buffer. This is what is done in QGLView. I take that back. There's a bit of logic in Viewport that calls the render() method on each mouse move already, likely because picking could initiate something that would require a re-rendering of the scene (for instance if the user changes an object's color on an hover event). I think I'll just leave it as is for now, even though there is a performance impact this way. Svenn-Arne ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Request for new Playground Repo
Let's realize that there are probably 2 separate categories of code worth talking about, and then also some overlap: A - common code for internal implementation ie a PpsObject class would be used to implement many standard Qt APIs on the BB/QNX platform B - useful code _for enduser developers_ that is only on one (or maybe 2) platform(s) ie maybe Android Intent classes (or BlackBerry Invoke) if a reasonable cross-platform common API can't be found Code like this is useful to get developers to use Qt - you don't want someone to say I'd use Qt except it doesn't give me access to special X on platform Y A+B - code that falls into both categories PpsObject might fall into this category - it is useful for internal implementation, but also useful for QNX-specific parts of a mostly cross-platform app. I'd like locations for both A and B. I suspect different locations. And the A+B stuff is probably A stuff wrapped by classes in B. -Original Message- From: development-bounces+tvaneerd=rim@qt-project.org [mailto:development-bounces+tvaneerd=rim@qt-project.org] On Behalf Of Fabian Bumberger Sent: Thursday, November 21, 2013 4:16 AM To: development@qt-project.org; oswald.buddenha...@digia.com Subject: Re: [Development] Request for new Playground Repo Hi, so unless this is going to be a huge beast, maybe qtbase would be actually a better target? I agree that it would be much better to have it in QtBase, if this is possible. Above all, because certain parts there use PPS (e.g. QPA and Locale). And it is not a huge beast (see https://qt.gitorious.org/qt/qtlocation/source/469cbf8f601270ac0b030202a e303939ba4c63ff:src/plugins/position/blackberry/bb) Fabian From: development-bounces+fbumberger=blackberry@qt-project.org [development-bounces+fbumberger=blackberry@qt-project.org] on behalf of Kevin Krammer [kevin.kram...@kdab.com] Sent: Thursday, November 21, 2013 10:03 AM To: development@qt-project.org Subject: Re: [Development] Request for new Playground Repo On Wednesday, 2013-11-20, 19:36:00, Andrew Wooster wrote: Hi, I'd like to request the creation of a new playground repository. Name: BlackBerry Extras Description: A repository for creating BlackBerry specific APIs that are useful for implementing Qt functionality. Let me know if there are any questions. Since I saw PPS being mentioned as one of the extra APIs, isn't that also available on stock QNX? I.e. would it make sense to follow the naming used for the QPA or is the plan to mostly add BB specific APIs? Cheers, Kevin -- Kevin Krammer | kevin.kram...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions - 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 - 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] Request for new Playground Repo
On 21.11.13 10:03, Kevin Krammer kevin.kram...@kdab.com wrote: On Wednesday, 2013-11-20, 19:36:00, Andrew Wooster wrote: Hi, I'd like to request the creation of a new playground repository. Name: BlackBerry Extras Description: A repository for creating BlackBerry specific APIs that are useful for implementing Qt functionality. Let me know if there are any questions. Since I saw PPS being mentioned as one of the extra APIs, isn't that also available on stock QNX? Yes, it is. We can target to make a new API for PPS which would unify advantages of all current implementations and approaches. Still the fact remains that a few things work on bare QNX in a different way than on BB10 because the latter is a complete application platform and the former is just a pure OS. I.e. would it make sense to follow the naming used for the QPA or is the plan to mostly add BB specific APIs? Does this mean considering QNX are a core platform and BB10 sitting on top of it? This sounds sensible. -- vm - 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] Nominating Fabian Bumberger for Approver Status
+1 disclaimer: I also work for BlackBerry. Peter On 11/19/2013 11:41 AM, Blasche Alexander wrote: Hello everybody, I'd like to nominate Fabian Bumberger for approver status in the Qt Project. Fabian has been contributing to QtNfc, QtBluetooth, QtLocation and many more Blackberry specific topics such as the platform plug-ins. His track record can be found under: https://codereview.qt-project.org/#q,owner:fbumberger,n,z https://codereview.qt-project.org/#q,reviewer:fbumberger,n,z From my perspective QtBluetooth and QtNfc wouldn't be the same without his help. I am convinced he will make en excellent approver. With regards, -- Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development - 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] Request for new Playground Repo
On 11/20/2013 10:20 PM, Oswald Buddenhagen wrote: so unless this is going to be a huge beast, maybe qtbase would be actually a better target? Even better if we could get the PPS parsing code directly into qtbase. As already posted, that comprises only a few files. Is everybody fine with that? We might need a blackberry extras repo for other things later though... 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
