Latest iOS release

[Rick Walsh]

On 2 May 2016 at 22:33, Marco Martin <notmart at gmail.com> wrote:

> On Mon, May 2, 2016 at 5:14 AM, Thiago Macieira <thiago at macieira.org>
> wrote:
> > That means the layout is unstable. When asked for what its preferred
> size is
> > on qquicklinearlayout.cpp:414
> >     const QSizeF pref = sizeHint(Qt::PreferredSize);
> > the answer does not stabilise.
> >
> > I have absolutely no idea how the layout engine works. The only hint I
> have is
> > to check whether the constraints (the anchors) in whatever page is
> causing
> > this issue make sense.
>
> I have a patch that even if is a bit a work around, I think it makes
> things more reliable anyways (so would be good even if the bug wasn't
> there).
>
> Can somebody hitting the crash on iOS or on the devel machine try to
> rebuild with attached patch?
>
> putting some debug around, I seen that the things that were actually
> returning a non stable size hint were some Label elements (so in the
> end the primitive Text element)
> those with "Buddy:" "Cylinder:" and so on.
>
> One thing I seen is that every single text element in that grid layout
> had wrap anywhere set. Regardless of the upstream bug that probably is
> indeed there, this can cause problems, as we have a grid of two
> columns, with each column having its width that depends from the width
> of the other. Since the implicit width depends from text layouting, if
> the text can wrap anywhere, if i resize the label, making it wrapping
> to two lines, its implicit width will change as well, so it seems this
> infinite recursion was due to the label answering once that it wanted
> its size as one line, the time after as wrapped in two lines, then as
> one line again etc.
>
> I think disabling wrapping for those small labels helps. it solves the
> crash for me.
> if as the attached patch disabling the wrapping altogether is deemed
> too much, using WordWrap as wrapmode would be already better (trying
> hard to wrap at word boundaries before splitting words).
>
> I don't have an idevice, and my android build isn't working at the
moment.  But I did test with subsurface-mobile on the desktop (Linux).  The
patch appeared to make it less fragile, but I did still run into an
infinite loop.  I think maybe you haven't gone far enough.  I haven't
tracked it down, but I'm suspicious of anywhere we wrap AND set the
preferred width (numerous places in divedetailsview.qml).

It's my bedtime now, but it's worth testing dives with long or very long
field entries (suit, buddy, etc.).

Of course, it would be nice if qml were made to be smart enough that it can
detect when an infinite loop exists, and exit with a default width
property.  I'm quite sure that's easier said than done.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160502/3254879b/attachment-0001.html>