Merge fork-kde-realinheritance about qmlweb

[ChALkeR]

I actually doubt that we want this merged as it is, it's a major overhaul in the old code that had everything in one single file. It perhaps it would be easier to redo it if we need this.

I propose to just extract small patches and feature additions from here, and drop the rewrite part for now. Perhaps we could take a look at the steps that were taken during that rewrite after everything else would be merged and reimplement them, if we find them worth it.

@akreuzkamp, what do you think?

[Plaristote]

And by the way, don't we have the same issue with 6022424 ? That sounds like something that would be pretty hard to merge (it doesn't seem it would be easy to use with the registerQmlType helper).
When I saw this commit I figured it looked a bit like what this branch is supposed to implement.

[ChALkeR]

@Plaristote 6022424 is being merged in #28 as 42ad0cb and is awaiting review. Note the daba362 follow-up fix, it breaks without it.

[henrikrudstrom]

noticed that @pavelvasev branch also uses QW_INHERIT.
@Plaristote how is it difficult to use with registerQmlType? wouldnt this work?

var MyType = function(...){ ... }
QW_INHERIT(QMLBaseObject, MyType)
registerQmlType(... constructor: MyType ... 

[Plaristote]

It would, but most of the usages of registerQmlType weren't written like this. Some don't even use a named function. I believe we'll have to rewrite all those call to registerQmlType.

The typical use of registerQmlType is more like this:

registerQmlType({
  constructor: function QMLType() {
  }
});

When it's written like this, the function is named (which can help for debugging), but it isn't accessible from anywhere but the scope which declared it (in this case, QMLType is only visible within itself).

[henrikrudstrom]

i see, but assuming we move to browserify the the visibility should be addressed in any case right?

[akreuzkamp]

I personally would defenitely not merge it as it is. It is a major overhaul, that I discarded myself because I lost overview... It's rather to be seen as a source of inspiration. :)
There is at least one important thing to merge in here, though. It's keyboard input. @Plaristote could you maybe have a look at commit be7bb90 and estimate how valuable the code is, compared to the key-handling you implemented? :)

[Plaristote]

Looks like you've been way further than I did. Pretty sure I didn't do FocusScope, and that's an important piece of that.

[Plaristote]

To go any further than I already did, I need to merge the property binding changes. It's the biggest part of 2443508.

Thing is, it's a really big thing, and I'm not entirely sure I understand it. I don't even know where to begin. If I could have the steps laid out, a plan to make sure that I can have some checkpoints in which the test suite will pass...

I've spent a lot of time on that 2443508 commit, and I'm sure that I can't merge the binding part on my own. There's even a few changes that cannot be merged as is, and since I'm not entirely sure what they do... I don't know how to continue merging.

@akreuzkamp if you can be of any help on that topic, it's very welcome.

[akreuzkamp]

which changes are you exactly looking for?

When watching at commit 2443508 don't forget to have a look at 4eefc48, it reverts some of the binding changes. In fact, in that commit I've experimented quite a lot and most things didn't work out (some because I lost overview, most because at some point it just didn't work).

Can you ask questions on it or is it yet a "what the **** did you do there!?" (in case of the latter: some damn **** ;)) I'll do my best to help of course :) Thanks a lot for tidying up what I left as a ruin. :)

[ChALkeR]

Hm. This was a significant rewrite, and also this was based on the older unsplit version, this can't be merged as it is, but we could re-apply some changes from here (already discussed above).

Taking that into an account, I don't think that a further cleanup (after 0.1.0) would make it significantly harder to apply changes from here (perhaps it would even make things simplier), so I'm removing the 0.1.0 milestone from this.

The idea of delaying the cleanup (0.2.0) until the merges would be complete (0.1.0) was for making merges simplier, which isn't applicable here.

We should stil probably review and cover the changes here in time to 1.0.0, though.

[Plaristote]

One of the change that bothers me for instance is the p variable. I'd like to better understand why this was done.

Then it's all the things about bindings... what results are we trying to obtain with these changes ?
Clearly this isn't just a refactoring, there's a lot of new stuff in it, and it looks important. But I don't really know what it does, and I can't make up the steps from where we are now, and where we want to be once this is merged.

One of the main things that slows me down here is that there's a lot of refactoring, in the middle of meaningful changes. I'm having a hard time telling the cosmetic changes appart from those who bring meaning to the whole picture.

About the milestone, I'm guessing we need the bindings change to start merging the keyboard implementation, so we probably need this sorted out for 1.0.0 indeed.

[akreuzkamp]

Sorry for not answering. I was too busy last month..

The p variable is easy: it was made to save some characters of writing/file size. It doesn't have any deeper meaning.

The binding changes tried to establish a clean separation between properties and bindings. Properties were supposed to not know anything about bindings. The goal was simply to get simpler and better maintainable code.
Moreover we could have set bindings to non-qml-properties, (e.g.css.background: "linear-gradient(white, " + (enabled ? "lightsteelblue" : "grey") +")").
But it just didn't work out. iirc one of the reasons was that we create the binding from the parser so we used to have one binding per component, not per instance. So we needed to copy the binding and stuff, which made the code ugly again. But there were things that just failed, which I don't remember anymore, that could only be resolved by the property knowing its binding...

The only thing that is needed for keyboard support is support for custom setters (or did I miss something?). It's mostly independent of the binding changes.
The problem is that changes to focus need to be propagated up and down in a way, that would cause infinite loops if we just connected a slot to focusChanged. The only proper way of fixing it, is to use setter functions like Qt has them.
Personally I never liked that we just register slots to property.changed signals, instead of doing it the qt way and doing that stuff in the setter. But using setters raises some questions. Maybe we should just start an open discussion about that and reimplement custom setter support according to the discussion's outcomings.

[Plaristote]

b3da103 and d7ae5de have been implemented already. Nothing to be done, I'm checking those boxes.

I've been trying to find use cases for e30ac75 and came up empty ended. It seems related to PropertyChanges and QMLBinding... I was able to port the code to the new refactored applyProperties function, and added an additional test to see how PropertyChanges behaved with bound properties all over. But the test already passed, and coverage shows the condition at line 629 (in the original commit) never evaluates to true... and I can't think of a scenario in which it would. Perhaps this is no longer relevant ?
[EDIT: could be related: new version o ListElement also uses $setCustomData]

be7bb90 A lot o this seems to be implemented already, except for Focusscope. I have my own implementation for that, so I'll start writing tests based on the test tool joined with this commit and see if anything else needs to be done.

e8648d I've been using and defining attached properties, with stuff looking pretty similar to this. It seems like this has been implemented already.

[Plaristote]

Making progress with 2443508 ! I can see that a lot of stuff from this commit has actually already been merged...

But I did manage to implement the custom getter/setter thing - well, most of the work had already been done, there just wasn't any way for individual properties to define their own getters or setters. And that was pretty relevant : not only for focus, but also enabled, which I had shoddily implemented in my controls2 branch... well, the new implementation, powered by these custom setters and getters, passes my tests and is fit for merge in master.

[Plaristote]

Pretty much merged 2443508 at this point. Item no longer relies on signals when updating x, y, z, width, height, implicitWidth, implicitHeight and parent properties, and the changes needed to implement focus support have been integrated.

There are a couple things I haven't integrated, namely anything related to the global stylesheet and $updateDirtyProperty.

• I'm not sure where we were standing on the global stylesheet thing ? Plus it doesn't seem to be coming from these commits.
• I don't get what $updateDirtyProperty's purpose is.

I'll check the box and move on to the next step.

[Plaristote]

Focus and scopes in be7bb90 do not work as intended. Turns out we still have zero support for that feature. I've spent my afternoon trying to merge this commit, or update the existing focus code, to no avail. Even if I did succeed, the implementation in this commit doesn't match the documentation: https://doc.qt.io/qt-6/qtquick-input-focus.html

I'll drop those parts and only merge the Keys related change.

[Plaristote]

dc4ac1d Fix positioners: well, it does Fix positioners, but the breaking changes were never merged.

HOWEVER there is a very important change here, as to how parent change signals are triggered. Instead of triggering childrenChanged in the child's $setParent method, each time a single item is parented to another one... it is called in $setData, only once.
That could be a pretty efficient optimization. And it works. But I'm concerned it might not work on every cases. Plus, it seems this change was reverted later.

Converting $onDataChanged to $setData breaks a lot of stuff, so I won't merge that change... but the parenting trick still works. I'm going to merge this change. We'll see in time if it causes troubles.

[Plaristote]

Just merged the default property commit. The test I wrote earlier now passes. It works !
This broke compatibility with older versions for both qmlweb and qmlweb-parser. I tagged a new parser version, and I'll wait until I reach 75% of test coverage before merging this work into master along with my Controls 2 partial implementation (currently 72%, it's getting there).

[Plaristote]

Merged XmlListModel, with updates to match the Qt6 documentation, patches to add qrc:// scheme support, and well... making things work, because the XMLHttpRequest usage was completely wrong (it made me lose a lot oF time: the documentation itselF is pretty damn vague, and I can see why mistakes were made... turns out the error event is pretty much useless, and you gotta make checks in the load event, because it might be triggered by an error - or when the loading isn't over yet).

Anyhow. It works. And I'm inclined to close this issue and stop the merging. I have doubts about the bits I didn't merge yet... either I don't know what they do, or I'm not sure it's really a good idea to apply those changes. I'll take a last look at each o' them and make notes:

• 7e5643e and c98583d
  Introducing the append method and have it replace setters for list properties: sounds like it could trigger a lot more update events than just overwriting the old array with a new one.

• f9dd070 4eefc48 f8acff6 c481336 e8018c8
  Pretty sure we don't need these anymore.