Re: [Development] Qt quick compiler impact on qmlbench.
On Tue, 2 Mar 2021, at 8:36 PM, Valery Volgutov wrote: > Could you please let me know why I have no any performance improvements > after quickcompiler apply? The QML compiler affects the performance of parsing and compiling the parsed source code. qmlbench is primarily testing the performance of object instantiation, binding evaluation, and the performance (or performance impacts) of various different properties. The code is only compiled once, but run repeatedly, which would also be more true of an application environment - you start your application once, not many times. I think there may be some other benchmarks that specifically cover startup time, but it's been a long time since I looked at it, so I don't really know where to point you off the top of my head. -- Robin Burchell ro...@crimson.no ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Qt offering
[ disclaimer: I wrote this in the middle of a headache last night, so I hope this is understandable ] On Tue, Jan 28, 2020, at 5:37 PM, Volker Hilsheimer wrote: > Would making Qt cheaper make it more likely that the Qt Company becomes > a sustainable business? Would giving a few licenses out for free to > contributors help with that? I doubt it would make much of a difference. That strikes me as somewhat myopic thinking. Being a sustainable business requires profitability, sure, there's more to it. Understanding an ecosystem needs a lot more thinking than looking at a spreadsheet, and it's also that hard-to-understand ecosystem that ultimately has a big effect on profitability. To me, being sustainable is focusing on the long term. Being profitable by next year (say) might be a good thing for a business, but it may not be good for the ecosystem, which in turn means it is not _sustainable_. So focusing on long term growth prospects, new customers, new projects, etc ought to be the focus, rather than the current approach, which to me feels like squeezing increasingly hard on the current pool of people who are using Qt already, which in turn hurts Qt's future growth prospects as a technology[1]. > Maybe you all have great ideas that we missed though. What kind of > change do you think would give companies a really good reason to buy a > license, without at the same time hurting the community? A long-term "nag" at the back of my mind is that there is what feels like a very strong focus on management-level sales. That isn't bad, but the problem is that this audience is very different to a lot of the developer (and open source) types that are directly _using_ Qt on a day to day basis. For example, management are often interested in minimizing costs: so open source or easy binary access etc undermines the argument to charge money, but at the end of the day, Qt is also often "sold" by developers, to developers (or to their own management). This "internal" sales happens in a completely different fashion, by people who are "driven" in a completely different way (technology, open source, problem-solving, "passion", whatever) and generally is a disruptive process, from the bottom up, rather than being imposed from above. As such, the people involved often don't *have* much of a budget at that early stage, so sales/licensing "nagging" will often serve to shut this process down entirely. What they need is for the technology they are interested in to be easy to test/evaluate/consider. Anyway, some concrete suggestions to think about: * Keep Qt binaries easy to access with minimal "sales" or "licensing" talk for first-time users just looking at trying out Qt. Anything in front of that - even a contact form or Qt Account for example which are already in place today - is just a distraction, and will serve to put people off. * Consider limiting the platforms/versions you offer binaries for. For example, offer binaries for the mainstream platforms built against the latest compilers/OS versions, and for anything else (older, or more esoteric platforms), you need to go commercial, or self-build. * The same could apply to LTS binary builds after the standard support period. If you need binaries after 6 months, then you need to be licensed, or self-build. * Make it easy to migrate from open source to commercial licensing: if people are considering giving you money, then why discourage them? Sure, there may be some who will take advantage of this, so impose limits, or make it clear that it's not an unconditional offer, but at least be up-front that it can happen in a nice fashion if both sides play nice. === [1]: Some anecdotes that immediately come to my mind from my own personal experience: * I am aware of situations where they keep their Qt-using code to an absolute (licensed) minimum, and refused to let anyone else really touch it or learn about Qt, because of licensing costs. * I have spoken with people starting businesses who were on the fence about - or ultimately chose not to - use Qt because they couldn't afford to pay for commercial licensing, and weren't able to understand or make use of the open source options. * I have spoken with people who really liked the look of Qt/QML, but immediately wrote it off as an option, because they were unsure enough about the licensing situation that they simply didn't want to take the time to look at it in more than a cursory fashion. They ended up using an alternative technology stack instead, which involved significantly more developer effort on their part - but budgeting for developer costs was seen as the better option, as it was possible to cut back on or outsource as needed. None of these things reflects positively on Qt&
Re: [Development] QTCS2019 Notes from QtQml session
On Tue, Nov 26, 2019, at 8:56 AM, Ulf Hermann wrote:
> We're also changing the way views and delegate work. If you want to use
> the "index" in a Repeater's delegate you'll have to declare that in QML
> 3, using a required property:
>
> Repeater {
> model: 10
>
> Text {
> required property int index
> text: "item " + index
> }
> }
Can you explain a bit more about what the concrete problem is with model data
on delegates? Speaking specifically about inline delegates[1] like the one you
give here.
In many cases, like the one you provide, is the additional required statement
really required? ;-) - when it's clear that the component is a delegate, it
seems rather redundant and annoying to have to specify additional 'required'
statements to be able to use the data that is always provided by the model's
context. I don't see why it makes sense to require an inline delegate to say
"hello, I am a delegate, please give me a delegate's properties" when you
already specified that it is a delegate when you wrote the component a line or
two above.
Perhaps I'm missing something, or perhaps this will only apply for external
delegates in a different file - but my opinion is that for inline delegates, I
think it would be an acceptable limitation to continue to 'hijack'
model/modelData/index on a permanent basis without any additional syntax.
Given that such inline delegates are so very, very frequently used, I think
that the bar for changing how that works in a user-visible way should be quite
high.
[1]: I suppose this would only really apply for inline components, too, where
it's clear that the component is used only in conjunction with the view in
question, but I think that's fine. Inline delegates are way more common than
external delegates (IME) and are also written as throwaways quite frequently
during quick prototyping, which should be as easy as possible ideally.
If your delegate gets complicated enough to split out to a separate file for
reuse or autotesting purposes, then sure, requiring a specification of what
that component uses of course makes a lot of sense, and I would be in full
favour of that, having been bitten by a few bugs in those cases.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
On Mon, Nov 25, 2019, at 4:55 PM, Robin Burchell wrote: > The situation for QML3 seems to be much less clear cut (This got sent a bit too early (hotkey mixup). Pretend this was at the bottom of my last mail.) I can't really comment on all of this stuff individually, because I'd be writing an encyclopedia and I've already written a lot (and I've been trying to stay away from Qt for a while because I've been too busy and burned out to have the time or the patience to do anything here anyway), but this is important enough that I thought I'd at least try. I guess my thinking in general is: New things are good. Change is good. But both of these are only actually good if they are genuinely worth the pain that the transitioning involves. Change that involves touching every file (version numbers, removing anchors.left/font.bold), or rewriting code in one way to another (context properties to singletons) seems like something that is honestly not worth fixing unless there is a very clear gain that I'm unable to discern from it because it pointlessly adds pain onto your users, who in turn will add pain onto you by not performing a quick transition and forcing you to support the old stuff far longer than you'd reasonably want to. I think it would be much better to see more effort put into smoothing the transition - whether that's through automation/tooling, or a relaxed approach to deprecating these features - or something, at least for some amount of time, rather than just saying "tough luck, go run an obsolete version of QML". -- Robin Burchell ro...@crimson.no ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
On Mon, Nov 25, 2019, at 3:53 PM, Ulf Hermann wrote: > Yes, but the problems with this construct are the same as with generic > context properties: Your QML component requires some context that it > doesn't declare. Therefore your code is not reusable and brittle wrt > addition of properties in other places. Which is why I also provided a possible solution - by providing declaration of that context. I'm not sure whether you just stopped reading once I started talking about the problem, but I'd be interested to hear about whether or not something like that approach was considered. > Mind that all those dynamic lookups will still live on in QML 2, and we > will maintain QML 2 throughout Qt6. They just won't be valid in QML 3. It's good to hear that QML 2 won't disappear overnight, but let's not pretend that this would be a sustainable, good situation to be in. One day, QML 2 will disappear. At least, given the lower version number, you would hope it will disappear. But every piece of pain that makes porting harder will help to ensure that it stays around longer. And even if there wasn't going to be pain in porting - there is going to be a lot of residual friction in transitioning. All of the documentation, all of the examples, all of the tribal knowledge will suddenly become irrelevant. And for what? Why? Yes, there are problems with some features. That doesn't necessarily mean they are unsolvable problems (perhaps they are; without having a proper discussion about it - how do we know?) By the sounds of it, QML2 to QML3 will not be an easy transition. I was already a little worried when I saw changes removing versioning, and a WIP change deprecating context properties back in April or so, but reading your mail makes me very concerned for the future. For reference, QML1 to QML2 was a _relatively_ easy port for example, despite a different JavaScript engine, a new item set, and a completely rewritten graphical presentation. My personal opinion is that this was very good, because it gave you a pretty big no-brainer: spend a small moderate amount of effort to port and validate/test, and in return, you gain much better performance. The situation for QML3 seems to be much less clear cut ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
On Mon, Nov 25, 2019, at 10:43 AM, Ulf Hermann wrote:
> Indeed we need to deal with this somehow. Maybe we do need to retain
> versioning on a module level. For example, the qmldir file could specify
> what versions of which other modules it expects. Or we define that it's
> not a problem ...
I think at least module-level versioning is a sensible idea.
> We could detect this in qmllint by just continuing the search for IDs
> even if we've found a property.
We could, but if I may gently suggest, I think I can count most of the people
who use qmllint on a regular, useful basis on one hand ;-).
(One possible improvement to this could be to not _just_ have it as a separate
tool: maybe debug builds should _also_ run qmllint - or at least a subset of
its checks - on the code that the engine is loading? Alternatively, perhaps as
an engine flag to at least allow it to be turned on once, and happen for
everyone on a team in a unified zero-effort way)
> Mind that adding a method to a base class in C++ will shadow unrelated
> other classes and functions even if it's not virtual or overridden. Why
> did we actually decide that we can live with this effect in C++ but not
> in QML? - Maybe because in C++ it's more likely to result in a compile
> error due to mismatched signatures?
I think one of the biggest problems is that ID resolution crosses file
boundaries. This essentially means that the ids chosen can very easily become
part of the "API" of a component unless you are very vigilant to not allow that
to happen.
Essentially this means that identifiers - and a child redefining an identifier
that the parent happened to use - suffer from the same problem that you point
out class members can suffer from.
This is a contrived example, but I have seen similar things to this cause bugs
in production.
Picture a SettingsButton.qml with this sort of contents:
Button { MouseArea { onClicked: console.log("clicked"); } }
Looks nice and innocent, right? But I notice that the MouseArea doesn't work
because it has no geometry. I want to refer to it elsewhere in this component,
too, so let's give it a name.
Button { MouseArea { id: someFoo; width: parent.width; onClicked:
console.log("clicked"); } }
In sensible code, this would work just fine, and have no complications.
Unfortunately, what you didn't know was that Button.qml is:
Rectangle {
width: someFoo.width
height: 10
}
The use of someFoo here was previously referring to a parent id. Now, it finds
that id in the child instead, with a very different geometry to what was
expected - just the same as if this was a property on the root item.
This is not an easy problem I think. For sure, you can't just take the "easy
way" out and warn about duplicate ids during lookup, because while _sometimes_
this inheritance is decidedly wrong and not what you want, a lot of the time,
id scoping is "private" and just fundamentally how code is written. In the C++
world, this would seem pretty silly:
class Base { private: int m_myImplementationDetail; }
class Base : Derived { private: int m_myImplementationDetail; } // warning:
duplicate variable "m_myImplementationDetail" found in class Base
Yes, they do indeed have the same name, but that's also unambiguous and fine.
If we do consider them to be part of the API *sometimes* though, perhaps the
right thing to do is to allow that to happen explicitly: specify what ids can
be "exported/imported" and issue a compile error if those expectations are not
met.
One problem though is that this import/export boundary should be checked at the
file boundary, _not_ the component boundary, otherwise using things like Loader
become a lot more annoying.
So perhaps it could look something like this:
import MyModule ...
expects Item myFoo; // we want something of type Item, identified as myFoo to
be passed in from a containing file somewhere
provides MouseArea bar; // we provide this ID for children to find
Item {
width: myFoo.width
MouseArea {
id: bar // is visible in scoped lookup (via 'provides' at the top)
}
}
I guess you might also be able to use this for context properties - which
suffer from many of the same unclear scoping issues rather than just outright
removing them, but that might require some additional considerations that I'm
not sure of right now.
--
Robin Burchell
ro...@crimson.no
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Views
Hi Marc, I agree with a lot of your points. Performance is important to me. I won't get bogged down in the specifics, because way too much energy has already been wasted on this (and related) threads I think, so I'll just say a few things. On Thu, Jun 6, 2019, at 10:45 AM, Mutz, Marc via Development wrote: > IMO, that hits the nail on the head: we have an obligation to our users > to use the most efficient data structure (and, by extension, looping > construct) we possibly can, and can't just pop in the first data > structure that comes to mind. The thing is, loops are easy to use. Containers are easy to use. You might know the STL like the back of your hand - I will be the first to admit that I don't. I write loops, I don't use find_if. I commit many other sins like this on a daily basis. The same is true I'm sure of many other pieces of the STL, or indeed, any other software. However, to make myself feel a little less awful, I will add that I am sure that I'm not alone here, and I think that is why some people have been pushing back a bit on the point of abstraction. Using the specific example of QMap: It's one thing to know not to use a QMap for a small container; it's another issue altogether to have an easily usable alternative that can be used in place of it, especially if the container is supposed to be exposed to another component, for example. It's simply less reading/writing/cognitive effort to bang out container usage than the alternative. That is generally the purpose of abstractions, after all. > IMNSHO, you can optimize for readability in your own app and see whether > you sustain in the market. In a library, used on millions of machines > every day, spending 8KiB (or 4KiB, or just 1KiB) just to use a slightly > less noisy code version is - sorry - selfish. If you contribute to Qt, > you should be putting yourself in the service of it's users. Again, I'll emphasize that I don't disagree with the point that you are making. I just think that you may want to consider that various enablers can make your life easier in that you have to write a lot less grumpy size-reducing patches, and a lot less mails arguing your point. That is one of the points of Qt, after all: that you make it easier for other people to write better code faster. > I have the feeling that some participants of these discussions thought > they joined an adulation club for Qt API lovers instead. I don't agree with this kind of attack, though, even if it was not directed at any one individual by name. Let's (_everyone_) please keep the mailing list a pleasant place to read (and write). -- Robin Burchell ro...@crimson.no ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Supporting helper functions in auto tests by providing throwing Qt Test macros
On Wed, Apr 3, 2019, at 1:24 PM, Giuseppe D'Angelo via Development wrote: > I may like the overall approach. However, this would imply that such > tests require exceptions / RTTI turned on inside QtTestLib / user code; > is it "OK" in the grand scheme of things? Note that testcase.prf already enables exceptions, at least for Qt's own tests (apparently, according to Mitch, with the exception of testlib's self tests). ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Supporting helper functions in auto tests by providing throwing Qt Test macros
On Tue, Apr 2, 2019, at 5:17 PM, Mitch Curtis wrote: > Quoting the commit message here: > > WIP: Add _THROW variants to testlib macros > > This allows using Qt Test macros in helper functions, avoiding the need > to write a lot of boilerplate code as seen with alternative approaches. Allowing other functions to terminate a test would be great, but I wonder if it's worth considering changing the "regular" macros to terminate tests through an exception it throws internally, thus avoiding the need to introduce a new set of macros. You could of course introduce a new macro specifically to throw (and I think that would be a good idea to automatically gather __FILE__ and __LINE__ in a non-messy way), but this way one could just use the regular macros we already know and love in new ways. It would mean that tests would need to support exceptions unconditionally, but since it's "just" test code, perhaps this isn't that big a problem. -- Robin Burchell ro...@crimson.no ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt modules, API changes and Qt 6
On Wed, Jan 30, 2019, at 9:17 AM, Alex Blasche wrote: > I am clearly missing something here. Could you please outline why such a > monolithic repo would be good? As you pointed out yourself, the > conceptual problem that different libraries won't walk in lockstep > remains and segmented builds continue to be desired. Sure, repo checkout > is easier but as long as segmentation exists I fail to see the > advantage. Split repositories have a lot of problems, both social, and technical, but I'd say that it all boils down to extra friction. On the technical side, you have the well-known problem of API changes. When you make one, you have to make it in a backwards-compatible way, integrate that into qt5, then change everything, integrate that into qt5, then remove the backwards compatibility. That's a long process, even if everything goes perfectly (reviews are easy, happen quickly, CI isn't flaky, etc, etc). Then you have the social side of it. Basically, I think I can summarize it as being this: a repository boundary generally makes a problem into "someone else's problem" rather than "my problem" or "our problem", because the perception is it's easier that way, even if the cohesive whole ends up suffering as a result. I will admit that a monorepo has a _different_ set of problems (including but not limited to: longer build times, longer test times, flaky tests in unrelated areas blocking changes), but those problems are not complex, and can be fixed with some dedicated application of smarter scripting at build/test time (for instance: if change is doc only, don't run any test that _isn't_ related to documentation, to cover one complaint from earlier in this thread). I don't think that changing the technology behind how we contribute today would necessarily fix any of this split repo stuff either, I think a lot of it is just inherent to how such a system works. For instance, a project I am currently working on uses a completely different toolset, yet suffered from (a version of) exactly the problems outlined here -- and once we realised just how hard that was making life, and merged a bunch of repositories together, suddenly, things became a lot easier. The repository merge, in our case, helped to inspire actually applying work to _fix_ those problems rather than just working around them by splitting things into smaller pieces, too. Another real life anecdote: when I merged together our bunch of repositories, I was annoyed by ~20 minute clean build times of one component in our CI pipeline. I found out that it was due to heavy (ab)use of templates, which I managed to work around in a largely source-compatible way, and dropped the build time of that component down to ~3 minutes, which certainly made the people working on that component happy. I wouldn't have done it without the repository merge, partly because it wasn't "my problem" before, and partly because I just didn't notice, as I didn't work on that component: I still don't, really, but because I live near it, I see the code in grep results. I see the impact it has on build/test times, and so on. Robin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Build system for Qt 6
On Tue, Oct 30, 2018, at 5:40 PM, Oswald Buddenhagen wrote: > on top of that there are long-term savings to be made from increased > productivity (which several posters to this thread have confirmed or > implied). that alone won't offset the cost vs. using cmake (it would vs. > developing and using qmake), but it's not negligible. Speaking specifically about things _other than Qt_ (this does not really apply to Qt - though perhaps it does a little): I can't really judge any of these savings as I never really had the opportunity to try qbs (and this is coming from me - someone who deliberately tries to experiment with almost every new, strange thing there is out there). I think that qbs's worst enemy was that the "competition" of everything else in the space was good _enough_ (yep, even qmake, warts and all). Build systems, from the perspective of the people using them to build other things, are not a tangible part of the deliverable product you make money off of. They are a tool that _enable_ you to produce such a product. Any effort that goes into changing that tooling takes effort away from other areas that more directly make money - and that effort requires justification. From my personal experience, I have never had a compelling answer for "why should we port to qbs" to give that justification. "Why should we port to a tool that very few other people are using that doesn't provide clearly night-and-day amazing benefits when what is available today is better known and works well enough"? Indeed, I'll let you know if I ever figure out an answer to that one. This isn't meant to say that any one tool is perfect - of course, they're not. But they're good enough most of the time. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
On Thu, Oct 25, 2018, at 11:50 AM, Rafael Roquetto wrote: > So I will go back to my question: what is it we are trying to solve? Or > rather, what is it that happened, that we are trying to prevent from > happening again? There will always be lunatics, and a CoC won't stop > them. Perhaps it will improve things... but... perhaps it will do more > harm than good. Or is it proven technology? The problem with that question is that by the time you need to _solve_ something, or prevent it from happening _again_, it has already happened. The point of a code of conduct as I understand it is that it is supposed to help prevent situations from arising/escalating out of control in the first place, and if that ever does happen, provide a process to resolve it in a well defined (and ideally, minimally damaging) way. [ As an aside, I've seen communities go very bad - with or without a code of conduct - so the "code" alone won't save you- at the end of the day, it's all down to you, me, and everyone here to do the right thing and make this place a good one. ] > Which brings to my second point, a very personal one: more or less in > line with what Jason said, programming *to me* has always been about > bits and bytes, about the code, about computers, about being able to > make things appear on the screen and to control the machine. Free > Software has been about free software and that's it. I find it > extremely off-putting to see that the Qt project is embarking in this > sort of politics - again, if things were broken and a CoC could fix > them, I would be more than happy to join the train, but that doesn't > seem to be the case. At least from my humble perspective. I will first acknowledge that I am in a privileged position - I've never been on the bad end of any sort of discrimination - and for those that have been, or worse, are systematically in that position, it is much harder for them to effect any real change to that without the clear capability to show that this sort of thing is not OK. With that having been said: my own personal stance is that I would _like_ it to be possible for this stuff to not be needed. I would _like_ people to be smart enough to understand that they should do, or not do, certain things in order to cooperate and "get on". But everyone is different, after all, and a common sense of "correct" is not necessarily as common as we might think, or hope. So while I don't personally find it necessary, I do try put myself in the shoes of someone less "fortunate" than myself while considering it. What do you do if you are certain that your contributions are being ignored not because of technical merits, but because of [ your own ] personal characteristics? Without a clear guideline of how that sort of a situation is approached, the only real answer is, simply, "you stop contributing". Which is a losing proposition: the community loses a potentially valuable contributor, at the cost of a toxic environment that is not at all based around technical merit - the exact opposite of what we want to happen, I'd say. > Communication/criticism just like this is unambiguously straightforward > and I *personally* prefer it this way. Unfortunately I could not make it > to the QtCS, but had I been there, I would have voted against the CoC, > for sure. I hate to see politics tainting the project. I tried to spell this out, but I think it needs repeating. In my view, a code of conduct is not a political tool, nor a legal document (if it is done well). It is a codified form of what is acceptable to the project, which at the purest form might be: contributions good from all comers of all types, and if bad things happen, here's how they are resolved. -- Robin Burchell ro...@crimson.no ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Coin maintenance notification
https://testresults.qt.io/coin/ shows the last successful integration at ~4pm, and the integrating list is full again: https://codereview.qt-project.org/#/q/status:integrating,n,z So I guess it's not fixed, or something else broke? -- Robin Burchell ro...@crimson.no On Thu, May 31, 2018, at 1:43 PM, Simo Fält wrote: > The update introduced some unexpected “features”, which were reverted/ > fixed. > In addition to that, we suffered from infra related problems today. > Those also should be fixed by now. > > Due to issues above, CI is a bit busy atm, so please be patient. > > Simo > > On 29/05/2018, 9.14, "Development on behalf of Aapo Keskimölö" > aapo.keskim...@qt.io> wrote: > > Coin production will be updated Tue May 29 09:30-10:00 EEST 2018. > > See attachment for related changes. > > > Kind regards/Ystävällisin terveisin, > Aapo Keskimölö > > > ___ > 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] QTBUG-43096 - QML instantiation performance decadence
On Fri, May 25, 2018, at 9:14 PM, Uwe Rathmann wrote:
> On the Qt Conn 2016 Andrew ( Knight ) presented our very first results,
> when comparing 4 different implementations of an average button.
>
> a) a button from Quick Controls 1
> b) a button from Quick Controls 2
> c) a custom button composed in QML ( this is your approach )
> d) a button from QSkinny
>
> All implementations have been done in QML with very similar code.
>
> Unfortunately the presentation has not been recorded, but out of my
> memory one of our statistics was:
>
> a) > 30 QObjects
> b + c ) 7 QObjects
> d) 1 QObject
I'm familiar with numbers like that. I've come up with many similar ones myself
in the past. The first point I would make in reply, though, is that the
convenience of creating code with a/b/c are going to be significantly better in
my experience.
And in addition, nothing (except the lack of a need to _actually_ go this far)
stops me from writing a button using QSGNode instances today, without any use
of private API and similarly avoiding many of those object allocations.
The one feature that would be a problem would be a missing public text node,
which would mean I'd have to resort to a QQmlComponent with a Text item in it
to set my label. Off the top of my head, that makes three QObjects, for the
record: a QQuickItem for the button, a QObject (really a QQuickTextItem) from
the component, and QQmlComponent itself, though that last one can be shared
between buttons.
Adding a public text node would be nice if we wanted to make it a single
QObject, but doesn't justify creating a whole new framework to me, given it's
perfectly possible with the API of QtQuick today, and there is plenty of
precedent (and demand) for it.
(And no, I don't think that just making QQuickTextNode public is the answer.
That is a very, very heavy set of classes, it really needs some thought and
cleanup applied first I think, alas, I don't know of anyone working on it
today...)
> ( But we also noticed stuff like that: QQuickGradient is a QObject and
> even QQuickGradientStop is one. So for the definition of a gradient with
> 2 colors you need 3 QObjects: > 400 bytes. These little things could
> easily being fixed by using Q_GADGET - but obviously nobody cares. )
It's not that nobody cares, it's that you can't actually do that without
breaking code that probably[1] exists in the real world. Let's take another
good example from the top of my head: Item::anchors. Behind the scenes, it's
implemented as a QQuickAnchors, which is a QObject. Let's turn it into a
Q_GADGET, and we're done, right?
Well, not quite, because now any code that does this:
anchors { onLeftChanged { ... } }
or this:
this.anchors.leftChanged.connect(function() { ... })
or in the C++ world:
connect(myItem->anchors(), &QQuickAnchors::leftChanged, ...
... will break, since Q_GADGET doesn't have signals - so it's simply not
equivilent.
It's nice to contemplate this sort of stuff, of course, and I'd love to see
common features like anchors made cheaper (really, gradients aren't anywhere
near as common, at least for the sake of my eyeballs I sure hope so), but doing
so requires a careful approach, and probably a good chunk of grunt-work and
magic that doesn't exist right now to make it actually happen, which is likely
why it hasn't happened yet. Suggestions of how (or better still, patches), most
certainly welcome.
[1]: almost certainly. my personal rule is: if there is API for it, someone
will misuse it in the most awful way possible to make your life hell with it,
somehow. I think one has to have a love-hate relationship with users, you can't
live without them, but my god you wish you could sometimes ;-).
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTBUG-43096 - QML instantiation performance decadence
On Fri, May 25, 2018, at 4:31 PM, Uwe Rathmann wrote: > But at the time, when Controls 2 has been started everything was on the > table and - at least from the outside - it looked like a comfortable > situation for making good decisions. And this is what I had expected to > happen: What happens is only what there are enough time and resources to do, plus a direction to do it in the first place. It might be that you had attempted to drive some of this work yourself (or yourselves), I don't know - but I didn't see any discussion about it on this list that I recall, and I don't recall anything hitting codereview either, so I have to say that from the perspective of the project, I can't see how you could really expect this to happen. > Unfortunately I never noticed any indication pointing into the direction > of a better C++ support. In fact the opposite happened: even the very > base class of all QC 2 controls is not part of the public API ! Why does it need to be? I have never needed to subclass QQuickControl, personally, so I have never brought this topic up. Assuming you have a valid reason, then I would present my next problem with that: it's probably not mature enough. QQC2 is only three years old, and it is (still) going through quite a lot of change that is often likely not ABI compatible[1]. Sure, it's often _possible_ to work with this stuff in a backwards-compatible fashion, but that comes at a strong cost, which then requires answering: does the cost of having to work in such a manner justify making it public? I would tend to suggest no in that particular case from what I know right now. > The stupid fact is that QML always comes at a cost. Trying to reduce > these cost has been successfully done and any further improvements are > welcome, but: as long as there is no clear separation between the Qt/ > Quick graphic stack and QML I disagree, that the "right direction" has > already been found. There is a cost, yes. But I would say it's more a cost/benefit tradeoff. Faster prototyping and development cycles at a cost of requiring some of your resources to munch on. And, well, this problem isn't just limited to QML or QtQuick- if you want to run Qt as it exists today on a lightbulb, you're probably getting something wrong in your architectural design. ;-) Anyway, wrt direction, I assume you are hinting at a scenegraph that is less tied to QtQuick. If you are volunteering to help engineer such a separation in a way that is maintainable in the long term, and doesn't negatively impact performance of the graphics stack's consumer (QtQuick), then I have no objections personally, though I'm not really the right person to talk to. I would suggest coming up with specific proposals for what you want done, talking them over on this list, and then working on patches assuming there are no objections. But if you are asking me personally to separate the scenegraph out, then I have no interest in doing so. As I said, I am happy with QML and QtQuick in their present form (with hopefully indefinite iterations to improve it over time, of course). [1]: This does bring me to something that I do find unfortunate: API stability is a lot easier to promise than ABI stability. I can imagine a world in which we would have a public _API_ for more things than we do nowadays, but I am hesitant to contemplate that too much, because it ties our hands in changing the implementation a lot wrt ABI compatibility. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTBUG-43096 - QML instantiation performance decadence
Hi Uwe, I had predicted a response, so this mail comes as no surprise to me :) Personal opinions on various things ahead, the reader may disagree with me, that's perfectly normal and OK. >From my own perspective, I think Controls 1 was a well-intentioned mistake. It >set out to fill a perceived hole in what QML/Quick offered, but it took some >shortcuts getting there, which were no doubt unavoidable due to various >reasons - if nothing else, the times were rather turbulent in the Qt world at >the time. The end result of this was not something pretty, when looking at the >pile of things like ScrollView regressions, usually a few per release, before >even getting to performance concerns. Unfortunately, of course, since it existed, it got used - despite the shortcomings - though I would say that they likely made themselves very obvious without looking too hard. At this point, from my perspective, QQC1/QQC2 is largely water under the bridge. I have over the years avoided using QQC1 in several projects as I knew that the performance simply wasn't up to the task without ever trying it "seriously", instead developing custom controls or - now that it is available - using QQC2 where appropriate - so unfortunately, I won't really be able to comment much on that "excitement" except to say that I am happy that QQC2 exists, and I look forward to its continued growth and maturity to fill the gaps with QQC1 where possible and necessary. This leads me onto topic #2, which is QML's performance itself, and to me, this is a much more interesting topic, and where my own personal concern in the 5.1 -> 5.2 transition came into play. I experienced first-hand a lot of pain in those times and, realistically speaking, I don't think things really started to settle down until some years later. With the benefit of hindsight, I don't personally think that the engine transition from 5.1 to 5.2 went well, but on the other hand, people are human, and will make mistakes - the important thing is to learn from those mistakes, and not repeat them. As well as that, there were no doubt a number of contributing factors then, similar to QQC1's. That's quite far in the past, though. Nowadays, there has been a lot of work around the performance area, and it has continued to improve. There's also tracking of performance, to help avoid regressions in the area in future. These are the key reasons I closed the bug -- I think that the message has been heard, improvements have been made, and hopefully things are now consistently heading in the right direction. You mention qskinny. I think that experimentation is very cool, and it's great that it is working out for your project, and I am already familiar with it, but I'm not too interested in it personally, simply because the QML of "today" (having written a few libraries LOC of QML at this point) generally works well enough for me, and I find the convenience of the language very much worthwhile. I suppose it is also my role to be a cheerleader of sorts for this thing, so there's that. ;-) Even if our opinions differ though, I'd like to thank you for providing your perspective and story - it is not a surprise to me as I hope I have spelled out given the history of things, but it is interesting to hear. While I hear a lot of reluctance in your mail, I would encourage you to give QML another try in the future, and seeing how it goes for you. If there are things that you find surprising or unpleasant in the performance area, by all means, keep filing issues. Just because that one bug is closed doesn't mean the story is over: performance is a crucial feature in product development, and it is something that we must remain vigilant about, and work on continuously. :-) Thanks for the mail, Robin -- Robin Burchell ro...@crimson.no On Fri, May 25, 2018, at 1:12 PM, Uwe Rathmann wrote: > Hi all, > > this morning I got a notification about > https://bugreports.qt.io/browse/QTBUG-43096 > being closed. I guess many applications had been hit by this issue, but > as I was related to the project that created this bug I would like to > give my summary of what has happened since then: > > a) > > On the Qt development side a lot of efforts have been made to improve > the QML problem. I don't want to be disrespectful, but the fact, that > Controls 1 has finally become deprecated, because of ( IIRC ) > "insolvable performance problems", it is fair say, that those were no > game changers. > > So to me the only step that really matters was introducing Qt/Quick > Controls 2. > > But what makes Controls 2 being superior compared to its predecessor ? > AFAIK the answer is mostly about doing less QML, achieved by: > > - dropping features ( usually desktop rel
Re: [Development] Nominating Kari Oikarinen for Approver Status
+1, and I'm surprised it wasn't already the case actually :) -- Robin Burchell ro...@crimson.no On Fri, Feb 9, 2018, at 2:18 PM, Rainer Keller wrote: > Hello everybody, > > I'd like to nominate Kari Oikarinen for approver status in the Qt Project. > > Kari has been contributing to Qt for Device Creation, COIN and several > other parts of the Qt project. He also is the maintainer of the Qt Debug > Bridge. His track record can be found under: > > https://codereview.qt-project.org/#q,owner:kari.oikarinen,n,z > https://codereview.qt-project.org/#q,reviewer:kari.oikarinen,n,z > > With regards, > Rainer > ___ > 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] QML and Qt Quick versioning of our modules
On Thu, Dec 7, 2017, at 02:53 PM, Frederik Gladhorn wrote: > I've lately been discussing with a few people in The Qt Company about our > versioning. Thanks for taking the initiative Frederik! > And a general confusion around which version does what. > Since we so far don't keep copies of old functions around (as far as I'm > aware at least), I don't think there's a huge value in the versioning system > in > the first place. > It only gives one important guarantee: if you added a property/type/name > and > import a defined version, you don't suddenly get conflicts because we > introduced > the same name. There is an additional added benefit: if you are targetting a system other than the one you are developing on now, you can set your import version appropriately, and you won't be able to use any properties/etc that were added later on than your target system. This is pretty good for working on a "product" while not messing around with your system-installed Qt, though I'll admit it's probably not a massive one. I have wanted to be able to somehow get information about what version was imported in the past, but it's not straightforward to see how to accomplish that. It would then be useful for introducing changes in behaviour that can then be explicitly opted into, though, without needing to necessarily wait for a major version. > Some modules started to copy the Qt version, e.g. Multimedia, that's > pretty easy to remember and a good start in my opinion. Agreed. The only caveat here is that it would prevent a repeat of QtQuickControls 1->2: if you copy the major version from Qt, you can't replace the whole implementation without giving it a new import, or waiting for a new Qt release. I see this as a benefit in some ways: I've heard of a lot of people who were (or are) confused by this, as the two do offer some functionality that differs. > 1) sync minor versions to Qt release version: > For Qt 5.11, we would provide QtQuick.Controls 2.11 > This way, the challenge for the user is only to find out if it's version > 1, 2 > or 5. Seems like a good idea. > 2) Make the minor version import optional and we pick the lastest. This > should > be optional to prevent the name clashes described above and shifts the > risk to > the user. > In practice I'd expect this to be pretty safe. > import QtQuick.Controls 2 would then give the latest version available. I'm inclined to prefer we don't do this, but I don't feel too strongly about it, either - at least not as long as revisioning is as weak as it is. > 3) Make even the major version optional and we'd pick up the latest > version. > import QtQuick.Controls would give version 2.11 with Qt 5.11. As well as preventing a QtQuickControls 1 -> QtQuickControls 2 transition again, this would also impact a hypothetical Qt 5 -> Qt 6 transition: QtQuick 6 (let's say) may well have behaviour changes in some form over QtQuick 2. If we don't require versioning at all, then suddenly, code that may not be able to work with that will be forced to use it. Making the minor version optional doesn't seem to have many caveats, but the major version is a bit more limiting and scary, given we don't have a linker to help ensure we're using the right dependencies... > Luckily we now have qmlRegisterModule(QT_VERSION_MAJOR, QT_VERSION_MINOR) > to help registering the current versions already. Yep, this is good :) Another potentially interesting idea that came to me while thinking about this just now: what about implicit imports (versioned), added in the qmldir file? Such that an: "import QtQuick 2.10" in the qmldir applied to everything in an import that don't specify an implicit version themselves. That would reduce clutter for anything which actually has a qmldir (which tend to be most larger more complex things), maybe that's good enough? Then, an application template could use that out of the box, too. I don't know offhand how hard this would be, but I don't think it would be too difficult. -- Robin Burchell ro...@crimson.no ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Updating community Qt4 port for OS/2 to Qt5
On Sat, Aug 5, 2017, at 11:41 AM, Paul Smedley wrote: > Thanks for the reply. Any hints on the minimal files necessary for gui > apps to work. At this stage, I'm not fussed about clipboard, drag and > drop, etc, just the bare minimal to get gui apps working. Hi Paul, So the basic idea you've probably already gathered is that each platform needs to implement a "QPA" plugin: https://wiki.qt.io/Getting_Started_With_Lighthouse covers some of the basics here, but in a little more detail: A QPA plugin provides the glue for things like windowing and input between Qt and a native windowing system. To start with, take a look at the 'minimal' QPA plugin (which just does software rendering, AFAIR directed to image files on disk), and look at how to fill in things from there -- the starting points you'll want are a QPlatformIntegration, QPlatformWindow, and QPlatformBackingStore. You want to look at QWindowSystemInterface to deliver events (like expose events saying "please start/stop rendering the window", and input events) from your QPA plugin to QtGui. What you want past there is a bit more fuzzy and depends both on how complete you want your integration to be and what your platform provides, e.g. QPlatformClipboard and stuff like that, but I'd put most of that stuff in the "optional extras" basket. As you've already figured out, the structure and code involved is quite different, so I doubt it'll be a 1:1 port - but the existing plugins provide pretty good guidance on how to lay things out, and your existing code would be adaptable without too much work I think. Good luck, Robin -- Robin Burchell ro...@crimson.no ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [BB++] Now is 3.5x faster than Node.JS
Hi Phil, On Sun, Jul 23, 2017, at 04:48 PM, Phil Bouchard wrote: > All you have to do is create a ListView with images in the ListView > Items, scroll the ListView and then you will see the ListView's > scrolling speed not being uniform in an unpredictable way. Whatever's > unpredictable is caused by the GC. You didn't give any details about how you measured, or what you were measuring on, so I gave it a shot -- I'm sorry, but I can't replicate these results, and even with a highly artificial test case[1] that scrolls a ListView constantly, I only see one GC run every so often, and it does not delay for any sort of significant amount of time (on a 2013 mbp, running a slightly old Qt 5.9 snapshot, on OS X): [D] default: QV4::MemoryManager::runGC:987 - Marked object in 0 ms. [D] default: QV4::MemoryManager::runGC:988 - Sweeped object in 1 ms. [D] default: QV4::MemoryManager::runGC:989 - Used memory before GC: 1095008 [D] default: QV4::MemoryManager::runGC:990 - Used memory after GC: 106784 [D] default: QV4::MemoryManager::runGC:991 - Freed up bytes: 988224 [D] default: QV4::MemoryManager::runGC:992 - Freed up chunks: 14 Running with QV4_MM_STATS=1 with a newer Qt (dev branch) should also show you a more precise time (in us, rather than ms), as well as information about what object types were GC'd. In my experience, GC is not often the root cause of "janky" interaction in QML, simply because most of the allocations don't originate from there, unless you are writing a really high amount of JavaScript, or very complex bindings. The image content of the Image element for instance is not allocated through garbage collection. Much more common sources of performance problems: * doing too much (overly complex delegates, or bindings) -- creating objects, and evaluating bindings is expensive * blocking the main thread elsewhere in the application * problems with the platform or graphics stack (or their integration with QtQuick) Of course, even more often, you get some kind of a combination of the above... Anyway: my experience doesn't rule out the possibility of there being a problem, but so far I am lacking evidence that there is one (a test case), and I am lacking evidence that garbage collection is the cause of that problem (investigating that test case with QV4_MM_STATS, and other tooling). Please create a bug with a test case (simple enough that it can be run standalone like mine below) where you see more details on the performance problem you see, with information about your platform, and full details about how you measured the results (if you did any such measurements). [1]: https://gist.github.com/rburchell/3026d3229d4211f71b947e3f9eee6d9f -- run with qmlscene, setting QV4_MM_STATS=1 in the environment, to get information about when the GC runs and what the impact is. Uncomment the animation & onCompleted hook to scroll automatically (and a lot faster). -- Robin Burchell ro...@crimson.no ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please add [ChangeLog] entries to your commits!
On Wed, May 31, 2017, at 02:50 PM, Oswald Buddenhagen wrote: > On Wed, May 31, 2017 at 02:38:53PM +0200, Robin Burchell wrote: > > To me, it's implicit that each release will ideally have improvements in > > terms of stability, so I think that there's less point in focusing on > > them, unless they are a major newsworthy item: something like "sorry we > > released 1.0.0 yesterday, but it turns out that feature foo was totally > > broken, have 1.0.1 today to fix that" would be newsworthy, but "we fixed > > a crash that has existed for the past 3 years" - less so, but that's my > > own personal view. > > > the trolltech policy was to always add a changelog entry when there was a > proper bug report. that seems reasonable, because there is (or at least > was) somebody waiting for that fix. Yes, however, if they are waiting for the fix, one would assume they are also subscribed to the bug tracker, and presumably watching the bug. They'll get a notification when the bug state changes (and a fix version is added). I should note that I'm not opposed to mentioning more stuff, I was just talking about my own editorial process when digging around after stuff missing changelog entries. -- Robin Burchell ro...@crimson.no ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please add [ChangeLog] entries to your commits!
My rule of thumb (when editing qtdeclarative's, for the last releases) has been to include things depending on the "size" of the release. Small (patch level) release? Include more bugs. Large (.0) release? Less focus on bugs, more focus on architectural changes, feature additions, etc. Any behavioral changes are always something that should be mentioned, of course. To me, it's implicit that each release will ideally have improvements in terms of stability, so I think that there's less point in focusing on them, unless they are a major newsworthy item: something like "sorry we released 1.0.0 yesterday, but it turns out that feature foo was totally broken, have 1.0.1 today to fix that" would be newsworthy, but "we fixed a crash that has existed for the past 3 years" - less so, but that's my own personal view. -- Robin Burchell ro...@crimson.no On Wed, May 31, 2017, at 02:30 PM, Mitch Curtis wrote: > > -Original Message- > > From: Kai Koehne > > Sent: Tuesday, 30 May 2017 9:31 AM > > To: Mitch Curtis ; development@qt-project.org > > Subject: RE: Please add [ChangeLog] entries to your commits! > > > > > > > > > -Original Message- > > > From: Mitch Curtis > > > Sent: Monday, May 29, 2017 3:27 PM > > > To: Kai Koehne ; development@qt-project.org > > > Subject: RE: Please add [ChangeLog] entries to your commits! > > > > > > > [...] > > > > Please be reminded that all changes that might be of interest to the > > > > end user should be part of the ChangeLog. So please, whenever > > > > reviewing a change, please check whether a [ChangeLog] entry is in > > order. > > > > > > Do we have a set of guidelines for what is considered interesting? > > > > I'd say anything that changes observable behavior of existing features, or > > new features. > > > > Should get a [ChangeLog] > > - new features > > - fixes for bugs in released versions of Qt > > > > Can be ignored: > > - fixes in tests > > - doc fixes > > - pure code cleanup > > - fixes for regressions introduced in not-yet-released commits > > > > Regards > > > > Kai > > > > (who considers starting a QUIP about this ...) > > There's also this one: > > https://wiki.qt.io/Commit_Policy > > That doesn't mention anything about change log entries for non-critical > bug fixes. > ___ > 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] Introducing discussion about QStringFormatter
On Tue, May 16, 2017, at 07:14 PM, Thiago Macieira wrote: > I'd prefer we kept the % syntax which we already have, but from the > discussion, it looks like it won't work. We need a syntax that has a > clear > open and close so that more options can be placed inside the placeholder. A potential additional advantage of using braces (which you include in your examples) is that they are familiar from use elsewhere: https://msdn.microsoft.com/en-us/library/txafckwd(v=vs.110).aspx. -- Robin Burchell ro...@crimson.no ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.9 beta4 available
Thanks for the report. I'll take a look at finishing this tonight. -- Robin Burchell ro...@crimson.no On Tue, May 16, 2017, at 06:43 PM, Тимур Артиков wrote: > Hi, > I believe, QTBUG-60547 should be fixed before the release. > ___ > 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] Introducing discussion about QStringFormatter
On Mon, May 15, 2017, at 02:49 PM, Mårten Nordheim wrote: > 3. What are its soft requirements? One very low priority item floating around on my wishlist would be formatting for QByteArray as well, though this is of course a bit of a task. But it would be useful for cases when you want to avoid the conversion penalty. -- Robin Burchell ro...@crimson.no ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Release plan moving forward
Hi, Responding to just the LTS news: I think that this is tentatively good news. I worry, though, on a releasing front whether it is realistic to consider supporting now two LTS branches, plus potentially 2-3 normal branches at the same time, especially since we don't yet have firm proof that we are able to even maintain a constant release cadence with the branches we have now. Can we get into a position where we can make a patch release every second month, say, so that security issues and high priority fixes don't have to wait half a year or more? The part of this that worries me is that I see 89 patches on just qtdeclarative/5.6 that aren't yet released, some of the highlights of the top of the commit log being: * Fix heap buffer overflow * Fixed assertion failure * Fix for dangling pointers (x 2) * Fix crash when ... ... and this was without looking for more than a minute or two. Right now, I honestly find it a bit difficult to recommend any given version -- right now, 5.6 is too old to offer a number of the things I would like to have, lags behind in performance, and has a number of unreleased fixes, but both 5.7 and 5.8 had their own share of problems in my opinion, and 5.9 isn't yet released. Just my (personal) $0.02... -- Robin Burchell ro...@crimson.no On Tue, May 9, 2017, at 03:35 PM, Lars Knoll wrote: > Hi everybody, > > I believe I have some good news to share with regards to our releases > moving forward. As you all know, we had quite some trouble getting patch > level releases out over the last year, going so far that we ended up not > doing patch level releases for 5.8. > > Fortunately, things are starting to look a lot better now. You might > already have noticed the rolling beta releases for 5.9, where we have > pushed updated betas out every 1-2 weeks. This shows that things are now > going a lot smoother and we are in a much better shape to create releases > in the future. > > Additionally, things have improved on the CI and releasing side. It's > nowadays a lot easier to get a qt5.git update through and create new > packages from a successful qt5.git integration. In summer, the CI system > will get a major HW upgrade giving it a much larger capacity, avoiding > capacity conflicts between CI, packaging and release testing.Together > with improvements to the Release Test Automation (RTA) which > automatically tests our packages we're actually getting into a good > position to do patch level releases with relatively little manual labor > from 5.9 and onwards. This means that we should now be in a position to > do much more frequent patch level releases from 5.9 onwards. > > Another thing that has happened is that The Qt Company has been seeing > lots of requests for a new LTS release, as Qt 5.6 is starting to feel > relatively old. I have also heard this request from a few places in the > wider Qt community. Because of the improvements to CI/packaging and > releasing, I believe we are now in a good position to make that happen. > > So we are now planning to make Qt 5.9 a LTS release. It's been 3 minor > releases since 5.6 and a lot of good things have happened in Qt, so this > should be very good news to those of our users that don't always want to > be on the bleeding edge but are looking for a stable version that's > supported for a long time. > > So once 5.9 is out, we are planning for rather frequent patch level > releases for that branch for the first 6-9 months. After that, we'll move > 5.9 into strict mode where we will also release a little less often, and > then have it in a very strict mode for the last year. See the draft QUIP > at https://codereview.qt-project.org/#/c/178906/45//ALL,unified for more > details on LTS branches. > > Of course, we will also continue to support 5.6 for the promised three > years. We are planning to release 5.6.3 in Summer, after which 5.6 will > move into the 'very strict' mode as defined in the branch policy QUIP. > > After 5.9, we'll be aiming at 5.10 in late autumn, 5.11 next spring. I > believe that we will be doing one more final LTS release on the Qt 5 > series, but most of the work after 5.11 will probably start to be aimed > on working towards Qt 6. > > Now let's not go into discussions what Qt 6 exactly will be in this > thread. I believe a lot of work towards defining what we're aiming at > with Qt 6 will be for the Contributor Summit in October. But the outline > above should give you good overview over the releases planned for the > next 18 months. > > Cheers, > Lars > ___ > 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] possible API freeze exception: would like to introduce QQuickItem::setAcceptTouchEvents() in 5.9
Hi, Let me start off by saying that I agree with you that this is a bad asymmetry, both for the end user, and for our own internal purposes -- which appears to be your primary motivator. I'm happy to see this addressed. On the other hand, this is a rather large change in behavior (whereby as I understand it, touch will stop working for custom items, and I know that there are a lot of them out there that take touch events) that will require code changes to adapt to. Not everyone can adapt their code -- some projects don't change after they release, some projects have other priorities, etc. In my opinion, requiring this kind of a change with only one minor release's notice is not something we should be doing given our focus on backwards compatibility. I'd be interested in hearing other opinions on list, so far I think I'm a tentative -1 to the idea. You mention that this is required due to optimizing the way that event delivery works internally in QQuickWindow -- have you considered restoring the old behavior there (despite it not being ideal, I think there's no disagreement there) possibly behind QT_MAJOR_VERSION guards, and switch it over to requiring registration for Qt 6? The reason that I ask is that I haven't ever seen what I would call a significant portion of time being taken up in the transversal part of event delivery -- it is of course non-zero, but the event handlers themselves (e.g. an onClicked handler in a MouseArea) are way, way more expensive which dwarf that cost in my experience... Robin -- Robin Burchell ro...@crimson.no On Tue, May 9, 2017, at 06:43 PM, Shawn Rutledge wrote: > This is of concern only to those who subclass QQuickItem in C++ and build > custom items that handle touch events. > > There is a pretty bad API asymmetry which it’s surprising that we didn’t > notice enough to try to correct it earlier. If you want to accept mouse > events while any mouse button is clicked or held down or released, you > call setAcceptedMouseButtons(). QQuickWindow won’t bother trying to > deliver those events if you haven’t done that. Likewise if you want to > handle all mouse movement events, pressed or not, you must call > setAcceptHoverEvents(true). Imagine a world in which these didn’t exist: > QQuickWindow would need to deliver every mouse movement to every Item. > It would be unmanageable, performance would be unacceptable. > > The docs say that QGraphicsItem::setAcceptTouchEvents(bool) has existed > since Qt 4.6. If you are handling touch events in a graphics view > application, it’s required to call this. > > Yet for some odd reason, QQuickItem::setAcceptTouchEvents(bool) was never > added. > > In some parts of the code, we make the assumption that if you have called > setAcceptedMouseButtons(), you might want the touch events too. In other > parts, we don’t check… so in the simplest case, if you create a custom > item that handles touch events and stick it into your scene, you might > get the touch events with no further ado, if no other item prevents it. > > It’s now become unmanageable to continue without adding this function. > QtQuick Controls 2 has an issue that if you have a Popup with a shadow > Item, you can drag via touch within the thin shadow area around the > popup, and the events will go through, and you’ll be able to drag the > sidebar open for example, even though there’s a translucent Item in > between which is supposed to both dim the rest of the application, and > catch all the events, to prevent interacting with other controls while > the Popup is open. (Modal behavior.) > > In 5.10 we hope to introduce PointerHandlers, a big improvement on > MouseArea, PinchArea and MultiPointTouchArea. This has been in the works > for a couple of years now. So on the wip/pointerhandler branch, we > already have the requirement that setAcceptTouchEvents() must be called > if a custom Item wants to accept touch events. I thought maybe I could > find a way to make it optional: to avoid changing behavior of existing > custom items out in the wild, we would need it to default to true. That > is, assume that every Item might handle touch events, give every item a > chance… because it was that way before. Or at least, go on assuming that > if it wants mouse events, maybe we should try to deliver touch events > too. But along with introducing PointerHandlers, we have tried to > optimize event delivery and make it more deterministic: before we start > delivery, we build up a vector of all items to which delivery will be > attempted, in the right order (reverse paint order). Then we build up a > vector of pairs of items and their filtering parents (those which have > called setFiltersChildMouseEvents - Flickable being the main example of > that). So when we are doing
Re: [Development] qdoc for C++ and QML
On Mon, Apr 24, 2017, at 05:08 PM, Shawn Rutledge wrote:
> > And if a C++ class has a corresponding QML type, should every member
> > function be included in the documentation for both? How will qdoc know that
> > a member function only applies to the C++ class or only to the QML type?
>
> Q_INVOKABLE for methods should cover it, I think, if qdoc already knows
> that the class is exposed to QML. Plus properties, of course. Usually a
> property setter is not invokable, but there can be exceptions.
This will involve some amount of work, though: for instance, qdoc would
need to be taught what to do with QQmlListProperty
("list" in output, e.g. QQmlListProperty ->
list).
There's also registered types are not necessarily intended to be
user-creatable, for instance, Item::layer, QQuickPen (Rectangle's border
type) which need to be handled "specially" in documentation.
And the good old subject of "variant" functions like Item::mapFromItem,
which will need special casing...
--
Robin Burchell
ro...@crimson.no
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Exposing QMimeDatabase to QML; QtQml.Utils?
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 to live in qtdeclarative, but that's not really much of a problem. That then gives us a good place to put additional types, too. I'd generally like to avoid a "Utils" import, since in my opinion they far too easily end up as a dumping ground (yes, yes, arguments about QtCore already sort of being one aside: at least then it's consistent). -- Robin Burchell ro...@crimson.no ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17
On Tue, Apr 11, 2017, at 06:16 PM, Stottlemyer, Brett (B.S.) wrote: > On Tuesday, April 11, 2017 11:14 AM, Simon Hausmann wrote: > > I think that what you are asking for is reasonable. I think the set of > > sha1s of qt5.git satisfy that requirement to the best of the project's > > ability. > > In this case I think they do not, based on all of the commits to the 5.8 > branches that aren't included in the v5.8.0 tag (last available). If > those were to be included in a 5.8.1 release, I would agree with you. qt5's 5.9 branch will contain a known-good configuration that built and passed tests for everything in it that the 5.9 branch of each individual repository won't offer you. I think you misunderstood this - I think that Simon was saying that the branches (not the tags) of qt5.git should be considered to be fairly stable for the people working on Qt itself (although obviously, qt5/dev will be more bleeding-edge than qt5/). > > For users of the product we can only point to tags. For developers all > > active branches should be good enough. I > > find it hard to imagine introducing a third "level" that is good enough for > > "some" but clearly not all. Unless there > > is a consensus to define and introduce this new way of identifying a > > development branch. > > Right, but doesn't that imply keeping 5.8 active until 5.9 is at least as > stable? How is it "a new way"? We have three targets: dev, the stable branch (more or less 5.9, since 5.8.1 is DOA) and the LTS (5.6). Adding an additional "level" there as you seem to be proposing with a "more-stable-than-stable" would be something I would consider new. -- Robin Burchell ro...@crimson.no ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QList
Hi Philippe,
On Mon, Mar 20, 2017, at 09:28 AM, Philippe wrote:
> >>Even our API guidelines stipulate that you should make common things easy
> >>and
> >>not-so-common things possible. Sharing is _not_ common and it need not be
> >>as
> >> easy as common tasks. I
>
> Maybe for you, but in my works, sharing _is_ common, convenient and safe.
> And overal usage of COW is one of the concept that makes Qt stand apart.
> From my POV, COW largely pay off its minimal performance cost.
> When performance is a high priority, _an uncommon case_, then using
> alternate containers is always possible and we don't need Qt for this.
I don't know your background, but let's assume you are primarily a user
of Qt (thus: an application developer of some kind), you may consider
performance to be unimportant, or important only in isolated areas of
your application.
Consider, however, the point of view from many of the people on this
list: as Qt uses itself in its own implementation, Qt must have
acceptable performance for end user applications to be able to have
acceptable performance at all - whether or not it is a priority to those
developers.
A few concrete examples of where data types matter a lot: signal
connections (involves storing a bunch of data), QObject (particularly
QObject::children, as already mentioned), event handling from the
operating system (or the application itself: the event posting mechanism
in QCoreApplication)...
> And when size matters, have this in mind:
>
> sizeof(std::vector) == 32
> sizeof(QVector) == 8
> sizeof(QList) == 8
To provide a more helpful response than Marc's: I assume that you are
aware that the Qt types just contain a pointer to a thing which contains
the actual data (unlike std::vector), right?
That is, QVector is actually (snipped from source):
template
class QVector
{
typedef QTypedArrayData Data;
Data *d;
}
Where QTypedArrayData is a QArrayData, which is:
struct Q_CORE_EXPORT QArrayData
{
QtPrivate::RefCount ref;
int size;
uint alloc : 31;
uint capacityReserved : 1;
qptrdiff offset;
}
If I'm adding it up right, this gives me a total cost of 32 bytes on my
system. Although the real cost is actually higher I'd guess, due to the
two being allocated in separate pieces (given that malloc usually has
some kind of book-keeping overhead).
Robin
--
Robin Burchell
ro...@crimson.no
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
On Mon, Jan 30, 2017, at 09:07 PM, Hamed Masafi wrote:
> My prefer option is form (3)
> We can add an enumeration to global space.
> var date = new Date;
> var out = date.toString(Qt.JalaliCalendar, "-MM-dd");
I would prefer to not modify standard APIs if we can avoid it (unless we
have a good reason to do so and such a change is pretty low risk).
Keeping close to the rest of the JS ecosystem means that skills learned
in one place are easily translated to another (meaning less
QJSEngine-specific knowledge and docs are required). In the particular
case of Date.prototype.toString(), it also means that should any future
specification start supporting additional arguments there, we aren't
going to open ourselves up to future unexpected problems.
> > Have you considered whether Date.prototype.toLocaleDateString could be
> > of use for this? See:
> >
> http://ecma-international.org/ecma-402/3.0/index.html#sup-date.prototype.tolocaledatestring
> Date.prototype.toLocaleDateString is used to converting date to a string
> bases on a Locale. we can use this function for accepting an CalendarType
> (CalendarType is a QEnum that contains list of calendar types like;
> gregorian, jalali, hindi or etc)
> date.toLocaleString(format);
> date.toLocaleString(CalendarType, format);
> date.toLocaleString(locale, format);
> date.toLocaleString(CalendarType, locale, format);
Right, if you look at the spec I linked you to, that's what it
specifies- converting a date to a string in a locale-specific way. They
don't use an enum, but a string to describe the calendar system (plus
some additional options to control the formatting result in an
additional optional parameter). I can admit the spec is a bit hard to
read. Here's a slightly less formal description, with some examples:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleDateString
If you want to see it in action, in a browser, try something like this
in a web browser JS console:
console.log(new Date().toLocaleDateString("ar-EG"))
I see:
٣٠/١/٢٠١٧
Which I hope is something useful/meaningful, I'm unfortunately not
familiar enough with that locale to tell. I've confirmed this to work in
recent releases of Safari, Firefox and Chrome on OS X. Outside of
browsers, YMMV. I didn't get Nodejs to respect the locale options, for
instance.
What we implement now is nothing close to this (in fact, we simply
ignore all arguments and return the argument using local formatting) -
my guess is that it is down to most of this being added after ES5.
> But there are some bugs related to this prototype, We have to solve that
> within this process.
As I said, as it stands, our implementation is currently not doing what
you need - it would need to be fleshed out to actually use the provided
arguments. However, I think that extending this seems to be a pretty
good match for the functionality you are wanting to add?
--
Robin Burchell
ro...@crimson.no
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
On Mon, Jan 30, 2017, at 08:59 AM, Hamed Masafi wrote: > I'm working on qml support of calendar system, > for porting this mechanism to qml we have two option: Have you considered whether Date.prototype.toLocaleDateString could be of use for this? See: http://ecma-international.org/ecma-402/3.0/index.html#sup-date.prototype.tolocaledatestring Disclaimer: I'm not intimately familiar with this API, but stumbled across it while looking into other possible alternatives for this problem. -- Robin Burchell ro...@crimson.no ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New library in qtbase
On Fri, Jan 13, 2017, at 11:58 PM, Samuel Gaist wrote: > Short summary, we have three possibilities: > 1) Own module (and current implementation) > 2) One “core" module and one GUI module to separate concerns for system > not requiring a GUI connection (Jake’s suggestion) > 3) Put everything in QtGui and implement the stuff in the QPA parts with > the implication that a QGuiApplication will be required. > > Can we come to an agreement about which one to implement ? My own vote would be tending towards 3 once the concept is nailed down. The existing change looks a little confused from a quick skim, e.g. you have a QCocoaNotifier which seems to be public API, but this is not the way I would expect to see this (at least, not in QtGui); I'd expect to see a "notification" class without any platform specifics, as far as possible, which then hooked into platform-specific code to "do its magic". As the "magic" would tend to be platform-specific, QPA seems to be the logical place to me; this then also allows a platform implementer to provide their own custom notification handling, should it be required – thinking more on the embedded or new platform front here, which is typically where QPA comes in anyway, where you may not necessarily have existing services or standards to follow. I can agree that it's "sad" to have to switch a QCoreApplication to a QGuiApplication once you need something in it, even if you don't have a GUI to present (though really, is this a common problem?), but aside from puritanical concerns, does that actually cause many concrete issues? So, considering that, and as it's a problem that already exists for non-graphical applications to have to interact with images/clipboard, for syntax highlighting and other text manipulation, etc, I don't think that adding another case to that problem is a death sentence. I think it's an extension of a minor inconvenience, but I don't think that arbitrary splitting of a feature or class is a good way to address that. It leads to a harder to use & understand API for little gain as I imagine it, though it is hard to say without a concrete suggestion on API to review. In the much longer term, on a separate tangent from your work, it might be interesting to think about rearranging things to properly address this problem if the gain is worth it, but even then, that starts to get tricky & requires a lot of care and research, especially when you realize that not everything you may want can be done without a windowing system: clipboard access, for instance, I'd say is almost certainly impossible to do without a windowing system on all platforms The same may apply to presenting notifications. Do you know the specific requirements of the APIs for, say, Windows/macOS/iOS/Android? If any of those (or future platforms) required the WS, then you'd essentially be left with a useless API on anything that did not have a QGuiApplication. I'd say that ultimately, requiring a QGuiApplication instance is a lesser evil than providing an API that won't work universally. -- Robin Burchell ro...@crimson.no ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Branch request: wip/itemviews in qtdeclarative
Hi, On Sun, Jan 15, 2017, at 12:24 PM, J-P Nurmi wrote: > There have been some discussions about rewriting the entire item-view > framework. I personally believe that would be best done in a major > release. :) I guess you're talking about the generic positioner-based view stuff here, but I wasn't thinking quite so ambitious. That is indeed one thing that is still bouncing around my head, but I suspect it will stay there for some time more :) More generally, I don't disagree that such a thing would be a major version change, or at least, done in a separate import. Anyway, I'll try write a longer mail about some of my thoughts on this stuff so they have a place in the public record, split off from this thread, as it is definitely a bit of a tangent. > +1 to having a branch for it (do you have a name in mind? wip/itemviews? > wip/tableview?) > > I was thinking wip/itemviews, but I don’t mind wip/tableview either. :) If your specific goal here is to provide enablers for tableview, then I'd go for wip/tableview. > Having more branches could be an option. All the tasks are somehow > connected to each other, though, so I was thinking that it might be > easiest to do it all in the same branch to avoid excessive conflicts and > merging between multiple WIP-branches. The last two, SortFilterProxyModel > and TreeModelAdaptor, would be the most logical ones to split to separate > branches, but on the other hand, they also need to be implemented so that > they play well with the rest. Yes, that's pretty much the sort of division I was thinking; and especially if Pierre-Yves can help with contributing on the SFPM part, perhaps that's a good candidate for doing "separately". I understand and agree with the need for unity, of course, but perhaps communication can help to some degree there. Anyway, it was just a suggestion. I'll leave the "how" to you people, you know the details of this work better than I :) > There’s so much to do that there is no way we could make all this happen > before the 5.9 feature freeze in two weeks. :) Text doesn't quite convey the emotion I meant that statement to evoke ;-); but I guess then you're thinking something like 5.11 (potentially earlier, if the planets align correctly)? Again, I'm not expecting promises here, just a rough idea would be a help so I can know when I need to start trying to pay closer attention to anything touching the area. Thanks again. -- Robin Burchell ro...@crimson.no ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Branch request: wip/itemviews in qtdeclarative
Hi, I (of course) wholeheartedly support work in the model/view area. It's something that could use some TLC, and I'm excited to see what you have cooking! I have a longer mental list of things that concern/bother me with current model/views (some of which we've already discussed), maybe I should try write that up in some form, if you think it might find it helpful, but as I don't know how much time I'll be able to dedicate to making this happen you may prefer me to hold my tongue :-) +1 to having a branch for it (do you have a name in mind? wip/itemviews? wip/tableview?) A thought, that came to mind while thinking about naming, though: there's a lot of features listed here, and I would expect that they will mature at different rates as some of them are more standalone, while others might require more extensive (and careful!) work on the existing, rather complicated code. As a result, I start to wonder whether a single branch for all of this makes sense, or whether it may make sense to do some smaller pieces either directly on dev, or to use more than one WIP so that it's easier to land stuff "when it's ready" rather than turning into a huge pile. I have great confidence in you, of course, just trying to make life easier along the way, so if you don't want to do this or feel that it wouldn't be helpful to you, feel free to ignore the idea :) (PS. I know you won't want to make hard promises, especially this early, but do you have any idea what kind of timeframe you have in mind for landing? Fingers crossed for "not 5.9"! ;-)) -- Robin Burchell ro...@crimson.no On Sat, Jan 14, 2017, at 01:37 PM, J-P Nurmi wrote: > Hi, > > I'd like to request a WIP branch for the Qt Quick item views. There are > plenty of items on the roadmap/wishlist: > > - refactor QQuickItemView > - add support for multiple delegate types (QTBUG-26681) > - add support for multi-selection > - add support for multiple columns > - implement TableView (QTBUG-51710) > - implement HeaderView > - implement SortFilterProxyModel > - productize TreeModelAdaptor (QTBUG-54390) > > Early feedback from the CI system would be invaluable. > > -- > J-P Nurmi > > ___ > 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] Proposal to adjust release candidate process
My (slightly delayed) $0.02: On releasing in general: I would agree that releases take too long, often, but I am of the belief that a good part of this is a mess of our own making. For instance, due to an end-user or project requiring a specific version or purely out of fear that the next release may be a long time away, I think we (collectively) often end up pushing changes to branches that might be less than ideally suited for the change in question. I think we should recognise that these pressures do exist, and consider ways we can work to mitigate them (things like: nightly or at least semi-"nightly" builds? working on pushing out patch releases more often? encouraging more of our consumers to apply patches that we already took in upstream and do their own builds? anything else?) It goes without saying that these are hard problems, but I think that working at the root causes is the only way to ultimately fix this. Moving away from a time-based schedule is just going to encourage the schedule to slip further, because now you have to wait [potentially forever] to get a change released rather than roughly [x months], which leads to even more pressure to get changes in an earlier version. Ultimately, I think we need to be better at saying "no" to changes that aren't explicitly necessary, especially on version branches (5.x.y) and in general taking care to evaluate how "done" something is before taking it in too. This is not an exact science, though, which makes it difficult to balance. Even if we truly are on the side of being too aggressive now - it may be perfectly possible that we could end up too conservative (and delaying fixes that our end users would like to see sooner), e.g. by implementing some kind of "blanket" restriction like "only P0 bugs get fixed in this branch" (not a suggestion I am making I will emphasise, just a note that we need to approach this carefully). To the proposal at hand: I think that we should not be afraid of releasing more release candidates. Some of them may well be broken, and while that's unfortunate, it's still certainly better that we release broken release candidates than a broken final release in the end. It may be the case that releasing more betas or using a different name may help get feedback earlier, but IMHO we have to accept to some extent that our end users are not us: they have limited time to build & test Qt in addition to their normal product/application work, and thus, overall, we should not expect too much of them. If we want more feedback, we need to work on making that testing process easier for them, rather than playing naming tricks, I think. On Tue, Dec 20, 2016, at 02:34 PM, Tuukka Turunen wrote: > > Hi, > > I think we have three major problems with our current release process > regarding the release candidate phase: > > 1. Process to make a RC that is as flawless as final causes > inefficiency as we only get full test coverage with the RC itself > > 2. We get full attention for testing a bit too late, many fixes are > still coming in close to the planned RC time causing instability > > 3. Current time between RC and final is planned to be 2 weeks, > which is very little in order to take in the feedback and fix things > > Therefore, I would like to propose the following: > > a. Consider "Release Candidate" to be a phase rather than an > individual delivery > > b. Create the first "RC1" almost immediately after release branch > (e.g. 5.9.0) is operational > > c. Criteria for the "RC1" is that no known P0 bugs exist (i.e. > there can be other issues that would not be acceptable in a final > release) > > d. During the "RC" phase P1 (and possible P0 of course) bugs and > documentation are fixed > > e. Public "RC" release is similar development release as Alpha and > Beta in that it starts a phase of work > > f.Multiple snapshots / new candidates are created during the "RC" > phase until one of them is considered the final release > > If desired, we could use some other name than "Release Candidate 1" for > the release that begins the last phase of the release. It could be called > "Beta 2" or "Technology preview", if so desired. Personally, I would call > it "Release Candidate 1". > > The difference to our current process is quite small. In essence it would > be about considering the "RC1" the beginning of the final releasing phase > (.0 branch), not something we do almost at the end of it. I believe that > lowering the quality criterial for "RC1" helps us in being more efficient > as it has been in practice impossible to really fulfill the current > process goal and have already the first RC as good as the final. > > In case of Qt 5.9 it would mean that we have the first "RC" out around > end of April, soon after the branching to 5.9.0 has been completed. We > then have 4 or so weeks to make all the needed amount of candidates / > snapshots until one of them will be released
Re: [Development] Using semicolons in JS (QML)
On Fri, Sep 30, 2016, at 11:00 PM, Kai Koehne wrote: > Interesting. Indeed, I wouldn't have thought it makes any measurable > difference. IIRC we had a qml mimizer once, I guess this is still around? tools/qmlmin in qtdeclarative > It's certainly not that important to me that I will spend a day on > writing a git hook that then nobody will use ;) But a lot of programmers > (including me) tend to care about code style consistency. So I was making > a suggestion that costs us nothing, but leads to a sllightly more > consistent documentation and examples in then end. In the same way as I > couldn't care less whether to use tabs or spaces, or what the right > indentation level is, as long as we stick to one. > > (And yeah, I also enjoy bikeshedding sometimes, be it at the coffee > machine or on a mailing list, even if not 'all Qt in bugs are fixed". And > honestly speaking I do not see an issue with this.) The problem is that these kinds of discussions do actually have a cost. They take time and energy to read and digest, and time to reply to (yes, it's voluntary, but occasionally something useful comes out of it, although usually not in any way related to the original topic - I'd count the above mention of qmlmin in this category for instance). The whole principle of bikeshedding as I'd understand it is that it's easy (and subjectively - somewhat fun) to do, but on the other hand doesn't really get all that much useful accomplished. And it may not be toxic every once in a while, but when you do it often enough, the noise starts to drown out the signal, and you can end up killing off a medium for any sort of reasonable conversations. It's a fine line to walk. As an idea of cost: aside from reading this thread, I spent something like 20 minutes mulling over this topic (and reading around on the internet for resources and opinions) while writing this reply for instance, time that I didn't even really realise I had spent until I was about to click "send" on this mail. Multiply that by every participant, and by every "low signal" thread, and you end up with potentially gargantuan amounts of time being spent on more or less irrelevant details, even if it is fun to do. ... To the topic at hand, I personally tend to omit semicolons unless they are clearly needed either to reduce ambiguity or for reasons of e.g. multiple statements on a single line (already something I prefer to outright avoid, however). I choose this for aesthetics, much like the "omit braces on single line if" rule (which is also, coincidentally, somewhat controversial and ignored from time to time) In the wider community (both QML and JS in general), this isn't a unified topic I'd say. You can find numerous advice going both ways, and I think it's fairly safe to say that there will always be dissenting voices everywhere, no matter what you choose. So for yourself, my advice would be: pick one that you like and stick with it. For Qt, while I would like to see one or the other picked and followed for consistency's sake, I'm not sure it would be a useful investment of your time to try to enforce a particular semicolon-style without tooling enforcement, as it seems like yet another Sisyphean task that will - at best - burn a lot of your time and energy and end up back in exactly the same situation, all for an effort which in practice has little real-world gain. I think that is why Shawn replied the way he did. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QML] Avoiding graphics flicker in Quick2
On Thu, Jul 28, 2016, at 02:37 PM, Denis Shienkov wrote: > So, my questions is: is there are any way to setup > Qt::WA_OpaquePaintEvent > and/or > Qt::WA_NoSystemBackground in Quck2? Or, maybe is it possible to use > another > tricks? Ah, the memories. Good times. Unfortunately for you, QQ2 is a very different beast. Rendering is done using OpenGL (unless you're using a different scenegraph backend, but that's probably not very likely right now) and then pushed to the windowing system of your choice using a QPA plugin via QWindow (how exactly this is done, of course, depends on your windowing system & the QPA plugin you are using). If you're seeing flickering, this means you have four possibilities, ranked in no real order: 1) OpenGL driver bug (the world is full of them..) 2) Application-side bug (make sure you don't have anything that could be flickering in your application). Using an overlay to debug item positions (QSG_VISUALIZE=overdraw) could be handy for trying to rule this out, as if it is specific to the application, you'd see which part of the application is flickering - and the overlay wouldn't be affected. 3) A problem or bug with the QPA plugin you're using (you mention embedded, so I'm going to guess you're using eglfs or something like that) 4) Relatedly, a problem or bug with the windowing system (particularly if you're doing something rather custom. If you're using e.g. OS X or some other mainstream setup though, this is less likely) -- Robin Burchell ro...@viroteck.net ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QtMultimedia] Still is supported, active?
On Thu, Jul 21, 2016, at 04:05 PM, Prav wrote: > Agree with you if this field was unchangeable once it was set (nobody > knows the future exactly ... ). > But this field is CHANGEBLE! So Fix Version SHOULD NOT BE KNOWN. It is > how maintainer see planning of it currently. Looking at my current world of choice: QtQuick (not QML, & not Controls) currently has - roughly - 385 open bugs. Three maintainers (Shawn & myself for QtQuick, Gunnar for scenegraph parts) - one of which works on Qt full time - plus a number of assorted contributors (in and outside the Qt Company) who all have their own priorities, wants, needs, and desires. The very nature of an open source project is that the resources that it has are unreliable. Outside of the core of people paid to work on it, there is no predictability about how much effort people are able to put in, let alone the completely unpredictable nature of software estimates, which is a widely known problem: I expect you've heard of it before so I won't go into it. And of the core of people paid to work on it, they have their priorities set based on a number of different variables: things they want to work on, things they are paid to work on, feature work vs bugs (and then: paid customers vs not, etc). On top of that, many bugs can't be estimated just by looking at the report. It requires knowledge of the code to find a fix, to understand possible implications and side-effects, testing, etc. I'm the first person to tell you that I don't have a clue how long a number of the bugs filed on QtQuick will take to fix right now, simply because I don't have an immediate understanding of what the problem actually is. I've rambled a bit here, but the point that I'm trying to make is: even if I *wanted* to, I couldn't try plan all 385 of those into something sensible, even if I was willing to spend all of the time that I spend looking at code/bugs/reviews on the meta-work that you're proposing (planning with all of those people) here. And that's just for one small part of Qt. Long story short, I don't see that happening. I don't think it's actually written down or formalised anywhere, but AFAIK, fix version tends to only be set on bugs that are actually fixed, to indicate which version the fix is going to land in, or on high priority blockers. -- Robin Burchell ro...@viroteck.net ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] commas in ctor-init-lists
And another +1 from me. -- Robin Burchell On Wed, Jun 1, 2016, at 09:23 PM, Andy Nichols wrote: > +1 to specify the coding style to be the "butt ugly" one. > > I'm one of those who has (not so secretly) been committing and approving > the offending style after all ;-) Though for the record I did not think > it mattered and was not covered by the style guideline you cited. > > Andy Nichols > > > On 01 Jun 2016, at 14:56, Simon Hausmann wrote: > > > > I'm in favorof changing our coding style to adopt the model you call "butt > > ugly" because I find it more appealing and I find that it makes diffs > > easier to read. > > > > Simon > ___ > 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] Nominating Frank Meerkoetter for Approver status
+1 :) On Fri, May 20, 2016, at 02:49 PM, Simon Hausmann wrote: > Hi, > > > I would like to nominate Frank for approver status. He has done a fair > bit of surgery in the QML engine and also seems to be active on > qtopcua/serialbus. > > > I appreciate his input on my patches and I trust him to responsibly > review. > > > > Simon > ___ > 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] qtfeedback and qtdocgallery: status?
On Tue, Mar 22, 2016, at 10:37 AM, Hausmann Simon wrote: > I'm not sure what you'd like me to answer at this point. I think that it > is possible to fix the > build of these modules, the CI system is in place for that. However it > requires a fair bit of > work (ask Robin about qtmessagingframework ;-). Assuming that the problems are *just* limited to license tests, and the tests in the package itself are in good shape, then it's probably not *too* hard. It'll still require playing a few rounds of CI ping-pong, and mass-staging changes (and headdesking when it fails again). I'll readily admit that it's an annoying process, but it was a manageable one. I'm not sure it's a productive use of time in the case of these "smaller"/pseudo-abandonware codebases, but it's certainly possible. For the practicalities of how to do it (Simon or someone, please correct me if I'm wrong here): * You'll want to edit sync.profile in the module and make sure they don't have "stale" dependencies (I see for instance that qtfeedback is pointing to refs/heads/stable, which is probably not a good idea at this point). I forget what the default is (no specific version listed) -- I believe it points to the origin branch (e.g. 5.6 branch of module -> 5.6 of dependency), or dev if there's not a direct match. * You can run the license test locally (from qtqa, see ./tests/prebuild/license/tst_licenses.pl) to check that it will be satisfied with a given module Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API/ABI changes report
On Fri, Feb 5, 2016, at 05:58 PM, Thiago Macieira wrote: > - QWindowSystemInterface: binary incompatible (class is \ingroup qpa, > but not >in a _qpa.h header, therefore it's public API) I don't agree with this. None of the QPA files have a _qpa.h extension (and haven't since 2012 -- see qtbase/037238022f3a91a5619709b2c7cf4b38cd4d294b), all of them clearly carry a warning "header", and all of them are put in include/qpa/ (see sync.profile), so they are not public. > * QtWaylandClient: > - events: false positive > - qt_extended_output: was public and should not have been removed. The > same >change also changed values of enums in other public classes >(like QWaylandCompositor). QtWaylandClient is not a public module. It's the platform plugin for Wayland. There isn't yet any API that is public (and not preview-level) in QtWayland. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Fwd: A simple analysis of apps using qtbase's private headers
On Fri, Jan 22, 2016, at 03:57 PM, PCMan wrote: > > The following three seems to be using at least qpa/qplatformtheme.h > > > > * KDE's frameworkintegration 5.16.0 > > * libqtxdg 1.3.0 > > * lxqt-qtplugin 0.10.0 > > > > Maybe for being able to create it's own theme? > > > > > Yes, but it's not only for themes. > Libqtxdg uses Qt private headers to woakround bugs in QIconTheme and > QIcon. > Lxqt-plugin uses Qt private qpa headers to support customized themes and > make some desktop settings work correctly. > Our LXQt file manager pcmanfm-qt will be using Qt private headers > qdnd_p.h > for workaround a regression bug of Qt 5.5 which breaks DND. > > Thanks! Do you happen to have bug IDs for the problems you're working around? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFD: plugins vs QStringLiterals
On Thu, Nov 5, 2015, at 06:13 PM, Oswald Buddenhagen wrote: > > Problem: performance impact, complexity of the atom/quark solution. > > > to lessen the performance impact, we could have a #define to control the > construction behavior of QSL at compile time. i'm not quite sure whether > to make that opt-in or opt-out (safety vs. performance). Is the problem only apparent inside of plugins? Do we have a way to detect whether someone is building plugin code at build time? (CONFIG += plugin for qmake, I guess?) If so, couldn't the behaviour of QStringLiteral differ for code inside of plugins, to that outside of them? Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing Markus Goetz
He already is (https://codereview.qt-project.org/#/admin/groups/12,members) - I guess it just never transferred to his other account. -- Robin Burchell ro...@viroteck.net On Tue, Oct 27, 2015, at 09:07 PM, Richard Moore wrote: > Not quite sure how Markus has managed not to be an approver. > > https://codereview.qt-project.org/#/q/owner:%22Markus+Goetz+(Woboq+GmbH)%22,n,z > > Rich. > ___ > 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] QML import versions
On Fri, Sep 18, 2015, at 08:15 PM, Nurmi J-P wrote:
> > I have some opposition to the idea because it entirely prevents us from
> > making changes if they are needed. An example of this came up just the
> > other day on IRC: Window{} has a number of major (or at least quite
> > irritating) flaws. A few of us were discussing whether/how it would be
> > possible to fix them in a QtQuick.Window 3.0, without breaking backwards
> > compatibility with older code, and without waiting for Qt 6.
>
> I think it’s a reasonable trade-off. Qt has lived with this restriction
> for quite long. :)
I think the reason that the imports system evolved in this direction was
because it was considered to be too limiting, and in the case of QML,
not necessary because of the capability to provide backwards
compatibility. You can't easily use Qt 4 and Qt 5 in the same codebase,
you could use QtQuick.Window 2 and QtQuick.Window 3 in the same
codebase, theoretically.
> If this is about the Item-based Window, would it make sense to give a
> different name? Panel? Popup? There’s also something related in the works
> in Qt Quick Controls 2.
Without wanting to go too far off on a tangent here:
I personally think that a concept that maps to a Window deserves to be
called a Window. Definitely not Panel or Popup at least as both of those
have different meanings in windowing, and neither of them match on
desktop platforms (sure, on platforms *without* windows, it does).
> >> How often do we release new major versions of QML modules? I don't see why
> >> QML
> >> modules couldn't follow the same practices than the rest of Qt follows.
> >
> > At present, we don't, but I think that's more down to the low amount of
> > activity happening outside the engine (at present) rather than the lack
> > of a _need_ to in some areas. Adopting this policy would mean there is
> > zero chance of these ever happening outside of major Qt releases, which
> > ties things to a much longer timeframe than "whenever we feel like
> > bumping the major version number".
> >
> > To me, that feels like a pretty big loss, even if I can see the appeal
> > we get in having consistency.
>
> Yeah, it’s a big limitation, but I’d vote for consistency for the sake of
> pleasant Qt Quick experience. It would also mean that we wouldn’t be able
> to release Qt Quick Controls 2.0 as is. We could release some parts of it
> under a different import, though.
> The QML version mess has been bothering me for a long time, and as I
> tried to illustrate in the initial email, it keeps getting worse every Qt
> release… :(
>
> > It also means we're bumping version
> > numbers for the sake of bumping version numbers in cases where there
> > really aren't any (or at least many) changes, in the case of e.g.
> > Particles, which is less of an issue, but still an issue.
>
> Is it any different to bumping the version of, say, QtXmlPatterns?
No, but one doesn't do something like "#include
" (unless one is using private API, in which
case it's all your fault, you're a horrible person, and you deserve
everything you get).
In other words, those version numbers are a lot more transparent to the
developer & end-user, unless they specifically rely on new
features/bugfixes. This is both a good thing (meaning that we have more
freedom to make changes), but a bad thing (due to potential
inconsistencies in how it's approached, and e.g. the massive smattering
of version numbers that we have now)
In QML, the version numbers are directly exposed to the developer. This
means that it would be a lot easier to, say, import QtQuick.Particles
5.7, and stop that application working on any prior version of Qt purely
because we decided to bump the import version, when there are no changes
in the module at all.
Maybe another solution towards this problem would be removing minor
versioning from our vocabulary altogether, and simply using a major
version number for imports:
import QtQuick 2
import QtQuick.Window 2
... and so on.
Functionality is always available (unversioned) in that import. Code
written for older versions will Just Work on newer versions (as it does
now). Code written for newer versions will Just Work on older versions,
unless it relies on newer features (as it does now, just with a
different error message: admittedly it might be a less descriptive one -
you'd get told that the type/property didn't exist, as opposed to module
version foobar is not available - but this is also the case with C++
usage now!).
Or am I missing some other value offered by minor version numbers?
We'd still have potential inconsistency with major version numbers, but
in my opinion, this is less of a problem, as at least in that case it's
usually a little more developer-evident when and why those change, and a
lot less frequent.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML import versions
On Fri, Sep 18, 2015, at 05:12 PM, Nurmi J-P wrote:
> - QtQml 2.2
> - QtQml.Models 2.3 (++)
> - QtQuick 2.6 (++)
> - QtQuick.Particles 2.0
> - QtQuick.Controls 1.5 (++)
> - QtQuick.Layouts 1.3 (++)
> - QtQuick.Dialogs 1.2
You missed QtQuick.Window I think :)
... which brings me to this:
> Is this something that would be possible to implement already in Qt 5, or
> is this Qt 6 material? Does someone strongly oppose the idea?
I have some opposition to the idea because it entirely prevents us from
making changes if they are needed. An example of this came up just the
other day on IRC: Window{} has a number of major (or at least quite
irritating) flaws. A few of us were discussing whether/how it would be
possible to fix them in a QtQuick.Window 3.0, without breaking backwards
compatibility with older code, and without waiting for Qt 6.
> How often do we release new major versions of QML modules? I don't see why QML
> modules couldn't follow the same practices than the rest of Qt follows.
At present, we don't, but I think that's more down to the low amount of
activity happening outside the engine (at present) rather than the lack
of a _need_ to in some areas. Adopting this policy would mean there is
zero chance of these ever happening outside of major Qt releases, which
ties things to a much longer timeframe than "whenever we feel like
bumping the major version number".
To me, that feels like a pretty big loss, even if I can see the appeal
we get in having consistency. It also means we're bumping version
numbers for the sake of bumping version numbers in cases where there
really aren't any (or at least many) changes, in the case of e.g.
Particles, which is less of an issue, but still an issue.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How to speed up QML for KDE5 without QML compiler
On Wed, Sep 16, 2015, at 06:03 AM, Leslie Zhai wrote:
> For a new PC, there is no sharp difference between QML and QWidget, but
> in a very very old PC, how old? about 7 years ago, QML is very slow! and
> it needs to close all effects for KDE5, even that when clicked, for
> example, calendar applet, it hang about 3+ seconds to showPopup.
This may be an obvious statement, but QML's capabilities (like that of
any other software) are dependent on the hardware you run it on. The
slower the CPU/GPU, the less you can accomplish in the same amount of
wallclock time.
The key to good performance when using QML is to do the minimal amount
possible at any given time. This means:
* Not having useless wrapper items, e.g: Item { OtherThing { } } <- this
is creating an item to do absolutely nothing
* Having bindings be as simple as possible
* Aggressively delay loading of items (using Loader, make sure to keep
them in seperate source files too to minimize the amount of time spent
parsing)
All of these points are multiplied depending on how often you do them,
e.g. in a ListView's delegate, you construct a lot of delegates, so any
inefficiencies there will be multiplied by however many delegates you
create.
Keep in mind that the things you use to write your application matters
quite a bit, too. For example, QtQuickControls' Button is a lot more
complicated & heavy than something like Rectangle + MouseArea (this
example may not hold as relevant with QtQuickControls 2, I haven't
looked into it much).
You can take a look at https://github.com/sletta/qmlbench to get a sense
for how expensive different parts of QML are (and how many of certain
items you can create per frame, and such).
In addition to all that: I agree with what Konstantin said. Before
trying to fix performance, you first need to understand what's wrong
with it, which involves profiling and understanding the problem "under
the hood".
> There is commercial QML compiler, a very small example tried to use it
> https://github.com/AOSC-Dev/AOSC-VersionHelper2
> But is it suitable for huge projects just like KDE5 if bought a
> commercial license? because not all KF5 components follow the Qt Quick
> Compiler`s resource.qrc way, so is it able to compile? for example,
> kickoff applet (the start menu of KDE5).
Probably not. IIRC the compiler ties you to a particular Qt version: you
must use the same Qt version at runtime as you compiled the sources
with. So unless it was used as part of the distribution's build setup
(for instance) it probably wouldn't work at all.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] Nominating Pier Luigi Fiorini (plfiorini) as an Approver
Hi, I would like to nominate plfiorini for Approver status. He's been quite helpful in working on Wayland (client & compositor) side things in conjunction with the Hawaii desktop (http://hawaiios.org/), and offering review on related patches. He also has knowledge of QPA thanks to this work, and best of all, is easy to get in touch with (and very friendly on) IRC :). His dashboard: https://codereview.qt-project.org/#/q/owner:%22Pier+Luigi+Fiorini+%253Cpierluigi.fiorini%2540gmail.com%253E%22,n,z And his reviews: https://codereview.qt-project.org/#/q/reviewer:%22Pier+Luigi+Fiorini+%253Cpierluigi.fiorini%2540gmail.com%253E%22,n,z Would anyone like to second? Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QtCS: Qt Quick Performance discussion
It seems that nobody took proper notes of the session (oops!) so I'm
sending the notes Gunnar and I wrote up in preparation for the session.
If anyone else has any recollections they'd like to add, please go ahead
and do so :)
=
# Performance!
* Why it's important
* What needs to be checked?
# Benchmarking
* Need support in qmlbench for measuring memory usage.
* For each set of creation benchmarks, we should run them a second
time collecting memory information.
* Once we have that, once graphed across a single test run, memory leaks
become easy to spot
* Graphed over time, regressions between commits become easy to spot
* Likewise for the number of items per frame
# Start up performance
We don't have good benchmarks for this, and creating them isn't trivial
to measure. Need a few generated examples, maybe.
# Memory usage
* Our memory usage is pretty bad in a lot of areas.
* Sharing data across processes (fork-booster)..
* Similar but better sharing achievable through qmlcompiler
* Benefits could be achieved by carefully allocating all write-once
expected-to-be-shared data contiguously
* Dropping CPU-side image data. We recently added QSG_TRANSIENT_IMAGES
to Qt Quick.
# Item creation performance
* We have pretty good benchmarks for this :)
* But we (constantly!) keep regressing
* This week's example: two seperate regressions in QQuickImageBase
(high DPI, and automatic transform)
* Image items per frame dropped from ~550/frame to 492/frame -- ~10%
regression
* Allocations for 5000 images increased by 41mb
* This is just one case - it's nobody's "fault", there's just nobody
taking care of it.
* Ideally need to do some work on automating runs of it (more on this
later)
* What is a good target?
* 1000 items / frame in qmlbench on a modern desktop / laptop (mbp
is one such)
* 100 items / frame on mobile and embedded
# Binding performance
I have no idea whether or not we have good benchmarks for this.
* Probably the creation ones cover the simple cases, but the more
advanced ones probably need seperate coverage.
* Ideally we also need to monitor the impact of things changing in
bindings (& multiple things changing at once, and so on?)
* Help creating benchmarks welcome!
# Graphics Performance:
Are we good here? I think we're close at least..
* Clipping has been brought up as an issue, 'simplerenderer' solves that
* Poor batching gives worse result, 'simplerenderer' solves that also,
but be mindful that simplerenderer also has ~2-3x worse performance
overall.
# Recommendations for working on QtQuick
* Avoid structures like QHash unless you are sure they are needed (they
have a heavy cost, and for <1k items or so, QVector, or std::vector, are
often a better choice)
* Avoid signal connections
* Virtuals instead might be a good choice
* If you really have to use them, use qmlobject_connect
* See prior art:
* qtdeclarative: 0de680c8e8fab36e386dca35e5008ffaa27e8ef6
* qtdeclarative: 7568922fa240e6e9440e9c6e93bf8ec00c06ec17
* Memory compactness:
* Don't introduce padding holes
* Don't increase the size of frequently allocated things (nodes,
items) "accidentally" without careful consideration
* Use a lazily-allocated ExtraData for things that aren't needed
often
* Consider your data types carefully - don't use a 64 bit int for an
"on/off" toggle
* Consider custom data structures & allocation (page allocation of the
shadow nodes was a big win)
# Specific Items?
* Rectangle implementation could be improved quite a bit (Gunnar?)
* Text node improvements (Eskil?)
* Hash of shadow nodes in the batched render is a large problem
* https://codereview.qt-project.org/#/c/97708/
* Delaying compilation (or whatever it is) on inline components until
they are used. Right now, these can have massive impacts on
performance/memory unless moved to external files. e.g. "Component {
Dialog { ... foo ... } }, only used when a button is pressed. It may
never be pressed.
* "Don't use" classes, like SpriteSequence :)
* In general, small items take up huge amounts.. Repeater { model: 500;
Rectangle { width: 100; height: 100; radius: 10 } } and you have 1Mb or
something :)
* QObject -> QQmlData / QQuickItem / QQuickItemPrivate etc all adds up
on individual items - but what can we do to fix that?
* The recent introduction of 'padding' in the box model might need a
second look to make sure it isn't increasing item sizes in common cases.
4 extra doubles is quite a large addition to item sizes.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] QtCS: Discussion about deprecating things
Notes I took on the deprecation session follow. If I missed anything, or misrepresented it in the notes, please chime in -- I was pretty tired when I was writing this :) (P.S. Did someone take notes on the QtQuick Performance discussion?) == Introduction * Qt 5 is now a few years old, a lot of things have happened * There’s always a limitation of resources, makes sense to focus on the important, future-looking things Compilers * C++ standard evolving is one additional motivation for change, meaning old compilers need to go (VS 2008, GCC 4.4) Platforms * Additionally, natural evolution of operating systems means that supporting older operating systems becomes an increasing burden (OS X, for instance, WEC 7, QNX 6.5) * Deprecation is hard: lots of use of “old"RHEL 6 still going on. At the same time, why is there a desire to use the newest Qt on these “old” platforms? * Qt 5.6 will deprecate: QNX 6.5 (QNX 6.6 OK) * Qt 5.6 will deprecate WEC 7, 2013 only. * Qt 5.6: Vista is on life support - patches welcome, it won’t be tested * Qt 5.6: OS X 10.8+ (previous 4 releases) * Qt 5.6: RHEL 6.6 with devpack * Android 2.3 support for 5.6 / “Qt LTS" * Developer devices are dying * Market share is dropping * Maybe not, discuss it more? Modules * Modules that are now undermaintained needs to have something done to them (QtWebKit, QtScript, QtQuick) * Printing support lacking from QQ2 * Non-OpenGL hardware needing QQ1 * For modules that are no longer to be developed (“deprecated”): * Remove them from the binary packages * Keep individuals source tarballs, but not qt-everywhere tarball * No guarentees given; patches welcome, bug reports may or may not be handled. * QtScript may be kept a bit longer, QtWebkit and QtQuick1 may be deprecated sooner. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qqmlengine/qqmlimport access
On Tue, Jun 2, 2015, at 11:44 PM, rpzrpz...@gmail.com wrote: > Another concern I have is the Render Thread issues VS Gui thread issues. Can you elaborate on this concern? The current description is impossible to address, which might explain the lack of response. -- Robin Burchell ro...@viroteck.net ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Future of Qt Quick 1 in Qt 5
On Sat, May 9, 2015, at 11:41 PM, Alan Alpert wrote: > > Can we declare the module in Deprecated state and keep bug compatibility > > with > > previous versions? If people are using it to transition from Qt 4, it should > > retain as much of Qt 4's behaviour as possible. That includes buggy > > behaviour > > that applications have most likely already worked around. > > > > We should fix only security issues, severe crashes and any issue resulting > > with > > loading both Qt Quick 1 and 2 into memory. > > That's what I thought the status was already, and it seems the right > level of support for the Qt 5 lifetime. It was certainly proposed to be that way by Lars in the thread "Deprecating modules with 5.5" ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Future of Qt Quick 1 in Qt 5
For the specific case of QtQuick1, I'd say that closing any issues that aren't applicable to QtQuick2 (or won't be done) with a useful message explaining the situation makes sense. It might also make sense to close reporting of new issues for that component. On Fri, May 8, 2015, at 06:10 PM, Hausmann Simon wrote: > Hi, > > Compilation wise I agree, it's low effort. But the situation is different > in Jira IMO. > > > Simon > > Original Message > From: Thiago Macieira > Sent: Friday, May 8, 2015 17:37 > To: development@qt-project.org > Subject: Re: [Development] Future of Qt Quick 1 in Qt 5 > > > On Friday 08 May 2015 14:39:38 Frederik Gladhorn wrote: > > Since KDE moved over the Plasma desktop to Qt Quick 2 (on which I'm writing > > this email), I feel confident that the time has come to move everyone over. > > For the no opengl acceleration use case, we provide the Qt Quick 2D Renderer > > as backend. > > (https://blog.qt.io/blog/2015/01/22/introducing-the-qt-quick-2d-renderer/) > > > > In short, is there any reason not to remove Qt Quick 1 from Qt 5.6? > > Do we need to do anything at all? How much effort is keeping Qt Quick 1 > compiling these days? We're not doing anything besides that, are we? > -- > 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Future of Qt Quick 1 in Qt 5
Hi, On Fri, May 8, 2015, at 02:39 PM, Frederik Gladhorn wrote: > One question is if there is any reason to maintain Qt Quick 1 in the > future. I know of some projects that are still out there using QtQuick1 (unfortunately). I think that moving to remove it now might be a little too quick, although I do think it's inevitable, and not a bad thing. Are there any specific concerns you have about maintenance? Is there anything that can be done to lessen that burden? > For the no opengl acceleration use case, we provide the Qt Quick 2D > Renderer as backend. > (https://blog.qt.io/blog/2015/01/22/introducing-the-qt-quick-2d-renderer/) This is true, but porting does require nonzero effort (especially in testing, as one can't be certain that everything works due to some subtle behaviour changes like MouseArea with opacity 0 still intercepting presses in QQ2). I think that giving some amount of time (5.7, 5.8?) after deprecation before removal might make sense. Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCore missing check for memory allocation
On Fri, Feb 27, 2015 at 9:20 AM, Oswald Buddenhagen
wrote:
>> The argument is that it implies runtime overhead. See Robin's email for
>> numbers. This is asking for making the code slower on the very devices where
>> it needs to run faster.
>>
> i don't trust this number. i don't know how qMalloc was implemented, but
> there is no way a simple forwarding wrapper would add 10% overhead to
> malloc (esp. in an optimized build).
> modern processors even have a specific optimization for call forwarding
> (or whatever it's called properly).
I went and dug out the test I had. I remembered the results correctly
(for OS X, for Linux the situation is somehow worse overall?). The
measurement is actually qMalloc + qFree vs malloc + free, so the
overhead is shared across two calls. See the attachments.
Here's the results for OS X 10.10 and Linux (Ubuntu 12.04). Hopefully
they don't get screwed in mail formatting :)
OS X 10.10Size msTotalIterations
qtMalloc 1 0,55 58 1048576
qtMalloc 100,56 60 1048576
qtMalloc 100 0,59 69 1048576
qtMalloc 1 0,00018 90 524288
qtMalloc 100 0,029 59 2048
qtMalloc 1000 0,34 86 256
regularMalloc 1 0,51 55 1048576
regularMalloc 100,51 58 1048576
regularMalloc 100 0,52 55 1048576
regularMalloc 1 0,00013 73 524288
regularMalloc 100 0,029 59 2048
regularMalloc 1000 0,4 97 256
Percentage change
-0,49
-0,49
-0,48
-0,99987
-0,971
-0,6
Linux Size msTotalIterations
qtMalloc 1 0,32 68 2097152
qtMalloc 100,32 68 2097152
qtMalloc 100 0,36 76 2097152
qtMalloc 1 0,00021 57 262144
qtMalloc 100 0,037 76 2048
qtMalloc 1000 0,47 61 128
regularMalloc 1 0,1 92 8388608
regularMalloc 100,11 95 8388608
regularMalloc 100 0,11 99 8388608
regularMalloc 1 0,11 97 8388608
regularMalloc 100 0,11 93 8388608
regularMalloc 1000 0,11 96 8388608
Percentage change
-0,9
-0,89
-0,89
-0,89
-0,89
-0,89
Looking at the instruction counts (Linux only, via callgrind) is
interesting, though, and I don't know how to explain this:
Linux Size Instruction reads
qtMalloc 1 376
qtMalloc 10376
qtMalloc 100 405
qtMalloc 1 2,320
qtMalloc 100 95,208
qtMalloc 1000 938,880
regularMalloc 1 179
regularMalloc 10179
regularMalloc 100 179
regularMalloc 1 179
regularMalloc 100 179
regularMalloc 1000 179
#include
#include
#include
#include
class MallocBenchmark : public QObject
{
Q_OBJECT
private slots:
void qtMalloc();
void qtMalloc_data();
void regularMalloc();
void regularMalloc_data();
};
void MallocBenchmark::qtMalloc_data()
{
QTest::addColumn("size");
QTest::newRow("1") << 1;
QTest::newRow("10") << 1;
QTest::newRow("100") << 100;
QTest::newRow("1") << 1;
QTest::newRow("100") << 100;
QTest::newRow("1000") << 1000;
}
void MallocBenchmark::qtMalloc()
{
QFETCH(int, size);
QBENCHMARK {
void *p = ::qMalloc(size);
memset(p, rand(), size);
::qFree(p);
}
}
void MallocBenchmark::regularMalloc_data()
{
qtMalloc_data();
}
void MallocBenchmark::regularMalloc()
{
QFETCH(int, size);
QBENCHMARK {
void *p = malloc(size);
memset(p, rand(), size);
free(p);
}
}
QTEST_MAIN(MallocBenchmark)
#include "main.moc"
malloccheck.pro
Description: Binary data
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCore missing check for memory allocation
On Wed, Feb 25, 2015 at 10:17 PM, Konstantin Ritt wrote: > Maybe a bit off-topic: can we introduce our own (probably customizable) > memory allocation API, something like Apple's CFAllocator [1], and move Qt > internals to use it instead of malloc/realloc/free (and maybe instead of > some new/delete-s, based on some policies)? Before you go all-out on something like that, please make sure you benchmark and consider the cost. Memory allocation is already something that is quite slow, and yet, done a lot - all over the place (too much, even, but that's a rant for another day). IIRC when I pushed for deprecating qMalloc/qFree in the past, I measured (on Linux) a ~10% time penalty for small allocations, lowering to 0-5% as allocation size increased. That's a way too hefty penalty to ask people to pay on something so universal - and that was literally just a function wrapping malloc, no "debugging or monitoring". Furthermore, aside from performance, I don't think that reintroducing a wrapper is a smart way to do it for much the same reason why I wanted to get rid of them in the first place: they weren't universally used, leading some people to get the false impression that intercepting qMalloc would give them the kind of diagnostic information you're talking about. If you want to debug or monitor, then I'd suggest doing it a lot more centrally with something dedicated to that task, see e.g. heaptrack (http://milianw.de/tag/heaptrack). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] CI failing due to tst_licenses.pl test
Hi, Since nobody else has replied to this yet, my understanding of what happened with license checks is roughly as follows. I was not involved, so YMMV - this is all just gained from observation of what's happened - someone else please correct me if I'm wrong. a) someone, somewhere, made a decision to change license headers (I don't know where this discussion happened, at least I don't recall this happening on-list) b) tst_licenses (or was it all qtqa tests?) were disabled, presumably to allow a) to happen c) license headers were changed, without checking that they actually passed the test d) license checks were reenabled, making everything fail e) 5.5 got branched without this having been fixed f) licenses were changed (again) in dev, fixing the tests g) finally, dev was merged back down to 5.5 to fix the failures there By my count, there's a few failures here: * it would have been nice to have a "heads up" about the headers change. * disabling license checks to update headers seems to have been a pretty terrible idea * branching 5.5 before fixing that seemed to create a lot of additional confusion, especially without any real communication about what was going on with all of these issues The situation is - I think - almost back to normal, bar some modules that aren't part of releases. Robin On Mon, Feb 23, 2015 at 3:17 AM, Aaron McCarthy wrote: > Hi, > > Changing are failing to integrated because the license header used by the > tst_licenses.pl test does not match the existing headers in the source. Errors > like the following are seen: > >> # Failed test 'Mismatch in license text in > examples/qml/dynamicscene/content/Button.qml >> # Actual: * Neither the name of The Qt Company Ltd and its > Subsidiary(-ies) nor the >> # Expected: * Neither the name of The Qt Company Ltd nor the names of > its' # at >> /work/build/_qtqa_latest/tests/prebuild/license/tst_licenses.pl line 389. > > Cheers, > > -- > Aaron McCarthy > ___ > 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] Item creation time in QML
On Fri, Feb 13, 2015 at 12:41 AM, Andrew den Exter wrote: > First of all it's accumulative, any QML application is going to end up > constructing many items, hundreds, thousands even and costs, even small ones > add up. Secondly yes constructing and interacting with QObjects can be > expensive and there are ways to mitigate some of those costs. Thirdly > parsing, compiling, instantiating, and executing bindings is all extra work > that comes at a cost. I would also add that memory allocation is usually a problematic thing. This can be something as "simple" as using the wrong type of container as was discussed on the list recently. See ba690fb73864915b4a35bbec5b7dc134ff1dafd0 in qtdeclarative for one recent example of just how bad this can get. > Robin's singled out the Text items so lets have a look at those. A good > amount of work has already been put into these items though so TextEdit > aside there's not a lot of low hanging fruit. Looking into a time profile on Gunnar's Text benchmark a little, here's some intriguing findings so far: * I started out with a split of 33% - 66% render thread vs gui thread split. This is quite high, the render thread is normally a lot less busy. * Profiling showed a lot of "hot path" memory allocation on various small spots, e.g. https://codereview.qt-project.org/#/c/106259/ https://codereview.qt-project.org/#/c/106260/ https://codereview.qt-project.org/#/c/106261/ https://codereview.qt-project.org/#/c/106262/ * Profiling also shows that (once again) QHash and QSet are looking likely to be problematic in a few places. I've already gotten rid of a few of them in a WIP patch I haven't pushed yet. On the GUI thread: * 11% in QQmlObjectCreator::create * 1% in QQuickText::QQuickText * 6.5% in QQmlObjectCreator::setupBindings * 52% in QQmlObjectCreator::finalize * 47% on QQuickText::componentComplete * 35% in QTextLine::layout_helper * 30% in QTextEngine::shapeText * 28% in QTextEngine::shapeTextWithHarfbuzzNG * 26% in hb_shape_full * 5% in QQmlBinding::update On the render thread: * 15% in QSGRenderThread::sync * 14% in QQuickWindowPrivate::updateDirtyNodes * 8.5% in QQuickWindowPrivate::updateDirtyNode * 7% in QQuickText::updatePaintNode * 4% in QQuickTextNodeEngine::addToSceneGraph * 1% in QSGNode::appendChildNode * 1% in QSGBatchRenderer::Renderer::nodeChanged * 5.2% in ~QSGTransformNode * 3.6% in ~QQuickTextNode * 1.5% in QSGNode::removeChildNode * 1.5% in QSGBatchRenderer::Renderer::nodeChanged * 3.7% in QQuickWindowPrivate::renderSceneGraph So we have total costs of around 35% for text engine costs, 11.5% for binding costs, and the actual Text construction isn't much to speak about. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Item creation time in QML
On Wed, Feb 11, 2015 at 2:49 PM, Rutledge Shawn wrote: >> Being able to do 500+items rectangles in one frame is decent, but not >> awesome. Being able todo 130 text items in one frame, is less than ideal, >> given that we often use several text items per cell in a list or table. Text >> is probably the most important UI element we have. Being able to do 10 >> buttons is, well, unfortunate :) If we look at Button, we see that it is a >> fairly complex QML beast. Hierarchy is >> >> Button -> BasicButton -> Control -> FocusScope >> >> and there are quite a bit of stuff on every level, including the dynamic >> style handling which will in turn create a StyleItem. >> >> And keep in mind that even though this isn’t the most high-end mac, it is >> sitll a pretty decent computer, Qt is supposed to run on much worse hardware >> than this. >> >> — >> >> There have been a few changes going into 5.5 which make these numbers better >> than 5.4, but I still think we got quite a ways to go. > > That’s very interesting. > > Do you think it was ever better in past versions? I'm glad you asked: http://rburchell.com/QtQuickPerformance.pdf > What do you think we should do about it? Mainly focus on trying to create > fewer objects, or is there still a lot of headroom for making the creation > more efficient? Is creation expensive because of constructor code, making > too many signal/slot connections, or something else? I think there's plenty that can be done, because it *used* to be better. We should aim for matching the performance we used to have at the very least, ideally, for exceeding that. I'd say that one very particular case that needs attention is text performance. It's pretty bad. As for why, specifically, it's slow, I did some profiling in the past, but I don't have those results now. I plan to spend some time on that, maybe on the weekend, and send some more information once that's done. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtDeclarative CI failures on Windows
Thanks. That's what I assumed, but it's nice to have it confirmed. On Tue, Feb 10, 2015 at 9:24 PM, Hausmann Simon wrote: > Hi, > > Friedemann made a fix: https://codereview.qt-project.org/#/c/105750/ > > Simon > > Original Message > From: Robin Burchell > Sent: Tuesday, February 10, 2015 21:15 > To: development@qt-project.org > Subject: [Development] QtDeclarative CI failures on Windows > > > Can someone with Windows please take a look at unblocking > qtdeclarative/dev, or give an update if you know what's going on? It's > been failing since February 5[1](!). > > The failures are consistent. See some examples: [2][3][4]. > > In light of it being just under a week since the last successful > integration, I think it might make sense to extend the branching > period a bit longer for qtdeclarative at least. I have a few changes I > would like to see in before branching (some of which require updates, > I've admittedly been a bit slack on that): > > https://codereview.qt-project.org/97273 (needs update, I was waiting > to add QQuickParticleData and QQuickTextPrivate to it, below, but they > have not yet integrated) > https://codereview.qt-project.org/103862 (minimal risk) > https://codereview.qt-project.org/105663 (improves size for the common > case of Text) > https://codereview.qt-project.org/105665 (improves size for the common > case of Text) > > Everything else on my dash I'm happy to wait for 5.6. > > Robin > > [1]: > http://lists.qt-project.org/pipermail/ci-reports/2015-February/035268.html > [2]: > http://lists.qt-project.org/pipermail/ci-reports/2015-February/035567.html > [3]: > http://lists.qt-project.org/pipermail/ci-reports/2015-February/035559.html > [4]: > http://lists.qt-project.org/pipermail/ci-reports/2015-February/035579.html > ___ > 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
[Development] QtDeclarative CI failures on Windows
Can someone with Windows please take a look at unblocking qtdeclarative/dev, or give an update if you know what's going on? It's been failing since February 5[1](!). The failures are consistent. See some examples: [2][3][4]. In light of it being just under a week since the last successful integration, I think it might make sense to extend the branching period a bit longer for qtdeclarative at least. I have a few changes I would like to see in before branching (some of which require updates, I've admittedly been a bit slack on that): https://codereview.qt-project.org/97273 (needs update, I was waiting to add QQuickParticleData and QQuickTextPrivate to it, below, but they have not yet integrated) https://codereview.qt-project.org/103862 (minimal risk) https://codereview.qt-project.org/105663 (improves size for the common case of Text) https://codereview.qt-project.org/105665 (improves size for the common case of Text) Everything else on my dash I'm happy to wait for 5.6. Robin [1]: http://lists.qt-project.org/pipermail/ci-reports/2015-February/035268.html [2]: http://lists.qt-project.org/pipermail/ci-reports/2015-February/035567.html [3]: http://lists.qt-project.org/pipermail/ci-reports/2015-February/035559.html [4]: http://lists.qt-project.org/pipermail/ci-reports/2015-February/035579.html ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Requesting a break in behavior in QML Text element
Hi,
Rationale: Text.AutoFormat is a terrible misfeature in almost every
case out there.
Design implications: In many cases in applications, a format is not
specified, with the assumption that only plain text will ever be
displayed because that is all it is ever tested with. In actuality,
this is not the case: providing rich text will allow rich text to be
displayed. This can break the appearance of the application (for
instance, bolding a list item becomes possible when this may not be
wanted as a design constraint)
Security implications: There are two security implications here.
Firstly, there is an issue when used in conjunction with another
feature of QML: automatic loading of resources[1]. This can allow for
resource usage in unexpected conditions (say, when on a mobile
device), allow some degree of tracking of user behavior ("did this
user get my message yet? better embed a 1x1 transparent gif in the
image and find out"), etc. In the case of a bug in Qt's image format
plugins or rich text handling, it could also escalate from being
"annoying" to actually allowing attacks to take place.
Performance implication: In addition to the security and design
implications, it's also undesirable from another perspective: that of
performance. Automatic detection and fallback implies a certain amount
of resources.
API design-wise, this is also not great. It's unexpected: you create a
text element, you don't have any idea what you're going to get. If you
turn on automatic detection or rich text, you explicitly have to make
the choice to get either of those behaviors.
It is worth noting that this behavior is present in the widget world
(QLabel and friends), but slightly less problematic there (in that
external loading is not possible). I have seen this be a problem quite
a large number of times there, too, as I am sure many developers
have[2], but changing the behavior of something that has existed for
so much longer is something that I consider to not be well received,
especially given the wide amount of codebase out there.
tl;dr: I'd like to request a behavior break in QML's Text element. I
would like to change the default value of Text::textFormat from
Text.AutoText to Text.PlainText.
Ideally, we could also provide tooling changes to help cover the
migration, by warning in QQuickTextItem::setText if HTML was
discovered and an explicit format had not been set, or perhaps in
other custom tooling aids.
Seperately, we may want to look at a restriction on the loading of
remote resources in Text. I can understand allowing remote URIs in
Image, but Text seems like an unexpected behavior to me.
BR,
Robin
(thanks go to Rich Moore for helping to proofread this proposal)
[1]: QML example showing loading of an image from a remote source
inside a text string.
import QtQuick 2.0
Item {
width: 500
height: width
Text {
text: ""
}
}
[2]:
http://blog.qt.digia.com/blog/2011/10/04/security-considerations-regarding-qlabel-and-friends/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtWayland windows decoration on the Raspberry Pi
On Mon, Dec 15, 2014 at 12:37 PM, Massimo Callegari wrote: > So, my application runs on Maynard using "-platform wayland" but all the > windows are not decorated. So basically I have the same result as if I run > it on eglfs. See: https://codereview.qt-project.org/#/c/93128/ > So, my questions to the QtWayland guys are: > > - have you people already done some tests on Weston/Maynard on the Raspberry > Pi ? I haven't personally touched the Pi since I fried mine a year or more ago. I don't know of many other people working on there, either, but perhaps there's someone lurking that I don't know of. > - how could I check which backend the QtWayland QPA is loading ? The easiest way is probably to just make sure that you have the right client buffer integration plugin available. But I'm not sure if the regular one even works on the pi - at least I presume there's a reason there's a custom integration made available of it. > - is there any chance to have windows decorations (bradient ?) on the RPi or > is it something still being evaluated/developed ? If someone does the work for it, possibly. Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Platform maintainers
On Fri, Sep 26, 2014 at 5:17 PM, Nichols Andy wrote: > My suggestions for replacement would be either Giulio Camuffo who as been > main driver for the QtWayland project this year, or Jorgen Lind who was the > previous QtWayland maintainer and who still has a deep interest in the > project. +1 to either, but I have to say I'd lean towards a +2 for Giulio simply because he is more focused on Wayland, whereas Jørgen has many other things on his plate already (from what I've seen going around in Gerrit). Giulio has an extensive knowledge base in the area, and has proven a real asset in the time he's been working actively on QtWayland & QtCompositor. (No offence intended to Jørgen if my understanding of the situation is incorrect!) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Requesting removal of qtjsondb
On Fri, Sep 19, 2014 at 10:48 PM, Jeremy wrote: > It’s the repo hosted on qt-project.org and clones such as qt.gitorious.org > that I’m wondering about. Leaving qtjsondb at its current URL is not what I > would expect for something that is not part of the Qt 5 bundle. Do we start a > qt-abandoned tree? qtplayground is too optimistic. We have plenty of other code in similar circumstances (qtwayland pre-5.4, qtpim, ...) that aren't released but may be Some Day (or might not, if nobody cares about them). I don't think the URL really says all that much about something necessarily, and moving things around is a hassle (technically and socially) I'd just leave it ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Linux release binaries too old
Thanks for starting the thread, Alex. I still hadn't had time to really do my homework on my side of this problem, apart from talking to you :-) On Mon, Aug 25, 2014 at 5:25 PM, Blasche Alexander wrote: > It is my understanding that the current Linux release binary packages are > built on Ubuntu 11.10 machines. This is very ancient. In fact for Bluetooth > Low Energy (new feature in 5.4) this is too ancient. This also looks to be a problem for QtWayland binary packages, though I'm not sure I'd say that those are urgent enough to hold releasing up with. I'm not an expert with Ubuntu anymore (haven't used it for a number of years) but it looks like the libwayland available in 11.10 is ancient. QtWayland needs at least 1.2.0 (which is already a pretty conservative requirement). If it were up to me, I'd just leave it as-is, and say that the QtWayland release is source-only, for 5.4 at least. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Looking for a way to batch-upload independent changes to Gerrit
On Mon, Aug 18, 2014 at 7:57 PM, Allan Sandfeld Jensen wrote: > Is it a problem that they have fake dependencies listed in gerrit? I often > upload lists of patches like that, and land them out of order as they get > reviewed. It appears to pose no particular problem, except that it can look a > bit odd. Me too, if I'm lazy. It can confuse some reviewers (small problem), but the annoyance I've faced is that rebasing will bump all changes after the commit you actually change. Having multiple source branches avoids that. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Looking for a way to batch-upload independent changes to Gerrit
Hi Marc, It doesn't specifically do what you want, I think, but you might want to take a look at Android's repo tool: https://source.android.com/source/developing.html https://source.android.com/source/using-repo.html I've been using it to interact with Qt's Gerrit for quite a while now and am pretty happy with it (not everything is perfect, I'd like an "amalgamated" branch which was automatically updated from all my topic branches) but it works OK. Creation of topic branches is easy enough that I don't tend to mind doing them. I have a manifest at https://github.com/rburchell/qt-manifest (some wrangling will likely be required, I'm pretty much the only person using it at the moment I think). Hope this helps, Robin On Mon, Aug 18, 2014 at 3:23 PM, Marc Mutz wrote: > Hi all, > > I have several times come across the problem that I hack away and end up with > a chain of 20 or so commits, most of which are completely independent of each > other. If I push gerrit HEAD:refs/for/X, I can upload all of them in one go, > but they will be shown in the Gerrit UI as depending on each other. > > If I had the right to upload merges, even for just deleting them afterwards, I > would take all of these changes, rebase them onto gerrit/X, and do one octopus > merge over the lot of them, then push gerrit that_merge:refs/for/X and abandon > the change that corresponds to that_merge as an artifact. > > Other than writing a script to iterate over the parents of that_merge and push > gerrit parent:refs/for/X each one separately, which takes a long time because > of the SSH key negotiation, is there a way to do this in one git push command? > > Thanks, > Marc > > -- > Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin > > Marc Mutz | Senior 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 > ___ > 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] Wayland app_id
On Thu, Aug 14, 2014 at 9:52 PM, Pier Luigi wrote: >>> Now the question is: how can Qt applications set this app_id? >>> >>> Since app_id should be the same for all xdg surfaces I would propose >>> adding an applicationIdentifier property to QGuiApplication. >> >> Why do they have to? Just like WM_CLASS is an internal detail to the >> xcb plugin, I'd imagine that this would be an internal detail in >> QtWayland. > > At a first and quick glance qxcb sets it to > QCoreApplication::applicationName() which is way too verbose and not > the desktop entry name, or argv[0] base name which is basically what I > did with qtwayland but this doesn't feel right. > This doesn't feel right because the desktop entry name might be > different than the executable name hence my desire for something that > would allow the application to specify it. It kind of has to be enough, though, because you won't always get launched from a desktop file (there's D-Bus activation, or plain old exec, shell launching, etc). And what if the property just isn't set? I don't think a new property is a good idea, both because it seems incredibly limited in the scope of its usefulness (I don't see how it's applicable in a cross platform way, and I don't even know how you'd begin to document something this limited in usefulness) and because they simply won't set it (partly due to it being a new property, and partly because of the previous problem). But yeah, you're running into the age old chestnut of a problem that has haunted the fine folks at Jolla for a while: how to associate a desktop file with a process. We never really came up with a good answer there (at least not a generic one.) Maybe someone else has a smart idea, let's see. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Wayland app_id
On Thu, Aug 14, 2014 at 8:15 PM, Pier Luigi wrote: > This used to be the class in wl_shell_surface and I know the concept > exists on X11 as well (WMCLASS if I recall). WM_CLASS I think, but don't quote me, it's been a long, long time since I've looked into anything X11 related. ... a quick grep+read on qtbase seems to support this theory. > Now the question is: how can Qt applications set this app_id? > > Since app_id should be the same for all xdg surfaces I would propose > adding an applicationIdentifier property to QGuiApplication. Why do they have to? Just like WM_CLASS is an internal detail to the xcb plugin, I'd imagine that this would be an internal detail in QtWayland. BR, Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357
On Fri, Jul 11, 2014 at 11:13 AM, Hunger Tobias wrote: > I see why you would want journal data in your output, but I do see a > problems making that work for remote debugging/running. Even sailfish is > apparently forcing output to stderr when starting applications on-device > via Qt Creator. Don't let our existing solution limit you. There may be better solutions, we were time-constrained, and now resource-constrained (i.e. we have to pick and choose what we put effort into..) so we haven't looked into changing this any more, as far as I know. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357
On Wed, Jul 9, 2014 at 11:43 PM, Thiago Macieira wrote: > == Problematic == > Qt 5.3 and dev are currently able to send the output of qDebug, qWarning and > the rest of the logging framework to somewhere other than stderr. That's done > on Windows, BlackBerry, Android, and on Linux systems with journald. > Additionally, there's a pending patch for OS X to use the Apple System Log [5] > and I had a patch for MeeGo that made it go to the standard Unix syslog. > > We have a problem of wanting a cake and eating it too: > > 1) we want applications to send their logging to the system log where > possible, which usually logs more information like the log level, time, > application name and PID. Such a system is searchable and may allow us to add > additional information, like the category (for category logging), file name, > line number, function context, etc. > > 2) we also want to see the output when we run applications from the terminal > or capture the output with QProcess. > > The absence of output causes bug reports like [2] and [4]. Let me explain why I implemented the journald-logging support the way I did. Some background: on Sailfish, we launch all major system services (and UI) through systemd services (& user session for the UI parts). Those processes may then choose to execute processes of their own (the most prominent example being the UI environment which will launch applications in response to user input). With a default setup, systemd will log everything sent to stderr of systems-launched processes, and child-launched processes will have their stderr output attributed to the systemd service which launched them. I implemented support for this because the situation as described above is frankly unusable for us. Output was wrongly attributed to parent processes, which made tracking down the real source of a problem interesting at times. The other stuff we got (like categorized warnings, a globally usable log - to view whole system effects of things - etc, are just icing on the cake) I wanted to send all non-interactive logging output to systemd. Interactive output (such as running things by hand) should go to the console, on the assumption that there is someone actively monitoring the other end (hence the console check). I added the environment variable workaround after this very problem (QtCreator output) came in in Sailfish. We then adapted our Creator setup to set the environment variable: https://github.com/sailfish-sdk/sailfish-qtcreator/commit/cc880444b433bc3a86305601c1471ffd292c737e https://github.com/sailfish-sdk/sailfish-qtcreator/commit/34c8fcf9d8f749796a7f43fb52997c43f286c480 > == Solutions == > === Heuristically determine at runtime where to send the log === > Which is what I'm trying to do above. > > On Windows, we check whether we have a console and whether stderr is not NUL. > > On Unix, I have implemented the same checks. > > We can also use the fact of whether the main application is in debug mode or > not. I think this is the nicest option, as said above. I may be biased, in that I wrote the initial implementation for journal logging :-) That having been said, as with all heuristics, I think we should strive to make them as simple as possible, otherwise they're going to become non-obvious. My vote would be to just have the correct environment variable injected. It's our knob to customize this behavior already. It's our knob, and we're also responsible for the behavior of it, so why not make use of it? I understand the knee-jerk reaction to modify application \environment, but we're talking about Qt changing Qt's behavior through a public environment variable here, not rocket science, KILL_ALL_HUMANS, LD_PRELOAD, or anything scary . BR, Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enginio build artifacts and naming conventions
On Wed, May 28, 2014 at 11:19 PM, Mathias Hasselmann wrote: > As a side note: A similar problem exists for the messaging framework > libraries (QMF). Its library names are: There's renames for that planned, but not yet executed. See the archives for my original mail on the subject. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about Qt's future
Hi, On 23 Apr 2014, at 14:14, cincirin wrote: Sorry for re-open this topic, but as someone else already pointed out, what do you think about the Unreal engine guys to abandon the unreal script which was used until now for many years ? I don’t think this topic is really suited for this list, but I’ll answer it anyway because why not. To give some background about myself: I’ve been around Qt for a while, actively developing with it since - I think - around 4.4, but I have also had exposure to code a lot older than that. I’ve been involved with developing two phones (one with C++ as the primary language of choice for the system applications - the Nokia N9) and more recently I’ve been working on Jolla’s Sailfish OS - which is a QML-centric (but not exclusive) platform, with most middleware and logic (that is - the real guts) written in C++. My feeling is that QML has exactly the flaws everyone talks about: it can easily create a mess of an application, it’s annoying to tool, it’s annoying to debug (because, well, you’ve two languages / runtimes / etc instead of one). On the other hand, it’s also one of the fastest things I’ve ever found to prototype UIs in (for context, the initial home screen code prototyping I mention on https://twitter.com/w00teh/status/447041014520643584 happened literally in one day). We had similar stories with most of our other applications, being fleshed out in UI within a very short span of time, with a lot more time then subsequently being spent in getting the middleware in good shape and bolted together correctly. Having a language runtime that isn’t C++ also frees you up from a few of the usual messes (access-after-free, etc, etc, etc) and generally means that the problems you get to debug are on a more superficial level. Unless you run into engine or Quick item implementation issues, which sadly aren’t yet as infrequent as I’d like - but it’s young. Give it time. The central point I guess I’m trying to make here is that, like any other tool, QML has its downsides, and as a developer, it is your job to be aware of those downsides, and to try to stick to best practices when writing your application. It’s perfectly possible to write a horribly unmaintainable mess in any tool/language, given a bad developer. I think the tradeoffs are worth the risks, even though I’ve seen a few of those horribly unmaintainable messes already in QML’s short lifespan. BR, Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing Valerio Valerio (VDVsx) for Approver rights to messagingframework
On Thu, Jan 23, 2014 at 8:48 AM, Thiago Macieira wrote: > On quinta-feira, 23 de janeiro de 2014 07:37:14, Knoll Lars wrote: >> On 23/01/14 00:32, "Thiago Macieira" wrote: >> >However, knowing Valerio from the past, I would be ok with giving him >> >approver >> >rights throughout. >> >> +1 (including the last sentence). > > Ok, so Valerio is now on the regular 3-week period for approvership. Which has long since expired, so congrats to Valerio :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: "rebranding" QMF as QtMail
On Mon, Feb 17, 2014 at 1:41 AM, Sze Howe Koh wrote: >>> The repository is currently comprised of two main libraries: >>> QmfMessageServer and QmfClient. I would propose: >>> >>> QmfClient => QtMail >>> QmfMessageServer => QtMessageServer >>> >>> Classes in QMF are already using the QMail* prefix. >>> >>> Any objections? >> >> +1 > > +1 for renaming, to avoid confusion (people might mistake them for > "QML Client" or "QML Message Server") > > To make the relationship between the 2 libraries more obvious, I'd > give them similar names (e.g. "QtEmailClient" and "QtEmailServer"). I was kind of deliberately avoiding the "Email" name due to awkward capitalisation, I also think that "Mail" is sufficiently clear in an IT context. I wouldn't expect to find a Qt API for postal mail, after all. :-) You're right that it should probably be QtMailMessageServer, though. > How big are the libraries? If they're small, what do you think of > merging them into one library? I think there is value in keeping them split. The message server library is something that I personally think of as more of an implementation detail. It's used to implement plugins for the messageserver binary, not mail client tools. That's rather a limited goal/audience compared to the main library. BR, Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: "rebranding" QMF as QtMail
Hi, Sorry for the delay in replying. On Mon, Feb 10, 2014 at 6:34 PM, Konstantin Ritt wrote: >> QmfClient => QtMail >> QmfMessageServer => QtMessageServer > Two modules in one repo (aka QT += mail messageserver), right? Yes. Same situation as it is now. > BTW, are you planning an API review/refactoring for it? I personally feel that some changes are in order (e.g. dropping the custom logging solution in favour of category logging, but I'd like to wait with that until Sailfish has moved to 5.2 in the hopefully-not-too-distant-future); another thing I don't really like is that protocol plugins define a UI for creating & editing accounts (thus tying them to QtWidgets, and also being rather unnecessary given that platform tie-in probably means not using the built-in UI anyway. I'd like to separate those to an account configuration tool, I think, somehow). I should probably start creating JIRA items. If you have proposals for other changes, I'm open to hearing about them. In general, I don't think most of the usability of the API is a problem apart from a few occasional trouble points, but different perspectives are always interesting. BR, Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Proposal: "rebranding" QMF as QtMail
Hello folks, After some build system reworking recently and a little discussion amongst the interested parties (Matt Vogt, Valerio), I'd like to propose renaming QMF (Qt Messaging Framework) to QtMail with the longer term goal of making it a module of Qt properly - no longer a labs project. QMF's naming is historical: QMF originally handled other types of messages than purely mail (SMS/MMS also, for instance). This has not been the case for quite some time - QMF now handles *only* email, so this renaming makes the whole thing sound a bit less meta and less awkward. The repository is currently comprised of two main libraries: QmfMessageServer and QmfClient. I would propose: QmfClient => QtMail QmfMessageServer => QtMessageServer Classes in QMF are already using the QMail* prefix. Any objections? BR, Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Proposing Valerio Valerio (VDVsx) for Approver rights to messagingframework
Hello, I'd like to propose Approver rights for Valerio on messaging framework. Justification: Valerio has worked on (& with) QMF for a long time, on both the Nokia N9 and now with us at Jolla on QMF-on-Sailfish. QMF also doesn't exactly have an abundance of approvers, so especially now that I'm doing some work at the moment, having an 'extra pair of hands' able to review would be handy. Dashboard link: https://codereview.qt-project.org/#dashboard,1001065 (+ the git history for his time before the Gerrit import) Fulll disclosure: I work with Valerio at Jolla. BR, Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] frozen tickets on bugreports.qt-project.org in qt-mobility and qt-components
Hi Alan, On Mon, Jan 20, 2014 at 11:33 PM, Alan Ezust wrote: > Meego is still a "supported" platform, with Jolla and all, right? While we use a number of components that were part of or have their roots in MeeGo, Sailfish is a rather different beast, particularly on the UI level. Think of it as a distant cousin, rather than a direct offspring. Sailfish uses Qt 5 & QtQuick 2 whereas on the Nokia N9, you had a Qt 4 / QtQuick 1 stack. Sailfish does not use the components referred to under QTCOMPONENTS. So I think it's fairly safe to consider that retired. BR, Robin (one of the Jolla folks, sometimes) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Q] Good way to handle QEvent::DeferredDelete
Hi Elvis,
On 27 Dec 2013, at 03:23, Elvis Lee(KwangWoong Lee)
wrote:
I’m looking for good way to handle objects which have called deleteLater.
According to what I understood until now, there are 2 ways to handle them.
One is making control return to the event loop. Another is calling
QCoreApplication::sendPostedEvents(0, QEvent::DeferredDelete) explicitly.
Actually, for the first way, I couldn’t know what to do exactly in code
level. How to return control to event loop?
Let’s first think about how event based programming works.
A simple event loop might look something like this:
while (application_running) {
// here we call out to user code
do_timers_and_stuff();
do_sockets_and_stuff();
// here control is back “in the event loop"
wait_for_something_to_happen();
}
So, your application code will be invoked when there is something to
respond to (an event) - like a timer, socket activity, user input, etc.
When that is done, the control has returned to Qt, and Qt goes back to
sleeping, waiting for new events.
At some point (I’m not sure if it’s defined when - before or after invoking
the user code), Qt processes deferred deletion.
I feel the control is always on event loop in our module. Does that mean
to exit from event loop in QCoreApplication::exec()?
No. You shouldn’t have to.
So I tried the second way, calling sendPostedEvents explicitly. But I
encountered an obstacle to send the event.
It seems that the function should be called with lower or same ‘loopLevel’
of posted event.
I couldn’t find proper position to call sendPostedEvents except adding glib
function to main event loop. (We are using qeventdispatcher_glib)
Usually where is the good position to call sendPostedEvents with low
loopLevel?
In sum, there are 2 question.
1. What is the natural way to handle deleteLater?
2. Where is a place which is not from QCoreApplication::notifyInternal
so that it has loopLevel ‘1’ to call sendPostedEvents?
If this is related to QtWayland: you may be running into a bug within Qt
which we also hit. See the WIP patch at
https://codereview.qt-project.org/#change,71892. Unfortunately, we haven’t
gotten things fixed for all dispatchers yet, so it isn’t yet merged.
Thanks.
Elvis.
BR,
Robin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Fabian Bumberger for Approver Status
On Tue, Nov 19, 2013 at 6:22 PM, Frederik Gladhorn wrote: > (did you know that improving unit tests is one of the most fun things ever and > leads to instant fame and glory? you should try it too some day) http://qtmemes.tumblr.com/post/67517056364/nice-try-fregl ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML and JavaScript extensions
On Thu, Nov 14, 2013 at 3:08 PM, Topi Mäenpää wrote: > Or rather could, if the interface wasn't a moving target. If an interface is a moving target, that means that trying to promise compatibility for it is generally a bad idea. Once something is made public, you're stuck with it. For a very long time, and maybe even forever if people get too attached to it. You can't go back on that, so you need to be very, very sure you'll be happy with it. As evidenced by the v8 to v4vm change, we aren't there yet. And once we do expose it, we tie our hands from making future changes that might be in our benefit. I understand your pain. The company I work for has also had software impacted by these changes (we did the QtScript to v8 port over the summer, we're currently on 5.1, but soon we'll have to look at what changes we need to make to move to 5.2). But erring on the side of caution means we can more reliably end up with something that we're free to keep improving in a backwards compatible way to the majority of folks, while making the life of the few inconvenient. BR, Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ABI change on arm*, call to distros' maintainers
On Wed, Nov 6, 2013 at 6:01 PM, Lisandro Damián Nicanor Pérez wrote: > In Debian we are considering if the problem of breaking ABI without a soname > bump is worth the effort for armhf, but it would be also good to try and > coordinate between distros so as to try to keep binary compatibility between > us. > > What are you thinking about this? At least from a Sailfish perspective, the change came too late. We already released our ARM SDK, and as a result, we'll be sticking with qreal == float (until such time as we can safely make a proper transition, whenever that will be). I should probably add that I find it a bit surprising that this change happened without any real heads-up or warning, given how Qt normally strives to *not* change ABI. BR, Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Gatis Paeglis as approver
+1 On Thu, Oct 24, 2013 at 8:50 PM, Frederik Gladhorn wrote: > Hi, > > I'd like to nominate Gatis as approver. He has been with us in the Digia Oslo > office for quite some time now. Gatis fixed many input/key handling and XCB > issues and started looking at sensors lately. > > Patches by Gatis: > https://codereview.qt-project.org/#q,owner:gatis.paeglis%2540digia.com,n,z > Gatis as reviewer: > https://codereview.qt-project.org/#q,reviewer:gatis.paeglis%2540digia.com,n,z > > Cheers, > Frederik > > > -- > Best regards, > Frederik Gladhorn > Senior Software Engineer - Digia, Qt > Visit us on: http://qt.digia.com > > ___ > 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] Nominating Andrew Knight (aknight) for Approver
And today marks weekday 15 since the proposal, with no negative comments. I guess that means it's time to congratulate Andrew. Can someone please grant the necessary JIRA/Gerrit rights? Thanks, Robin On Fri, Aug 30, 2013 at 1:37 PM, Robin Burchell wrote: > Hello, > > I'd like to nominate aknight for approver status. Andrew has been > doing some solid work that I've noted in QtWayland (and with wayland > in general), and also appears to have some solid knowledge of Windows > from his dashboard: > https://codereview.qt-project.org/#dashboard,1001190. Also useful: > https://codereview.qt-project.org/#q,status:closed+owner:%2522andrew+knight%2522,n,z > > Andrew is responsive on IRC and helpful during code review/discussion, > so I think he'd be an asset. > > Anyone willing to second? > > BR, > > Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] More on QDateTime / QTimeZone
On Thu, Sep 12, 2013 at 9:24 PM, Knoll Lars wrote: > We might be able to simply cache the time zone offset once and cache it. > Then it should be at the same speed. This would also probably provide hidden wins in various places, making changes like b9ef4a9c3047228ec007ac81ff0a304f8cc274b7 in qtbase unnecessary. I'd like to see this for that reason :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] CI false positive.
On Mon, Sep 9, 2013 at 3:21 PM, BogDan wrote: > I'm trying to stage this https://codereview.qt-project.org/#change,64292 > patch, but CI complains that 2 files don't contain "a license header". But > I'm pretty sure they do. At a guess, they are there, but aren't valid. Date ranges aren't allowed by the license check script. There's a bug about this somewhere in bugreports, but I don't have the time to go looking at the moment. BR, Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Thorbjørn Martsum (ThorbjornTux) as approver
+2 :) (and sorry, Steve, this time to the ML) On Fri, Aug 30, 2013 at 3:05 PM, Stephen Kelly wrote: > > Hello, > > I'd like to nominate Thorbjørn for approver status. Thorbjørn has been > contributing to Qt for almost two years, and has been quite active in the last > year in submitting patches and reviewing other patches. > > https://codereview.qt-project.org/#dashboard,1000708 > https://codereview.qt-project.org/#q,reviewer:tmartsum,n,z > > His reviews are thorough, and often catch issues, he's often on IRC and > responsive and friendly. He has made a lot of great quality patches in > itemviews, particularly in QHeaderView and other widgets, as well as more > recent work on the container classes in Qt. > > Any seconds? > > Thanks, > > -- > Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com > > Stephen Kelly | 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 > ___ > 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
[Development] Nominating Andrew Knight (aknight) for Approver
Hello, I'd like to nominate aknight for approver status. Andrew has been doing some solid work that I've noted in QtWayland (and with wayland in general), and also appears to have some solid knowledge of Windows from his dashboard: https://codereview.qt-project.org/#dashboard,1001190. Also useful: https://codereview.qt-project.org/#q,status:closed+owner:%2522andrew+knight%2522,n,z Andrew is responsive on IRC and helpful during code review/discussion, so I think he'd be an asset. Anyone willing to second? BR, Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Tracing Qt
Hi,
(apologies in advance for the wall of text)
It's inevitable when working with Qt that sooner or later, you
probably have a desire to work on tracing Qt - or at least part of it.
Qt Creator's QML profiler is one such very prominent example of an
area where this may be useful, but there are many others: usually
sprinkled around Qt hidden behind various defines, environment
variables, and other hard-to-find places. This makes digging into a
problem somewhat hard, unless you are (or can be handheld by) a Qt
expert when you start digging.
It's also a bit of a problem in that each of these methods uses
different ways to communicate information, meaning it is difficult to
write tooling to inspect this data and visualise it. We also miss out
on tracing in a number of areas that *could* potentially be valuable,
such as touch event processing, the event loop, the sky's the limit.
Thanks to Carsten and Andre for their input in hashing the details of
this proposal out.
Proposal
Let's look at unifying tracing inside Qt. Let's add code to Qt itself
to enable easy introspection of what exactly is going on.
When looking at tracing, it can be boiled down into two levels - an
area (which may be a feature being inspected, or a subsystem - for
instance, QML performance, vsync timestamps, ...) containing events,
so from this, we can gather that we need a way to categorise logging
by area, and the capability to switch logging on by area.
An area should be associated with a simple numeric identifier to avoid
expensive code when manipulating events, but there will be some form
of name => id mapping (for the environment variable below, for
instance).
Suggested area-based API:
enum TraceArea {
TraceAreaDrawing (drawing event, frame event)
... other areas as required
TraceAreaUser = 1000 // held for possible future expansion into
allowing dynamic area registration
}
QT_ENABLE_TRACE=inputevents,frameevents,magicalmonkeyevents
rationale: providing system-wide defaults enables tracing of
system-wide behaviour is very useful. Being able to inspect exactly
what an entire set of Qt-based applications are doing while a user is
interacting with it would be a useful thing.
enable_trace(TraceArea area)
disable_trace(TraceArea area)
rationale: a developer may want to turn tracing of an individual area
on/off at runtime, as they start something they are particularly
interested in tracing. This has some inspiration in
CALLGRIND_START_INSTRUMENTATION/CALLGRIND_STOP_INSTRUMENTATION also.
Along with this user-facing API, we also need some mechanism to enable
different applications of the tracing data (for instance, the QML
profiler from Creator, Android's systrace
https://developer.android.com/tools/help/systrace.html, plain console
logging, etc). Multiple tracers should be able to handle a single
area. Tracers would live in seperate plugins.
Example tracer API:
class QTracer { virtual void logStart() = 0; virtual void logEnd() = 0; }
QTracer subclasses would register their interest in a particular event
type on construction:
struct MyCoolConsoleTracer : public QTracer {
MyCoolConsoleTracer() : QTracer() {
q_register_tracer_for_area(this, TraceAreaDrawing); // we are
interested in this particular event type
}
virtual void logStart() {
qDebug() << "Trace event for drawing, start: " <<
QDateTime::currentMSecsSinceEpoch()
}
virtual void logEnd() {
qDebug() << "Trace event for drawing, end: " <<
QDateTime::currentMSecsSinceEpoch()
}
};
The invocation of tracer subclasses is controlled by a simple RAII class:
struct QTraceEvent {
QTraceEvent(TraceArea area); // invokes logStart on all interested tracers
~QTraceEvent(); // invokes logEnd on all interested tracers
}
Example use being something like:
void draw() {
QTraceEvent e(TraceAreaDrawing);
// do painting
paintOnScreen();
}
Thoughts, flames, cookies?
BR,
Robin
(with jolla hat on)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enabling -Werror developer builds
On Tue, Aug 20, 2013 at 12:14 AM, Thiago Macieira wrote: > Right now, I've got most modules compiling with -Werror with GCC 4.7. I'd like > to start adding the CONFIG to enable the flag. > > Objections? One potential problem I see (I haven't looked at your changes, sorry, holiday and lack of time) - is in the behavior of dependencies. Say that something in qtbase is deprecated, but not yet removed from all submodules (due to a lack of urgency, proliferation of use, whatever) --- that will then block the build of the submodules, but not qtbase. Maybe -Wno-error=deprecated would be a good idea? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] PSA: Qt Project IRC logs & statistics
On Thu, May 2, 2013 at 9:40 PM, Alan Alpert <4163654...@gmail.com> wrote: > Given those guidelines, our possible answers are either "No (i.e. > there is no permission given for public logging)" or "list it in the > channel topic for logged channels (and possibly leave some channels > deliberately unlogged)". > > I'm personally in favor of the latter, because the free flow of > information is generally useful to open projects (and this is *not* > sensitive personal data). This pretty much sums up the reasoning for why I've been doing this all along. Some knowledge is passed down through IRC (and unfortunately not recorded elsewhere). Having the ability to find that again when required is often an invaluable resource. As a very simple example, #qt-labs a long time ago is where I learned about memory barriers and reordering. The same can be said about #qt -- the primary purpose of most people going there is to learn, and to ask questions/help each other, and what better way to do that than helping to retain a collective memory? I do think that having an archive of discussion of useful topics like that in general is invaluable, just like a mailing list archive, a VCS commit log, etc. BTW: I had the same concerns pointed out to me privately, which is why the logs are offline again at the moment until I can take the time to remove information that isn't of interest to the project such as IP addresses. I haven't had the time to do this, or to send mails about this, until now, but I do agree with removing it. It isn't technically or socially useful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] PSA: Qt Project IRC logs & statistics
Hi, In addition to hosting qt_gerrit, I have for a very long time generated IRC statistics for #qt and #qt-labs. These were perhaps not all that well publicized, but they did exist. After my recent server outage, obviously, this all got lost. I got around to restoring it this evening (see http://qt.viroteck.net/irc/), and I've also published logs for #qt and #qt-labs which I did not do previously due to laziness. I can do other channels on request (as usual). There isn't much there yet, but the statistics are set to auto-generate at the server's idea of midnight, so checking back in a few days should give more interesting results, provided I've remembered how to use crontab correctly. I've documented both this (and qt_gerrit) at https://qt-project.org/wiki/IRC Thanks, Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] PSA: qt_gerrit downtime and forgetfulness
On Thu, Apr 18, 2013 at 2:05 PM, Robin Burchell wrote: > - he announces gerrit changes in qt_gerrit Ahem. #qt-gerrit. I shouldn't be trusted with an email client as well as server management, apparently. :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] PSA: qt_gerrit downtime and forgetfulness
Hi, A short PSA: qt_gerrit had some downtime this morning (and is now back, at least in a few channels). The post mortem: some fat-fingered user of that server hosting qt_gerrit (i.e. me) made a rather serious mistake that meant the server needed reinstallation. The code for qt_gerrit was safe (as it's stored in git), but the configuration file was lost. This means that if you had qt_gerrit in your channel, he doesn't remember anymore. If you would like him in there, please ask me. For those of you who don't know about qt_gerrit: - he's a bot - he announces gerrit changes in qt_gerrit (and soon, other channels on demand, if I ever get around to rewriting that feature - e.g. jsondb used to send their messages to their development channel) - he looks up information on JIRA changes if you mention a bug id - he may do some other fun things as I get ideas and time to implement them Thanks (& sorry for the inconvenience), Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Access lazy Models from within QML
On Tue, Mar 5, 2013 at 8:28 AM, Dominik Holland wrote: > Yes this makes sense and it's similar to my solution... But why do you > need to multiply it with 0.9 ? To start fetching (hopefully) before the data is really needed. Models may involve asynchronous access (network etc) which might take a while. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
