Re: [Development] Views
I doubt adding one if condition to QMap insert and remove methods would be noticeable. I might be wrong. if i am and the user needs a QMap API with few elements, then the user should write a QListMap of some sort, not a QList and sprinkling the code with unnecessary for loops all over the place. From: André Pönitz Sent: Thursday, May 16, 20:46 Subject: Re: [Development] Views To: Paolo Angelelli Cc: development@qt-project.org On Thu, May 16, 2019 at 06:31:13PM +, Paolo Angelelli wrote: > i think you and alex stephanov are wrong. if QMap API is convenient, > but does not perform for the few elements use case, optimize QMap for > that use case, And then everybody else pays with cycles for the detection of the special use case. Oh, yeah. I only today run (again) across QDataStream performance. Super convenient, super flexible class. And easily beatable by a factor of ten in performance for each and every individual use case. So - no, you should not have to explain *each* use of a map to your manager but for central parts of performance critical sections you should think twice. Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Views
i think you and alex stephanov are wrong. if QMap API is convenient, but does not perform for the few elements use case, optimize QMap for that use case, and don't make people write thousands of unnecessary for loops. From: Mutz, Marc via Development Sent: Thursday, May 16, 20:21 Subject: Re: [Development] Views To: development@qt-project.org [1] Paraphrasing what Alex Stepanov teaches in his A9 courses: No C programmer would _ever_ get the idea to use a self-rebalancing red-black tree for something that holds a dozen elements. Because once you understand what is required to implement one, you'd shy away from the sheer complexity. Yet, in C++, just typing QMap makes the compiler do all that stuff for you. Don't use a map or a hash just because you can and the API is convenient. Use it when it makes sense, given what data is expected to be stored. And you will invariably end up with using vectors all over the place. According to Stepanov, developers wishing to use a map should seek a face-to-face meeting with their manager to explain why they need it :) ___ 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] Programmable delegate selection for QML views
On Mon, 6 Aug 2018 15:34:00 +0200
Pierre-Yves Siret wrote:
> > - it can only nest (and thus load) QQuickItems, being a QQuickItem itself
> Loader can wrap QObject too. This works : Instantiator { Loader { QtObject
> {} } }
> http://doc.qt.io/qt-5/qml-qtquick-loader.html#sourceComponent-prop : "Since
> QtQuick 2.0, Loader is able to load any type of object; it is not
> restricted to Item types."
True, but that example is a bit artificial.
How about nesting some other QObject * subclass that should be the delegate in
a view?
And, also, loaded elements are childItems of the Loader itself, if QQuickItems.
If it's a QObject only, there's the "QObject *item" property instead.
But then views should then handle the Loader case specifically to extract the
QObject.
If the view uses a delegate model, instead, at least with options 2. and 3., it
would
require no special handling. If the view is supposed to have QObject delegates
and
does not support (in principle) a Loader, no special handling would be required.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Programmable delegate selection for QML views
On Mon, 6 Aug 2018 14:22:43 +0200 Mitch Curtis wrote: > At a quick glance, if we can do it with the existing delegate property (#2), > it would be nice. That's less complex than having two delegate properties. > > One minor problem with this is what we do when none of the delegates match > the data type. #1 seems to cover this > (https://codereview.qt-project.org/#/c/206670/8/src/qml/types/qqmldelegatemodel.cpp) > by requiring that delegate also be implemented if a delegateChooser is > provided. How does #2 account for it? I guess with #2 there should be a way > to provide a "default" delegate, by e.g. leaving all properties (indexValue, > roleValue) unset so that it acts a sort of wildcard? Correct, in this case it's the chooser element the one in charge of providing the delegate, so it should have a fallback nested inside. That's also the way the patch currently works. However, this approach also lets one define a completely opaque subclass of QQmlAbstractDelegateComponent (private API, mind you) that doesn't require nesting anything inside in QML, and does all the magic internally. For example, imagine having a special use case where you get the delegate QML code (or QQmlComponent*, if one wants to be efficient) from the model itself. The special chooser would just get the QQmlComponent from the model and return it. It may not be present, so in this case it would have to return a plain Item or whatever is situationally required (may have to be some other class). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Programmable delegate selection for QML views
Hi, as some of you might have noticed, it's several months that some are trying to remove a long-standing limitation of the current QtQuick architecture: the inability to dynamically select, at runtime, the delegate to use in a view, based on whatever approach, either data-driven (typically using row data, index, etc), or else. The workaround, so far, has been to use a Loader for this. The Loader approach has several notable drawbacks, most importantly - performance, under different situations - it can only nest (and thus load) QQuickItems, being a QQuickItem itself 3 possible solutions to this problem have been suggested in the past few months, but it seems that no consensus has been reached on what is the way to go. So what i want to present, in this message, is an overview of these proposed solutions, to: - understand what is the general preference among the proposed approaches - see if anyone has other approaches to suggest, that might have been overlooked so far Currently suggested solutions are all based on a so-called "delegate chooser" (or selector), that would be queried whenever a delegate is required. The differences are in how to provide such an element to the view from an API perspective: 1. Add a new property to all view classes (ListView, TableView, ***View etc.), where to specify the chooser. The delegate property would be used as fallback, if chooser not present. ( https://codereview.qt-project.org/206670/ ) 2. Make the chooser subclass QQmlComponent, and pass it through the delegate property in place of a regular delegate ( https://codereview.qt-project.org/228909/ , example usage https://github.com/paoletto/MIVQVariant ). 3. Do not make the chooser subclass QQmlComponent. Instead, use another separate base class, like some QQmlAbstractComponentSet. Then mangle things enough so that it could still be passed through the delegate property. Reason for 3. (as alternative to 2.) is that there's one school of thought that see such a chooser not as a QQmlComponent subclass, while still trying to avoid an additional property. Ideally, should there be a clear winner, targeting 5.12 could still be viable. Thoughts? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Rendering only items that are visible in Qt Quick
Could one way be to change QList QQuickItemPrivate::paintOrderChildItems() const; into a virtual method, and reimplement it like in flickables or the like to prevent returning what isn't currently visible? That was at least my idea when i was looking at how to do this on maps (where there are potentially plenty of items, but also potentially only few are visible). Could this work? or what cases would this break? On Fri, 23 Mar 2018 13:44:03 + Mitch Curtis wrote: > I'd like to get some discussion going around this: > > https://bugreports.qt.io/browse/QTBUG-67274 > > As I understand it, clipping (the "clip" property) doesn't prevent items that > aren't visible (in the sense of being out of the viewport, not the "visible" > property) from actually being rendered. > > It would be useful if we had a way to do this with minimal effort from the > user. I'm thinking of a e.g. a property or flag in QQuickItem that, when set, > would cause the scenegraph to use the shape (could start off as just being a > bounding rect) of child items to determine whether or not that item is > visible with regards to its parents bounding rect. That way, any regular old > item can benefit from it easily. > > Does anyone else have ideas about this? > > Comments about how it will never work and I should feel bad for suggesting it? > > Far superior alternatives? > > Please, share your thoughts! :D > ___ > 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] GSoC 2018 Idea: a widget for 2D/3D image display
Hi Xia, in my opinion the project you describe seems a very specific widget, that perhaps would fit best in a Qt-based visualization framework than in Qt itself. After all, where in Qt would such a flexible medical visualization widget live? QtWidgets is supposed to contain only building blocks such as QOpenGLWidget, that you would use as a basis of your specialized widget. Maybe you could look into something like inviwo.org, for creating medical data processing pipelines. best, Paolo On Tue, 13 Mar 2018 21:39:54 +0800 孫夏 wrote: > Hello all, > > I am a student interested in participating in Google Summer of Code 2018 > with Qt. > > As a Qt user before, I used Qt as the UI framework to develop my > application in 3D medical image analysis and video processing. But I found > there's no commonly used Qt widget for image display and interaction, not > to mention a standard pipeline for 3D image processing. > > To my understanding, most 3D image jobs are done as multiple 2D image job. > So I would like to develop a Qt widget that could display and maintain a 3D > image dataset. Most commonly used interaction methods and possible APIs > should also be included. I want to make this widget a standard widget for > all common 2D/3D images and should include most image and video I/O, for > example, OpenCV and GDCM. > > I wonder whether this idea could be considered as a GSoC project. Or on > what points may I improve it? > > Thank you all. > > Best regards, > Xia Sun ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] My understanding on a GoSC project
Hi Yuchen, great to hear you are interested in this project! You are quite right there, such a plugin should essentially wrap valhalla. The project steps you describe seem already a good approximation of a potential project. Actually, a starting point for wrapping Valhalla could be looking at the project https://github.com/rinigus/osmscout-server, where valhalla is wrapped into a standalone server. Some missing bits, imo, are - documentation of a data generation pipeline (Valhalla needs data to work on, and the outcome of the project should ideally contain instructions and tools to produce these data starting from the OSM db file(s)), - Example QML application using the plugin If you are serious about this project, next step would be trying to find a mentor for it, who will also help you writing the project proposal. Please contact us on IRC (Freenode, #qt-gsoc channel), or write me an email, so we can take it further! best, Paolo On Wed, 21 Feb 2018 12:16:22 +0800 Yuchen Wang wrote: > Dear all: > > My name is Yuchen Wong, a student from China. I have 3-year experience > in c++ programming and quite interested in the Valhalla Offline routing > plugin. > > In my opinion, it is a wrapper of Valhalla. In the guideline from qt, a > GeoService plugin should implement at least one ManagerEngine class. Thus I > think we can divide this project into following steps: > > - Investigating Valhalla’s document and divide its function. > - Match Valhalla’s function with the functions we want to implement. > - Code following what we have got. > - Documentation > > It is the last year of my undergraduate. I wanna have fun with this > project during my last summer vacation. 3 months is quite OK for me i believe. > > Yuchen Wong > 2018.2.21 > > Sent from my iPad > ___ > 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] Qt branches & proposal how to continue with those
On Mon, 29 Jan 2018 10:31:14 +0100 Giuseppe D'Angelo wrote: > On 29/01/18 07:59, Jani Heikkinen wrote: > > We have currently really many branches open: > > - 5.6 > > - 5.9 > > - 5.10 > > - 5.10.1 > > - 5.11 > > - dev > > > > In my opinion this is too much to handle effectively, especially because > > there is many branches in stable mode (see > > http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst). Currently '5.6' > > is in 'strict' mode and '5.9', 5.10' & '5.11' are in stable... I think we > > need to change that to be able to work efficiently & get releases out. > > Could you please elaborate, what's the problem at the moment when you > say that it's "too much" to handle? Is it a matter that branches have > become different enough that merges don't apply any longer? Is it a > matter of bandwidth for the releasing team having to produce releases > from several branches? > > > > > So I am proposing following changes starting from 1st Feb 2018: > > > > - '5.6' will move in 'very strict' mode > > Which by the way is already the case, in practice. E.g. there have been > ~20-30 patches landing in qtbase/5.6, with over half being fixes for > flaky autotests. > > > - '5.9' will move in 'strict' mode. So no direct submissions anymore, just > > cherry picks from stable > > This was also proposed a few days ago (to change in 'strict' mode after > 5.11 branching is completed). I have mixed feelings about that, in the > sense that in 6 months from now noone will be doing the cherry-picks > because of the extra work, thus leaving bugs in 5.9 in the name of > stability, but somehow breaks the LTS promise. +1 This will also introduce extra work in patching 5.9 (every change that has to go to 5.9 has to be pushed twice, due to no more forward merges) > > > - '5.10' will be closed and Qt 5.10.1 will be the final release from Qt > > 5.10 series (5.6 and 5.9 are LTS branches so we shouldn't keep Qt 5.10 > > active too long) > > I don't agree, 5.10 releases should be done on a regular basis until > 5.11.1 is out (Yes, .1, many users don't upgrade to .0 versions...) +1 here too Closing 5.10 before 5.11 isn't even released, and actually after just 2 months of releasing, also doesn't seem good marketing material for the project.. > > My 2 cents, ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [FYI] the new way to retarget gerrit changes
On Mon, 8 Jan 2018 14:40:15 +0100 Oswald Buddenhagen wrote: > On Mon, Sep 12, 2016 at 02:39:57PM +0300, Orgad Shaneh wrote: > >Either extend the sanity bot, or create a new bot, which listens on > >gerrit's event stream. > >If the change's owner (or an approver?) posts a comment reading "Please > >retarget ", run your script on the server side. You need some > >sanity test that ensures this branch exists etc... > > > ... which he implemented, and it's deployed now. > > for simplicity, only the change owner may issue the command. for other > cases, you still need to go through an admin. the same is advisable for > batch requests, but do as you wish. > > the regex is > > > /^(?:gerrit-)?bot:\h*(?:please\h+)?move\h+(?:back\h+)?to\h+(?:branch\h+)?([\w.]*\w)\b/im > > which boils down to "bot: move to " at the start of any line of > a gerrit cover message. Tried: bot: move to wip/navigation got the change moved to branch "wip" Bug or my mistake? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Jesus Fernandez for Approver status
+1 Awesome work on OAuth and WebGL! On Tue, 11 Jul 2017 12:06:46 + Timur Pocheptsov wrote: > I'd like to nominate Jesus Fernandez for Approver status. Among other things > Jesus is the author and the maintainer > > of qtnetworkauth module, he is actively contributing to qtcore, qtnetwork, > qtwebsockets, qsql, etc. He is also > > participating in the development of the WebGL QPA plugin. > > > This is his Gerrit dashboard: > > > https://codereview.qt-project.org/#/q/owner:%22Jesus+Fernandez%22+status:merged,n,z > > > Best regards, > > Timur. > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.9 alpha & mapbox-gl-native on windows ?
Hi Alexander, we are trying, but we are unsure if we'll be able to ship the mapboxgl plugin for windows with 5.9. In any case, i believe that, if not, mapbox might make it available outside the qt sdk as an additional plugin. regards From: Development [development-bounces+paolo.angelelli=qt...@qt-project.org] on behalf of Alexander Ivash [elder...@gmail.com] Sent: Monday, February 27, 2017 6:44 PM To: development@qt-project.org Subject: [Development] Qt 5.9 alpha & mapbox-gl-native on windows ? Is it planned to enable mapbox-gl-native building for windows? If yes, then when? Alexander ___ 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
