Latest iOS release

Marco Martin notmart at gmail.com
Mon May 2 08:04:43 PDT 2016


On Mon, May 2, 2016 at 3:19 PM, Rick Walsh <rickmwalsh at gmail.com> wrote:
>
>
> 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).

Here is a different approach, thinking about it i like it a bit more.
The fact that the numbers of the column sizes didn't add up when one
considered the column spacing as well made me suspicious, (in general,
setting a column of like one quarter of the layout size is to be
avoided if the spacing in the layout is not 0) so i tried to make the
last column just "take all the remaining space" rather than trying to
have an exact size, and this seems to completely fix it for me.

see attached patch.

--
Marco Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Make-the-last-column-take-all-the-available-size.patch
Type: text/x-patch
Size: 6383 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160502/04058bbb/attachment.bin>


More information about the subsurface mailing list