ubuntu-phone team mailing list archive

[Michael Zanetti <michael.zanetti@xxxxxxxxxxxxx>]

On 21.05.2016 22:18, Zsombor Egri wrote:
> 
> 
> On Sat, May 21, 2016 at 9:33 PM, Alberto Mardegan
> <alberto.mardegan@xxxxxxxxxxxxx <mailto:alberto.mardegan@xxxxxxxxxxxxx>>
> wrote:
> 
>     On 20/05/2016 18:45, Tim Peeters wrote:
>     > The reasons that we do this in 1.3 and not introduce 1.4 right now are
>     > the following:
>     > - Having 1.4 would not solve the problem.
> 
>     It definitely would.
> 
> 
> No, it wouldn't. Because once we open 1.4, people will jump on it,
> because some features they need will be available only in 1.4, and in
> case we have to drop some support like now in one of the components, we
> will have this conversation again, and again, and again...

The difference here in comparison to something else is really that UITK
is shipping unfinished APIs. Usuually, when an API ends up on the
device, it is considered to be stable. Not in this case.

I think this is the main reason why we are having this conversation
again and again and again, and people's apps keep breaking again and
again and again.

While I understand why this is the case for now, I think this is what
needs to change in the long run. Once you ship it, it's done, don't
touch it any more. If you messed up, next chance for course correction
is when you bump the version next time. I'm not saying this is easy or
anything, but this is how it works everywhere else.

> 
> 
>     > APL is not performing good
>     > enough now, so you have to switch to 1.4 anyway.
> 
>     It is performing well enough for people who are using it. People who are
>     not satisfied with it will move to 1.4.
> 
> 
> Well, we had to introduce few properties to get it responsive, and that
> still wasn't good not enough. And we do care about the 5-10 seconds app
> startup. You seem not to know the startup consumption, we do.
>  
> 
> 
>     > - UITK 1.3 is not feature complete yet (but we are getting close).
> 
>     It's good enough for people who are using it now. When people will
>     decide they need new components, they'll move to 1.4. 
> 
> 
>     > - Introducing a new version will require us to duplicate the qml files
>     > for the components and themes,
> 
>     Use symlinks like the apparmor-easyprof-ubuntu project is doing. It's
>     actually a very good way of keeping track of what files have changed and
>     what file haven't.
> 
> 
> We can use symlinks. Indeed. Unless 1.4 will work with 5.5 or 5.6. In
> which case all components will have to be unlinked and import 2.5/2.6.
> So this theory doesn't work. We thought about it when opening 1.3
>  
> 
> 
>     > duplicate all the tests,
> 
>     I don't think you should. At most, add a test which computes a checksum
>     of the 1.3 source tree and verifies that it never changes (in this way
>     you make sure that any modifications to it won't be accidental).
> 
> 
> We already only duplicate those component tests which do differ in
> between the versions. 
> 
> 
>     > and add an
>     > otherwise useless property to StyledItem to detect the correct version
>     > of the theme.
> 
>     If it's necessary to maintain the API contract, it's not
>     unnecessary. :-)
> 
> 
> Well, it is. Because we have dynamic theming, components must know from
> which version they should load their style, depending on the import they
> got used from. And that is not possible without some module-version
> specific property in StyledItem. If we don't have to add anything else,
> we have to add then some fake crap, which is not nice.
> 
> 
>     > - Updating the apps to 1.4 will be a lot of work but necessary if the
>     > apps want to use the convergence features.
> 
>     The only additional work is replacing "1.3" with "1.4". And actually, I
>     wonder if you could avoid requiring it (with QtQuick, one can import 2.0
>     and 2.6 in the same app, and everything works fine).
> 
> 
> Indeed. But there is a difference between QtQuick and Ubuntu Components.
> QtQuick is fully done with C++ and has no dynamic theming. And it is one
> single plugin, no matter if you import 2.0 or 2.6. We do have dynamic
> theming, and that doesn't let us import 1.3 and 1.4 same time. If two
> versions are imported, the theming versioning will be screwed. If we'd
> have static theming (like QtQuick Controls 2), it would be fine, as
> those would be in two different modules. Never the less, it would need
> to import two different modules. And here we go RAM hunger. More,
> components from 1.2 don't work with all 1.3 components, and same will
> happen if we go for 1.4. And you say simply apps will just change to
> import 1.4 instead of 1.4... There will be more than that. There were
> apps which few weeks ago were still mixing versions, and that caused us
> trouble.
> 
> 
>     > Because of all this, we better finish UITK 1.3 and then declare it as
>     > frozen and support it for a long time.
> 
>     Wishful thinking. :-) 2.0 will be much better in all respects, and who
>     knows if design will want to revamp the components in the meantime.
> 
>     You'll meet the same issues again and again, better start working on API
>     stability now than later. Unexpected changes will always occur, even
>     after 2.0 is released.
> 
> 
> Yes, true. However the UI changes you see were all planned for 1.3 and
> thus you see those unexpected (from your side) changes coming still.
> Because we are not yet feature complete. And you mentioned earlier about
> Qt, how they do things. They also have plans in their roadmap, and they
> even slip the release dates if they are not ready yet with the feature
> set they planned for a certain version. Noone closes a version just
> because they woke up in the morning with the proper eye opened.
> 
> 2.0 is not a magic version. We've learned from our past, and we want to
> have a clean start - after all 2.0 is a major release, and it is also a
> start. But we have a good basis we can start from. And we will not rush
> it. Perhaps in parallel we will have one more version, 1.4, and 2.0 will
> be pushed further, but 2.0 will definitely a different one. And yes,
> design know what they have to stick to, and they won't change UI/UX for
> frozen components - just as they do not do that right now.
> 
> We talked about having a blog post about this topic next week, so you
> will see some clarification coming out next week.
> 
> Cheers,
> Zsombor
> 
>

Attachment: signature.asc
Description: OpenPGP digital signature