Update: In this MR
https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/deprecateSubHeader/+merge/296919
I add a red outline to the old header when it is used inside
AdaptivePageLayout. It will be included in the next landing of our staging.
Greets,
Tim.
On Tue, May 24, 2016 at 8:53 AM, Zoltán
Hi all,
I have collected our thoughts about this topic on a form of a blog post:
https://developer.ubuntu.com/en/blog/2016/05/24/about-versioning-ubuntu-ui-toolkit/
One extra point what I wish to mention is that we do scan and analyze
those applications in the store to have visibility on how
On Mon, 2016-05-23 at 10:28 +0200, Michael Zanetti wrote:
> 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 w
On 21.05.2016 22:18, Zsombor Egri wrote:
>
>
> On Sat, May 21, 2016 at 9:33 PM, Alberto Mardegan
> mailto:alberto.marde...@canonical.com>>
> 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 followi
Hi Zsombor,
I'll just focus on the essential issue and try to get to a
constructive suggestion:
On 21/05/2016 23:18, Zsombor Egri wrote:
> 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
On Sat, May 21, 2016 at 9:33 PM, Alberto Mardegan <
alberto.marde...@canonical.com> 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.
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.
> APL is not performing good
> enough now, so you have to switch to 1.4 anyway.
It is performing well
Hello,
Just to make sure everything is clear, this is the proposal:
- The Page.head property will *NOT* be touched. It will stay as deprecated
(as it was) and no Page API will change.
- From OTA13, the deprecated Page.head (and also Page.title) property will
be ignored *only* if it is used inside
On 20.05.2016 12:14, Tim Peeters wrote:
> Hello Alberto
>
> On Fri, May 20, 2016 at 11:29 AM, Alberto Mardegan
> mailto:alberto.marde...@canonical.com>>
> wrote:
>
> Hi Zsombor,
>
> On 20/05/2016 08:33, Zsombor Egri wrote:
> [...]
> > Second, frameworks do guard you from API br
On 05/20/2016 01:14 PM, Tim Peeters wrote:
The stable release is 1.2, which does not break API or behavior.
OK. This should be somehow communicated to developers.
Now if one goes to
https://developer.ubuntu.com/api/qml/
and wants to develop using a stable version, one would see that 15.04.5
Hello Alberto
On Fri, May 20, 2016 at 11:29 AM, Alberto Mardegan <
alberto.marde...@canonical.com> wrote:
> Hi Zsombor,
>
> On 20/05/2016 08:33, Zsombor Egri wrote:
> [...]
> > Second, frameworks do guard you from API breaks, indeed. What I am
> > surprised a bit is you guys immediately thought t
Hi Zsombor,
On 20/05/2016 08:33, Zsombor Egri wrote:
[...]
> Second, frameworks do guard you from API breaks, indeed. What I am
> surprised a bit is you guys immediately thought this change will be an
> API break. Which is not. Again, this wasn't clear from the original
> mail.
[...]
You yourself
On Fri, May 20, 2016 at 3:42 AM, XiaoGuo Liu
wrote:
> Hi Tim,
>
> Would you please explicitly give us some examples or a blog which are not
> working so that we all can fully understand your points? I think it is best
> to have a blog with examples to clarify this. As said, some developers may
>
Gentlemen,
First of all apologies for the first email, it did not contain a valuable
information which was that we were planning to introduce this "break" by
the end of summer. So not like tomorrow, not next week, not next OTA
release. Because we haven't even started the work. All we did is we che
Hi Tim,
Would you please explicitly give us some examples or a blog which are not
working so that we all can fully understand your points? I think it is best
to have a blog with examples to clarify this. As said, some developers may
miss this email and they may use the wrong approach in the design
I agree on this. Isn't it the purpuse of using frameworks/UI toolkit
versions? I think this isn't a good practice. This has happended quite
frequently. You can't assume that all developers are following this list.
In the end the consumers are the one greatly impacted by this. They'll get
broken
Hi Zsombor,
thanks for your reply.
I'd then like to request a better policy for such changes.
When I asked about click frameworks some time ago, I was told that they
are meant to
keep apps from breaking, each framework should be one fixed environment
the app is targeting.
But it looks like tha
Hello Tim,
As we are not making any new component, and we are targeting this work to
happen with 1.3 UI Toolkit, apps made prior to 15.04.5 (or wherever this
change will land) will stop working with pages using old header
configuration setup. So if you have apps in the store which uses APL with
ol
Hey Tim,
I was wondering whether this change does affect all frameworks?
For example, will an app using the APL and targeting a prior 15.04.X
framework release break because of this change or will only 15.04.5 apps
be affected?
Thanks for your reply!
All the best
Tim
Am 19.05.2016 um 16:52
Hello all,
As you probably know, some time ago we introduced the new PageHeader
component (see
https://developer.ubuntu.com/en/blog/2016/02/24/pageheader-tutorial/ ). An
instance of PageHeader can be assigned to Page.header to define the header
of a Page, and if no Page.header is specified, there
20 matches
Mail list logo
