Comment 12 for bug 1572525

Hi guys! I have to say, that I completely disagree with the proposed solution and would like us to stop for a moment and think about the issue again. I'm attaching a video which shows how the application is working on the current OTA and how I think it should continue working.

The thing I want to stress is that I'm using the UITK in a proper way, I'm not exploiting any undefined behaviour, but actually relying and the *documented* behaviour.

Now, if you think that reverting to the old behaviour is not possible without also reopening the three bugs which were fixed with that MP, I would like to ask you to give me a chance to try and see if it's possible to get the best of both worlds: fix those three bugs, while still retaining the old documented behaviour. I believe it should be possible, and I'm willing to use my free time to work on that.

The other question is how wrong the old behaviour is, and how many people were affected by it. First of all, we have no bug about it, which leads me to think that nobody found it wrong. If I correctly understood Andrea's concerns he wrote in IRC, his use case is very different: he was saying that when the header is hidden, the original topMargin of the flickable should be retained. I fully agree with him, and I see no contradiction: I believe that both this issue and the issue I'm having could be fixed.

In short, the behaviour I'm proposing is:
1) When the flickable is not bound to a header, or is bound to an invisible header, don't mess with its topMargin
2) When the flickable is bound to a visible header, its topMargin is set to the header's height

If some people (do we actually have any?) think that #2 is wrong, let's introduce an additional property retainFlickableMargins which if enabled will toggle the new behaviour (summing the initial flickable topMargin and the header height). But I seriously doubt that it's a needed thing.