[PATCH] mobile: divedetails page etc. improvements

[Lubomir I. Ivanov]

On 16 November 2015 at 23:47, Sebastian Kügler <sebas at kde.org> wrote:
> On Friday, November 13, 2015 23:59:09 Lubomir I. Ivanov wrote:
>> > Do I make sense to you? If not, proof-of-concept attached. It's quite minimal
>> > and only shows the very basic mechanism.
>> >
>>
>> nice...so ListView pretty much does what's required here out of the
>> box. also Flickable and MouseAreas in the delegate item *just work* -
>> i've just tested that.
>> plus the buffering, which is a great bonus!
>>
>> as long as there no performance issues, this is pretty much good to go
>> in the source.
>
> Next question: Would you want to have a go at it? :)
>
> (I'm happy to review, of course.)
>
>> > I quite like what you have done in the delegate. I'd like to split viewing and
>> > editing dives into separate UIs, one optimized for viewing, one optimized for
>> > editing (e.g. showing the profile in the editing page is not very useful, on
>> > the other hand the TextEdit widgets in the details view make it visually quite
>> > heavy. We should probably do something like to the current details delegate
>> > (and repurpose / cut down the current detailswidget purely for editing.
>> >
>>
>> for the main application something which was an important topic at
>> some point in time (discussions between Dirk and Tomaz mostly) was to
>> be able to edit in place. this can be seen in the MainTab class ATM.
>> so i'm not sure if everyone will agree on a separate dive edit page
>> for the mobile UI, but this can be solved with a DiveEdit overlay of
>> sorts - i.e. when you swipe the ListView to a dive, click over the
>> details and a rectangle opens on top of static texts with some
>> TextEdit fields...or a DiveEdit can simply replace the static text
>> container until the editing is finished. not sure about the exact
>> implications and if this is the best choice.
>
> Good to know the backstory.
>
> Factoring Dirk's reply in, I think an edit overlay is the way to go here, that means we
> can concentrate on presentation in the divedetails page and focus on editing and
> input in the edit page, this allows us to make both really good instead of having to
> make compromises in each.
>
>> if i manually set "width" and "height" in the ApplicationWindow of
>> main.qml it ignores them but it runs in a huge window!
>> the UI looks quite bad here, but that's probably because i'm using the
>> Windows XP them on Windows 7.
>>
>> any idea how to run the UI in a reasonable desktop resolution e.g. 480x800px?
>
> Not knowing anything about windows, you already suggest to try the default theme,
> so try that. Otherwise, specifying width and height in the top-level item works: it puts
> the initial window at exactly that size.
>
> You can also try using Window (effectively a QQuickWindow) as top-level item, see
> attached example. Let us know what works for you, then we'll put that in (shouldn't
> cause any problems), and it makes your life easier.
>

so the exact error message when using ApplicationWindow (as is in main.qml):
setGeometryDp: Unable to set geometry 160x1200+720+426 on ApplicationWindow_QMLT
YPE_74_QML_111/''. Resulting geometry:  160x885+720+426 (frame: 4, 23, 4, 4, cus
tom margin: 0, 0, 0, 0, minimum size: 0x47, maximum size: 16777215x16777215).

it crashes after a while. my desktop resolution is 1600x900px.

changing ApplicationWindow to Window and keeping everything else makes it work.
i can now resize the window to any size.

attached is a screenshot.

thanks
lubomir
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: subsurface_mobile_screenshot.png
Type: image/png
Size: 15724 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20151117/bd921e6d/attachment-0001.png>