ubuntu-phone team mailing list archive

[Zsombor Egri <zsombor.egri@xxxxxxxxxxxxx>]

On Sat, May 21, 2016 at 9:33 PM, Alberto Mardegan <
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...


> > 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